Transactions

On Lisk, transactions are designated by type. These transaction types include:

Active Transaction Types Deprecated Transaction Types
Type 0: Transmit funds to a specified Lisk address Type 5: Register an application on the Blockchain
Type 1: Register a second secret Type 6: Transfer Lisk into a Sidechain
Type 2: Register a delegate Type 7: Transfer Lisk out of a Sidechain
Type 3: Submit vote(s) for delegates
Type 4: Multisignature registration

Transaction Signing

Every transaction, regardless of the type, must be signed by the sender prior to being accepted by the network. The process of signing the transaction is identical for every transaction. First, a data block representing the transaction must be generated. Each data block contains a specific set of standardized information. Additional information contained in the data block will differ depending on the type of the transaction.

The following fields must be present in all types of transactions:

  • A 8 bit integer identifying the type of the transaction
  • A 32 bit epoch timestamp of when the transaction has been created
  • The 256 bit public key of the issuer of the transaction
  • A 64 bit integer representing the amount of Lisk to be transferred

The other fields will be added to this schema depending on the transaction type. Once the data block has been generated, it is hashed using the SHA-256 algorithm, and this hash is signed using the key pair of the issuer. If the issuer has enabled a second pass phrase, the first signature is appended at the end of the data block, and the process is repeated, generating a second signature. The same concept applies to multisignature accounts. The transactionId is generated from the data block. In order to compute the transactionId the system takes the data block with the completed signature information and hashes this block using SHA-256 and the first 8 bytes of the hash are reversed and which is then used as the transactionId.

A signed transaction uses the following flow:

With a second signature the flow looks like this:

Balance Transfer Transaction

A balance transfer transaction (type 0) is a transfer of Lisk from one account to another account. In order to issue a balance transfer transaction, the following fields must be specified:

  • The account Id of the recipient
  • The amount of LSK to transfer
  • The secret of the account

Once those three fields have been specified, the system will begin building the transaction object. First, the public key of the sender is computed using their secret. Following this, the data block is created using the process outlined in Transaction Signing and the additional field, recipientId, is added the to object. The resulting data block is 53 bytes.

This block is then signed using the method described in section 2.1. The final step of the transaction generation process is to compute the fee of the transaction. In the current system, the fee is fixed at 0.1 Lisk. Once all these steps have been completed and the transaction validated, the transaction may be broadcast on the network. While the transaction may be present on the network, it will remain in unconfirmed status until it has been processed by a delegate. When the transaction is broadcast to the network and it is sent as a JSON object using the HTTP API.

The following figure is a representation of a transaction object:

The following figure is a representation of the JSON.

{
    "type": 0,
    "amount": Amount,
    "senderPublicKey": Public key of the sender,
    "timestamp": Timestamp,
    "recipientId": Id of the recipient,
    "signature": Signature of the data block,
    "id": Id of the transaction,
    "fee": 10000000,
    "senderId": Id of the sender,
    ...
}

The final size of a balance transfer transaction with no second pass phrase is 117 bytes, and 181 bytes with a second pass phrase.

Second Signature Registration Transaction

A second signature registration transaction (type 1) is used to register a second passphrase on the blockchain. In order to issue this type of transaction the following fields must be specified:

  • secret: The secret of the account.
  • secondSecret: The desired second pass phrase.

Once those two fields have been specified the system will begin building the transaction. The process outlined in section 5.1 is followed for this process. The second public key is generated from the second pass phrase, and the system builds the data block of 85 bytes.

This data block is then signed using the user’s secret ks, and the signature is appended to the object. Following this the computation of the fee is performed for the transaction type. In the existing implementation the fee for a signature transaction is fixed at 5 Lisk.

The resulting object is represented by the following diagram:

The JSON object that will be broadcast on the network is represented by the following diagram:

{
    "type": 1,
    "amount": 0,
    "senderPublicKey": Public key of the sender,
    "timestamp": Timestamp,
    "recipientId": null,
    "signature": Signature of the data block,
    "id": Id of the transaction,
    "fee": 500000000,
    "senderId": Id of the sender,
    "asset": {
        "signature": {
            "publicKey": The public key associated with the second passphrase
        }
    }
    ...
}

The final size of the transaction, with the signature, is 149 bytes.

Delegate Registration Transaction

A delegate transaction (type 2) is used to register the account as a delegate. Refer to section 6.1 for more information about delegates. In order to issue a delegate registration transaction the following fields are required:

  • secret: The secret of the account.
  • username: The delegate’s username.

