Da2ce7:New Transaction: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Da2ce7 (talk | contribs)
added lists for processing
Da2ce7 (talk | contribs)
updated intro
Line 1: Line 1:
''make new transaction''
''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)
=== States: ===
''build'' this state a transaction doesn't need to fulfil any rules. The user just defines what she wants in the transaction.<br />
''ready'' this state is after a client that has (or knows of the), private keys checks the transaction, checking and adding more inputs or change output if necessary.<br />
''done'' the transaction has been signed by and all the inputs are vaild.<br />
''submited'' the transaction has successfully publicly announced.


'''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 (4 override)
   /// 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}