We (at <a href="http://www.ziftr.com/">ziftr</a>) are working on a cryptocurrency API and may want to alter the RPC interface in our copy of the codebase. We think that the alterations to the RPC interface that we would like to make may be useful to others, and we hope that any work we do will be available to the bitcoin community. Here we are outlining the proposal to get some feedback about how one could implement these changes.
Essentially, we want to split up the work that is done in <tt>signrawtransaction</tt> so that the different parts can be used individually. This will make the RPC calls more modular, offering more flexibility to any developer who is using the daemon's RPC interface.
The basic idea is that <tt>signrawtransaction</tt> currently has to calculate the hashes that need to be signed, sign them with the appropriate private keys, and then bundle everything up into a raw transaction. We would like to make it so that each of these could be done separately. For us, this means the middle step, the calculation of signatures, being done on a different device.
The first change we would like to make is to add an RPC method call named <tt>getdatatosign</tt>. This takes the raw transaction and a few optional parameters, and calculates all data that must be signed. The returned value from this could be fed directly to <tt>signrawtransaction</tt>.
// Creates an array of data that needs to be signed
<pre> getdatatosign "hexstring" ( [{"txid":"id", "vout":n, "scriptPubKey":"hex", "redeemScript":"hex"}, ...] sighashtype ) </pre>
Return data format:
<pre> [ { "txid":"id", "vout":n, "scriptPubKey":"hex", "redeemScript":"hex", /* Only present if p2sh. */ "tosign":"hex", "pubkey": "hex", /* Present if not pay to pub key, which is most of the time. */ "r":"", "s":"" } ] </pre>
// If r and s are filled in, possibly by someone else who owns the keys, // then this can just bundle them up into the transaction ready to send. // If they don't exist, the daemon will look for the appropriate // keys to sign with and fill them in (or use the given private keys). // The datatosign, r, and s fields are not required to be keys in the // JSON object, so that this change is backwards compatible.
<pre> signrawtransaction "hexstring" ( [{"txid":"id", "vout":n, "scriptPubKey":"hex", "redeemScript":"hex", "datatosign":"hex", "r":"hex", "s":"hex" }] ["privatekey1",...] sighashtype ) </pre>
<pre> { "hex": "0100000001ba8bb652d537989726d242bf99153fb4e5de262ecbaa975ab1715abbb0597fe7000000006b483045022100e6db653e65c48838fc7d58f7696b20bb74d27b315a0a3cba3e80f6b9e5fc0d3402207a2613efe02663d8f8933922a328b8333d0acd31d43c738e2fbcc58d3f3ace87012102c1e842bd2c8314f0699d606a1c712e26abc9836d6f76fc64ee3f73f31b753945ffffffff0110a8a600000000001976a9142badcf56c4fb168773ff661606e5c9b8eb55d5fd88ac00000000", "complete": true } </pre>
Essentially, this just exports some of the work that currently is done in <tt>signrawtransaction</tt> to a second method, and <tt>signrawtransaction</tt> can still be used as it was before, but now it can make a call to <tt>getdatatosign</tt> to do the first part of its work.
These may not be the optimal method names, parameters, or return values for such methods, but hopefully they convey the proposal. The goal is that this will make the rpc calls more modular, so that developers will have more flexibility in their applications. In particular, it will make it easier for applications where the signing is to be done on a different device.
I'm sure there are details that need to be worked out, but I think the core idea here is a good one. Please let me know if there is anything here you think can be improved! Any feedback on this proposal would be greatly appreciated.