The length of the username must be at least one character and at most twenty characters. Once those fields have been specified, the system can then compute the account's public key, and begin building the transaction’s data block with a maximum 73 bytes.

This data block is then signed using the account's secret, and the signature is appended to the transaction object. The system then computes the fee of the transaction. In the present implementation, the fee for a signature transaction is fixed and costs 25 Lisk.

The resulting object is represented by the following diagram:

The JSON object that will be broadcast to the network is the follows the format below:

{
    "type": 2,
    "amount": 0,
    "senderPublicKey": Public key of the sender,
    "timestamp": Timestamp,
    "recipientId": null,
    "signature": Signature of the data block,
    "id": Id of the transaction,
    "fee": 10000000000,
    "senderId": Id of the sender,
    "asset": {
        "delegate": {
            "username": The chosen username
            "publicKey": The public key of the delegate (the sender)
        }
    }
    ...
}

The final maximum size of the transaction, with the signature, is 137 bytes, and with a second signature, 201 bytes.

Vote Transaction

A vote transaction (type 3) is a transaction used to vote for delegates. In order to issue a vote transaction, the following two fields are required:

  • secret: The secret of the account.
  • delegates: An array of votes.

A vote is prepended with a ’+’ for adding stake to the delegate’s public key, and a ’-’ is prepended to the delegate’s public key if the account wants to remove the vote for the delegate. The maximum number of vote applications in one transaction is 33. Once those fields have been specified, the system can then compute the account's public key, and start building the transaction’s data block with a maximum 2198 bytes.

This data block is then signed using the account's secret, and the signature is appended to the transaction object. The system will then compute the fee of the transaction. In the current implementation, the fee for a vote transaction is fixed at 1 Lisk.

The resulting object is represented by the following diagram:

The JSON object that will be broadcast to the network is the follows the format below:

{
    "type": 3,
    "amount": 0,
    "senderPublicKey": Public key of the sender,
    "timestamp": Timestamp,
    "recipientId": Id of the sender,
    "signature": Signature of the data block,
    "id": Id of the transaction,
    "fee": 100000000,
    "senderId": Id of the sender,
    "asset": {
        "votes": Array of votes
    }
    ...
}

The final maximum size of the transaction, with the signature is 2262 bytes, and with the second signature is 2326 bytes.

Multisignature Registration Transaction

A multisignature registration transaction (type 4) is a transaction used to add a multisignature to an account. Refer to section 3.3 for more information about multisignatures. The following fields are needed in order to issue a multisignature registration transaction:

  • secret: The secret of the account the multisignature will be applied to.
  • keysgroup: The array of keys to add or remove from the multisignature account.
  • min: The minimum amount of signature required to validate a transaction. (Minimum of 2)
  • lifetime: The time to wait for enough signatures before removing the transaction.

Each public key in the keys group is prepended with a ’+’ then the public key to be added to the multisignature account. The minimum amount of signature required to validate a transaction must be at least 2 and at most 16. The minimum amount of keys in the keysgroup is two. The lifetime is specified in hours and a must be at least 1 hour and at most 24 hours. Once those fields have been specified, the system will then compute the account's public key, and start building the transaction’s data block. The size of the data block depends on the amount of keys added to the multisignature registration transaction. Each key is 65 bytes due to the addition of the modifier.

This data block is then signed using the user’s secret, and the signature is appended to the transaction object. The system will then compute the fee of the transaction. In the present implementation the fee for a multisignature registration transaction is 5 Lisk per key in the keygsgroup. Note that the key of the account issuing the transaction is implicitly added in the multisignature.

The resulting object is represented by the following diagram:

The JSON object that will be broadcast to the network is the follows the format below:

{
    "type": 4,
    "amount": 0,
    "senderPublicKey": Public key of the sender,
    "timestamp": Timestamp,
    "recipientId": null,
    "signature": Signature of the data block,
    "id": Id of the transaction,
    "fee": Transaction fee,
    "senderId": Id of the sender,
    "asset": {
        "multisignature": {
            "min": The minimum of signature required,
            "lifetime": The lifetime of the transaction,
            "keysgroup": Array of keys to add in the multisignature
        }
    }
    ...
}

The final size of a transaction with two keys in the keys group is 249 bytes, and 313 bytes if the account has a second pass phrase enabled.


What's next?
Consensus Algorithm