Da2ce7:New Transaction: Difference between revisions
added lists for processing |
updated intro |
||
Line 1: | Line 1: | ||
'' | ''New Transaction'' is an proposal for a new extendable method of creating transactions.<br /> | ||
Each new transaction is defined by a random ''txnumber'' that should be unique globally.<br /> | |||
Advanced functions, such as transaction scripts, and importing and exporting can appropriately be done using the group of supporting functions. | |||
=== Transaction life-cycle === | |||
Every New Transaction goes through the following steps. (not always in the same order) | |||
==== Build ==== | |||
In this stage, a transaction is being built:<br /> | |||
* Any feature of the transaction may be modified. | |||
* Users can add, remove, any input, output or script. | |||
==== Ready ==== | |||
In this stage, only certain features may be modified:<br /> | |||
* Only inputs may be changed. (is this correct, or will past signatures be destroyed if we change them?) | |||
* Any other attribute that doesn't effect the existing signatures. | |||
==== Done ==== | |||
In this stage, the transaction is complete, and would be accepted by the network: | |||
* User still can add inputs, however all the outputs have already been fulfilled, these new inputs will be counted as fees. | |||
* After any change, a 'done' transaction gets automatically demoted to 'Ready' state. | |||
==== Submitted ==== | |||
In this stage the transaction has been published to the bitcoin network and is in/or is awaiting to be included in a block. | |||
=== Terms === | |||
''txnumber'' is a random string given to every transaction for identification purposes.<br /> | ''txnumber'' is a random string given to every transaction for identification purposes.<br /> | ||
''pubkey'' is assumed to be owned by the client that preforms the 'readying' of the transition (build > ready states) | ''pubkey'' is assumed to be owned by the client that preforms the 'readying' of the transition (build > ready states) | ||
'''This entire processing is lazy! Bitcoin will automatically fill-out everything just as it dose at-the-moment with the ''readytransaction'' stage.''' | '''This entire processing is lazy! Bitcoin will automatically fill-out everything just as it dose at-the-moment with the ''readytransaction'' stage.''' | ||
Line 113: | Line 132: | ||
/// sign ''ready'' transaction ( | /// sign ''ready'' transaction (6 override) | ||
signtransaction {txnumber} | signtransaction {txnumber} | ||
signtransaction [{txnumber}] | signtransaction [{txnumber}] | ||
Line 120: | Line 139: | ||
signtransaction -r {txnumber} | signtransaction -r {txnumber} | ||
signtransaction -r [{txnumber}] | signtransaction -r [{txnumber}] | ||
// sign a pre-signed/partial transaction (signs for owned private keys) | |||
signtransaction -o {txnumber} | |||
signtransaction -o [{txnumber}] | |||
response [{txnumber},{done|failed}] | response [{txnumber},{done|failed}] |
Revision as of 18:13, 25 July 2011
New Transaction is an proposal for a new extendable method of creating transactions.
Each new transaction is defined by a random txnumber that should be unique globally.
Advanced functions, such as transaction scripts, and importing and exporting can appropriately be done using the group of supporting functions.
Transaction life-cycle
Every New Transaction goes through the following steps. (not always in the same order)
Build
In this stage, a transaction is being built:
- Any feature of the transaction may be modified.
- Users can add, remove, any input, output or script.
Ready
In this stage, only certain features may be modified:
- Only inputs may be changed. (is this correct, or will past signatures be destroyed if we change them?)
- Any other attribute that doesn't effect the existing signatures.
Done
In this stage, the transaction is complete, and would be accepted by the network:
- User still can add inputs, however all the outputs have already been fulfilled, these new inputs will be counted as fees.
- After any change, a 'done' transaction gets automatically demoted to 'Ready' state.
Submitted
In this stage the transaction has been published to the bitcoin network and is in/or is awaiting to be included in a block.
Terms
txnumber is a random string given to every transaction for identification purposes.
pubkey is assumed to be owned by the client that preforms the 'readying' of the transition (build > ready states)
This entire processing is lazy! Bitcoin will automatically fill-out everything just as it dose at-the-moment with the readytransaction stage.
Please not this draft doesn't include all possible error responses.
commands:
/// make a new transaction (1 override) newtransaction newtransaction {name} response {txnumber}
/// add an input to the transaction. (1 overrides) addinput {txnumber} {txid} {pubkey} addinput {txnumber} {txid} {pubkey} {comment} response {txnumber} {inid}
/// add outputs to the transaction (6 overrides) /// add fee to transaction addoutput {txnumber} {amount} {forced|suggested|optional} addoutput {txnumber} {amount} {forced|suggested|optional} {comment} // add change address to transaction addoutput {txnumber} {pubkey} addoutput {txnumber} {pubkey} {comment} // add send outputs addoutput {txnumber} {address} {amount} addoutput {txnumber} {address} {amount} {comment} response {txnumber} {outid} // add many send outputs addoutputlist {txnumber} [{address},{amount}] response {txnumber} [{outid}]
/// remove input or outpus (1 override) remove {txnumber} {inid or outid} remove {txnumber} [{inid or outid}] response {txnumber} droped: {inid or outid} response {txnumber} droped: [{inid or outid}]
/// prints out human readable information about the tranaction shownewtransaction {txnumber} (1 override) response {txnumber} in: [{inid},{address},{amount},(comment)] in total: {amount} out: [{outid},{address},{amount},(comment)] out total: {amount} fee: {amount} size: {readytxn bit} state: {building:ready:done:submitted} shownewtransaction {txid} (1 override) response {txid} in: [{inid},{address},{amount},(comment)] in total: {amount} out: [{outid},{address},{amount},(comment)] out total: {amount} fee: {amount} size: {readytxn bit} block: {block number}
/// demote a transaction (1 override) demotetransaction {txnumber} demotetransaction {txnumber} {build|ready|done} response {txnumber} {building|ready|done}
/// exports a binary encoded transition (4 override) exporttransaction {txnumber} exporttransaction [txnumber] exporttransaction {txid} exporttransaction [txid] response {binary data}
/// import binary encoded transition(s) (1 override) inporttransaction {binary data} inporttransaction [{binary data}] response [{txnumber}]
/// check and complete build translation (1 override) reddytransaction {txnumber} reddytransaction [{txnumber}] response [{txnumber}] {has made changes|no changes needed|not enough coins|invalid transaction}
/// sign ready transaction (6 override) signtransaction {txnumber} signtransaction [{txnumber}] // calls reddytransaction before hand if needed signtransaction -r {txnumber} signtransaction -r [{txnumber}]
// sign a pre-signed/partial transaction (signs for owned private keys) signtransaction -o {txnumber} signtransaction -o [{txnumber}] response [{txnumber},{done|failed}]
/// publish a done transaction to peers (2 override) // submits all 'done' transactions submittransaction -a // submits a single 'done' transaction submittransaction {txnumber} // submits a list of 'done' transaction submittransaction [{txnumber}] response [{txnumber},{txid}]
/// complete transaction from any stage and publish it (1 override) completeransaction {txnumber} response {txnumber} {txid}
/// delete a transaction from local client droptransaction {txnumber} responce dropped: {txnumber}