Raw Transaction RPC

gistfile1.md

#New RPC commands

Implementation: bitcoin/bitcoin#1456

listunspent [minconf=1] [maxconf=999999]

Returns an array of unspent transaction outputs in the wallet that have between minconf and maxconf (inclusive) confirmations. Each output is a 5-element object with keys: txid, output, scriptPubKey, amount, confirmations. txid is the hexadecimal transaction id, output is which output of that transaction, scriptPubKey is the hexadecimal-encoded CScript for that output, amount is the value of that output and confirmations is the transaction's depth in the chain.

createrawtransaction [{"txid":txid,"vout":n],...] {address:amount,...}

Create a transaction spending given inputs (array of objects containing transaction outputs to spend), sending to given address(es). Returns the hex-encoded transaction in a string. Note that the transaction's inputs are not signed, and it is not stored in the wallet or transmitted to the network.

Also note that NO transaction validity checks are done; it is easy to create invalid transactions or transactions that will not be relayed/mined by the network because they contain insufficient fees.

decoderawtransaction <hex string>

Returns JSON object with information about a serialized, hex-encoded transaction.

getrawtransaction <txid> [verbose=0]

If verbose=0, returns serialized, hex-encoded data for transaction txid. If verbose is non-zero, returns a JSON Object containing information about the transaction. Returns an error if <txid> is unknown.

signrawtransaction <hex string> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...]

Sign as many inputs as possible for raw transaction (serialized, hex-encoded). The first argument may be several variations of the same transaction concatenated together; signatures from all of them will be combined together, along with signatures for keys in the local wallet. The optional second argument is an array of parent transaction outputs, so you can create a chain of raw transactions that depend on each other before sending them to the network. Third optional argument is an array of base58-encoded private keys that, if given, will be the only keys used to sign the transaction. Returns json object with keys:

hex : raw transaction with signature(s) (hex-encoded string)
complete : 1 if rawtx is completely signed, 0 if signatures are missing.

If no private keys are given and the wallet is locked, requires that the wallet be unlocked with walletpassphrase first.

sendrawtx <hex string>

Submits raw transaction (serialized, hex-encoded) to local node and network. Returns transaction id, or an error if the transaction is invalid for any reason.

Motivating use cases

##Multisignature transactions

Funds are sitting in one or more multisignature transaction outputs, and it is time to gather signatures and spend them.

Assumption: you know the multisignature outputs' {txid, outputNumber, amount}.

1. Create a raw transaction to spend, using createrawtransaction.
2. Use signrawtransaction to add your signatures (after unlocking the wallet, if necessary).
3. Give the transaction to the other person(s) to sign.
4. You or they submit the transaction to the network using sendrawtransaction.

I don't imagine anybody but very-early-adopters or ultra-geeks will do this by calling these RPC methods at a command-line. They are really intended for people writing services on top of bitcoind. The service should be careful to include an appropriate transaction fee, or the sendrawtransaction method is likely to fail (either immediately or, worse, the transaction will never confirm).

##Debugging/testing

These lower-level routines will be useful for debugging and testing; listunspent gives a detailed list of the state of the wallet, and sendrawtx might be used to test double-spend-handling.

##Input selection control

You want fine-grained control over exactly what coins in the wallet are spent.

1. Get a list of not-yet-spent outputs with listunspent
2. Create a transaction using createrawtransaction
3. Apply signatures using signrawtransaction
4. Submit it using sendrawtransaction

Note that you are responsible for preventing accidental double-spends.

##Control over payment of fees and/or transaction re-transmission

You want to specify, on a per-transaction basis, how much to pay in fees. Or you want to implement your own policy for how often transactions that are not immediately included in blocks are re-broadcast to the network.

1. Maintain a list of not-yet-spent, confirmed outputs with listunspent (refreshed every time a new block is found, using the -blocknotify feature).
2. Create a transaction with exactly the amount of fees you wish with createrawtransaction
3. Apply signatures using signrawtransaction
4. Submit it with sendrawtransaction
5. Re-submit it periodicially with sendrawtransaction if it does not get into a block.

is the hex encoding defined anywhere?