<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapcontinue="Transactions" />
  </query-continue>
  <query>
    <pages>
      <page pageid="27" ns="0" title="Transaction signing">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">__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. 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).</rev>
        </revisions>
      </page>
      <page pageid="28" ns="0" title="Transaction types">
        <revisions>
          <rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">There are 3 main types of [[transactions]] used in the mini-blockchain scheme:

# Send coins to other addresses
# Claiming block reward
# Change [[Withdrawal_limits | withdrawal limit]]

Changing the withdrawal limit is a special type of transaction where the output address is the same as the input. A transaction using a multi-signature address as an input is similar to a normal transaction but requires multiple signatures for verification. See the [[multi-signature transactions]] page for more information.</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>