In this chapter we will take a closer look at transactions. Transactions can be seen as actions taken on the blockchain, chaging the state of the block chain.
From the NEM API documentation:
Once a transaction is initiated, it is still unconfirmed and thus not yet accepted by the network. At this point it is not yet clear if it will get included in a block. Never rely on a transaction which has the state 'unconfirmed'. Once it is included in a block, the transaction gets processed and, in case of a transfer transaction, the amount stated in the transaction gets transferred from the sender's account to the recipient's account. Additionally the transaction fee is deducted from the sender's account. The transaction is said to have 0 confirmations at this point. When another block is added to the block chain the transaction has 1 confirmation. The next block added to the chain will give it 2 confirmations and so on. Crypto currencies have the ability to roll back part the block chain. This is essential for being able to resolve forks of the block chain. There is however a maximum number of blocks that can be rolled back, this is called the rewrite limit. Hence forks can only be resolved up to a certain depth too. NEM has a rewrite limit of 360 blocks. Once a transaction has more than 360 confirmations, it cannot be reversed. In real life, forks that are deeper than 20 blocks do not happen, unless there was some severe problem with the block chain due to a bug in the code or an attack of some kind.
As different actions can be taken, different transaction types have been defined. Transaction types are grouped by kind. For example all multisig transactions are of the same kind, but still have a differrent type according to their effect like adding a cosignatory or signing a pending multisig transaction. Some kinds have multiple transaction types, others only have one.
Each transaction kind has a base id, from which the id of their transaction types are derived. For example, the transfer kind has base id
and a mosaic transfer type has id
0x101. If one days it is decided that NEM needs a new transfer type, it would be assigned the id
today is not used.
Here are the transfer kinds and their respective types, each with their id noted in hexadecimal and decimal notation, as extracted from the code:
|Transfer||0x100, 256||Mosaic transfer||0x101, 257|
|Importance||0x800, 2048||Importance transfer||0x801, 2049|
|Multisig||0x1000, 4096||Multisig change||0x1001, 4097|
|Multisig sign||0x1002, 4098|
|Multisig tx||0x1004, 4100|
|Namespace||0x2000, 8192||Provision ns||0x2001, 8193|
|Mosaic||0x4000, 16384||Mosaic definition creation||0x4001, 16385|
|Mosaic supply change||0x4002, 16386|
Keep this as a reference for when we’ll monitor or create transactions.
Just for the completeness, there are gaps in the numbers because some of them have been assigned to kinds and types that were never used in the end. Here they are:
|0x200, 512||0x201, 513|
|0x400, 1024||0x241, 1025|