Transaction signing - Revision history

Admin: Fixed up stupid wording.

2014-11-04T22:44:43Z

Fixed up stupid wording.

← Older revision		Revision as of 22:44, 4 November 2014
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. ~~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~~.		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.

	==Removing Transaction Malleability==		==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.~~		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).

	~~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).

Admin: fixed incorrect statement

2014-07-31T06:14:40Z

fixed incorrect statement

← Older revision		Revision as of 06:14, 31 July 2014
Line 19:		Line 19:
	==Removing Transaction Malleability==		==Removing Transaction Malleability==

	So, in order to make sure the same signed transaction isn't processed by the network more than once, the ~~block header~~ 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.

	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).		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).

Admin: added table of contents

2014-07-18T15:28:07Z

added table of contents

← Older revision		Revision as of 15:28, 18 July 2014
Line 1:		Line 1:
			__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. 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.		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. 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.

Admin: Added page to wiki

2014-07-16T08:58:12Z

Added page to wiki

New page

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. 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 block header 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).