Skip to content

GitLab

Last edited by Josh Wilcox
Page history

Instant send

How instant send works (technical)

Each transaction is constructed and sent using the following functions.

CreateTransaction
CommitTransaction

CommitTransaction takes an argument which identifies whether the transaction is an instant or regular one (ix or tx). If it's an instant then locking process is performed.

Locking process

The node creates lock request and broadcasts it to the network to be voted. If votes count of each transaction is equal or more then INSTANTX_SIGNATURES_REQUIRED (6) then transaction is considered as locked in the network and the locking information is kept in mapLockedInputs map. Later when accepting a new block each node checks if the input is not in mapLockedInput and rejects the block if it is (to prevent double spend). For the receiver it is enough to wait until the transaction is written in blockchain (1 confirmation) and it can be spent in a regular way.

When trying to get depth in the blockchain of instant sent transaction it considers already having 5 confirmations that’s why users see (5 of 6 confirmations) in QT gui when sending instant transaction and it gives an impression that it has 5 confirmations immediately after send.

Current drawbacks of instant send

  1. Theoretically there can be cases when instant transaction doesn’t get enough votes (not enough masternodes, network issue etc.)
  2. After instant send transaction closing and reopening the wallet makes the transaction to seem like regular.
    The reason is because mapLockedInputs variable is empty after crown reboot and it doesn’t know anything about locked transactions. Network of course is aware of that transaction lock but the local wallet will force to wait several confirmations to allow the input to be spent.
    This could be fixed by requesting transaction lock information after wallet run.
  3. Transaction input sent instantly can be used instantly again after 6 confirmations.

Technical reason of waiting 6 confirmations

Transactions are locked based on input already approved transaction. If the input is not yet confirmed (it has < 6 confirmations) the block can be rewritten and the input can be lost. So locking input which has just one confirmation can be lost and network will keep locked transaction which doesn’t exist.