completerawtransaction RPC #3794

issue sipa openend this issue on March 4, 2014
  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

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-24 12:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me