Difference between revisions of "Transaction signing"
m (fixed incorrect statement) |
m (Fixed up stupid wording.) |
||
| Line 1: | Line 1: | ||
__TOC__ | __TOC__ | ||
| − | A signed [[Transactions | 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. | + | A signed [[Transactions | 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. The [[mini-blockchain]] is designed in such a way, that old transactions can be forgotten, so transaction signing must be done in a way that prevents rebroadcasting of old forgotten transactions while not affecting the ability of the system to handle multiple concurrent transactions. |
==Preventing Reuse of Signed Transactions== | ==Preventing Reuse of Signed Transactions== | ||
| Line 16: | Line 16: | ||
* Nodes can incorporate transactions from abandoned branches into main chain if reorganization is smaller than N blocks. | * 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. | * It helps to make [[withdrawal limits]] work which makes double-spending considerably harder. | ||
| − | |||
| − | |||
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. | 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. | ||
| − | + | ==Removing Transaction Malleability== | |
| + | |||
| + | One of the reasons Cryptonite does not suffer from transaction malleability is because it doesn't use scripting, but more importantly it doesn'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). | ||
Latest revision as of 22:44, 4 November 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. The mini-blockchain is designed in such a way, that old transactions can be forgotten, so transaction signing must be done in a way that prevents rebroadcasting of old forgotten transactions while not affecting the ability of the system to handle multiple concurrent transactions.
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.
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.
Removing Transaction Malleability
One of the reasons Cryptonite does not suffer from transaction malleability is because it doesn't use scripting, but more importantly it doesn'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).
