Consider unconfirmed unspent outputs from external wallet as safe for spending for "sendtoaddress" and "fundrawtransaction" RPC #17936

issue FrancisPouliot opened this issue on January 15, 2020
  1. FrancisPouliot commented at 9:46 PM on January 15, 2020: none

    Is your feature request related to a problem? Please describe.

    In the context of creating a sophisticated wallet management application, a Bitcoin exchange wants to send unconfirmed funds that he knows are safe because they are from an external wallet under its control. It is crucial that this these transactions be confirmed as soon as possible. Not being able to spend the unconfirmed funds effectively doubles the transaction time.

    The developpers of this wallet management solution are using the Bitcoin Core RPC. They would prefer to continue relaying on Bitcoin Core to create the transaction and fund it with the coinselection of Bitcoin Core. As such, they want to keep using the "sendtoaddress" RPC.

    However, it would appear that Bitcoin Core considers unconfirmed outputs that are from an external wallet as not "safe" and does not include them in the coin selection when using the "sendtoaddress" and "fundrawtransaction" RPC.

    I believe that this is a well-intended policy to protect some users from themselves, and that it assumes that advanced users will be able to bypass it by using "createrawtransaction". However, the degree of complexity of using "createrawtransaction" is significantly higher than "sendtoaddress" and can actually make it more likely to do a mistake. In addition, using the wallet RPC already denotes some degree of sophistication.

    A few wallets, for example Electrum, allows users to spend unconfirmed funds. This has been useful personally for me on many occasion. However, when building applications, one cannot rely on such wallets and it is always preferable to use Bitcoin Core wallet itself, in my opinion.

    I think a good compromise would be to have a configuration (.conf) that allows unconfirmed outputs to be included in the "sendtoaddress" and "fundrawtransaction" RPC calls.

    Describe the solution you'd like

    A configuration that allow unconfirmed outputs to be included in the "sendtoaddress" and "fundrawtransaction" RPC calls.

    Another option would be to add a boolean flag (default=false) like "allow_unconfirmed" in the RPC on a per-call basis.

    Describe alternatives you've considered Using createrawtransaction

    References

    https://github.com/bitcoin/bitcoin/blob/af05bd9e1e362c3148e3b434b7fac96a9a5155a1/src/wallet/rpcwallet.cpp#L2835

    https://github.com/bitcoin/bitcoin/blob/ac61ec9da6793f00b29ba11f784b9b1c3ae662e9/src/wallet/wallet.h#L556

    \"safe\" : xxx (bool) Whether this output is considered safe to spend. Unconfirmed transactions from outside keys and unconfirmed replacement transactions are considered unsafe and are not eligible for spending by fundrawtransaction and sendtoaddress.

  2. FrancisPouliot added the label Feature on Jan 15, 2020
  3. FrancisPouliot commented at 8:58 PM on January 17, 2020: none

    N.B.: this would also make it possible for people to do CPFP easily via the RPC interface by sending the entire balance to themselves.

  4. maflcko added the label Wallet on May 7, 2020
  5. krtschmr commented at 9:47 PM on October 27, 2020: none

    allow_unconfirmed or similar option would be very useful. you can use any bitcoin node to receive payments but instantly forward them to your cold wallet and thus have (almost) zero balance on your hotwallet which is exposed to the internet. a great security feature.

    i think best way would be a flag in the sendtoaddress method call where we can say include_unconfirmed=true.

  6. pinheadmz assigned achow101 on Apr 27, 2023
  7. achow101 commented at 9:17 PM on April 30, 2023: member

    Such inputs can be manually selected when using fundrawtransaction or walletcreatefundedpsbt. However allowing coin selection to select such inputs introduces a potential footgun and we generally are not interested in doing that.

    The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

    Closing due to lack of interest. Pull requests with improvements are always welcome.

  8. achow101 closed this on Apr 30, 2023

  9. bitcoin locked this on Apr 29, 2024

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: 2026-04-21 15:14 UTC

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