Difference between revisions of "Transaction signing"

Revision as of 06:14, 31 July 2014

A signed transaction is essentially some signed message very similar to a Bitcoin transaction, but without any scripting. It's a set of instructions for modifying the balance sheet (the account tree). To verify a withdrawal from any account, the owner of the account must sign the transaction with the private key which corresponds to the account address. However if we're not careful, such a signed message could be used not just once, but many times, and still be valid. Luckily we can solve this.

Preventing Reuse of Signed Transactions

A scheme with limited duplicate checking:

• Lets define N to be less than minimum number of historical blocks every node is required to keep (see cycle time).
• Creator of transaction puts latest block number inside txn and signs it. Lets call this block number K.
• Network treats such transaction as valid if it is included in one of blocks from K+1 to K+N.
• If the same transaction with the same signature was already included in one of past N blocks then it is rejected.

This scheme has the following advantages:

• Does not affect concurrent transaction generation.
• Can be used to make time locked transactions (Cryptonite allows delay of no more than 5 blocks to prevent DoS attacks).
• Nodes can incorporate transactions from abandoned branches into main chain if reorganization is smaller than N blocks.
• It helps to make withdrawal limits work which makes double-spending considerably harder.

Removing Transaction Malleability

So, in order to make sure the same signed transaction isn't processed by the network more than once, the transaction must also contain a “lockheight” field. The transaction becomes invalid once the lockheight is outside the range of blocks which nodes are required to keep (lets call this the blocks “in view”), and same txid cannot be included twice in any of the blocks which are in view. This makes it impossible to use the same txid twice. However this solution requires that the txid is not malleable.

There are several things which need to be considered when attempting to solve transaction malleability, but most importantly we can't include the signatures when hashing a transaction because signing the same data with the same key produces different signatures each time. The sender will sign the txid, but signing it many times in no way alters the txid, only the signatures. Thus attempting to alter the contents of the transaction will always change the txid and as a result invalidate the signature(s).