completerawtransaction RPC #3794

1. 
   sipa commented at 3:13 pm on March 4, 2014: member

   Right now, the wallet API can be used either at high level (use the wallet both for tracking inputs, building transactions, choosing inputs, signing, broadcasting) or at a high level (do everything yourself, optionally use the input tracking and transaction building code).

   It would be very useful to use the coin selection code of the wallet too but still have control over raw transactions. That’s why I propose a completerawtransaction RPC, which takes an unsigned partial raw transaction (with potentially more outputs than inputs), and adds inputs and change outputs as necessary to make it a fully policy compliant transaction. It doesn’t sign or broadcast, as that can be done through signrawtransaction and sendrawtransaction.

2. sipa added the label Feature on Mar 4, 2014
3. sipa added the label Wallet on Mar 4, 2014
4. 
   ghost commented at 3:16 pm on March 4, 2014: none

   This would be an excellent addition because creating raw transactions by hand is currently over complex and error prone. Taking advantage of code to select inputs etc would be ideal. :+1:
5. 
   laanwj commented at 3:23 pm on March 4, 2014: member

   Sounds useful. One application would be issuing transactions which re-use inputs of a prior transaction to invalidate that transaction, without having to build the entire transaction yourself.
6. 
   kjj2 commented at 3:26 pm on March 4, 2014: none

   I looked at this a while back. My goal was to add raw versions of sendtoaddress and sendmany. Maybe rawtoaddress and rawmany

   They both have problems and would need major refactoring. sendmany, for example, kicks off a chain of function calls with nearly all of the work happening at or near the bottom.

   It would be easy (but ugly) to add a flag to most of the calls, and a reference for letting the raw transaction percolate back up.

   A better solution, in my opinion, would be to refactor those calls. sendtoaddress would first call a stack that returns an unsigned transaction, then call a second stack that signs it and commits (wallet, memporypool, relay, etc). The raw version would instead return the hex to the RPC layer.

   http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/12/13#l1386951924

7. 
   jgarzik commented at 3:30 pm on March 4, 2014: contributor

   +1
8. 
   sipa commented at 3:33 pm on March 4, 2014: member

   Yes, I think the correct way is have the backend code mimick the steps in the raw transaction API, and have separate methods for building a transaction with outputs, one to add inputs/change, one to sign, and one to commit/broadcast.

   The high-level RPCs (sendtoaddress, sendmany, …) would then call these with specific options.

9. 
   jgarzik commented at 3:40 pm on March 4, 2014: contributor

   Inputs to an RPC as it seems useful to me (which may or may not match your idea):

   • a list of prevouts
   • a list of as-yet-unused keys
   • a list of output targets and amounts

   Then the “transactions assistant” figures out fee and change, and produces a single raw transaction.

10. 
    sipa commented at 3:56 pm on March 4, 2014: member

    From #bitcoin-dev, redacted:

    • < sipa> jgarzik: i’d like to see things split up in 4 steps: 1) build your outputs (and potentially inputs you certainly want to use) manually 2) find inputs + change to make it a full but unsigned transactions 3) sign that transaction 4) send/commit that transaction to wallet
    • < sipa> jgarzik: for 1) the parameters are outputs/amounts and potentially manual prevouts
    • < sipa> jgarzik: for 2) the parameters are a set of unspent outputs
    • < sipa> sorry, a set of unspent outputs + a keypool for sending change to
    • < sipa> for 3) the parameters are a keystore
11. 
    jprichardson commented at 4:45 am on March 14, 2015: none

    Yep, this sounds great. Has there been any progress on this? Anyway that I can help?
12. 
    jonasschnelli commented at 8:01 am on March 14, 2015: contributor

    I think this feature request should be solved when #5503 goes in. 5503 is marked for 0.11.
13. 
    jonasschnelli commented at 8:07 am on March 14, 2015: contributor

    @jprichardson You can help by testing #5503.
14. laanwj closed this on Feb 16, 2016

    ---

15. 
    laanwj commented at 3:13 pm on February 16, 2016: member

    fundrawtransaction exists now.
16. DrahtBot locked this on Sep 8, 2021

Contributors
sipa ghost laanwj kjj2 jgarzik jprichardson jonasschnelli

Labels
Feature Wallet