Question: PSBT and RBF #19481

t-bast commented at 10:40 AM on July 10, 2020: member

Hi all!

As part of the anchor outputs work for Lightning (in the context of eclair), I'm wondering if it's possible to use psbts and the bumpfee RPC or if I'll have to implement a lot of fee bumping code myself outside of bitcoind.

A quick summary of the situation (a lot more details here if you're interested):

we have a "commit tx" that represents the state of the channel
this "commit tx" has an output for CPFP carve-out (called "anchor") that we use to bump the fee (through a "claim anchor tx")

  commit tx
+--------------+
|   vout       |
| +----------+ |
| | output 1 | |
| +----------+ |
|     ...      |
| +----------+ |
| | anchor   | |-------+
| +----------+ |       |         claim anchor tx
|     ...      |       |       +-----------------------------------+
| +----------+ |       |       |   vin               vout          |
| | output n | |       |       | +-------------+   +-------------+ |
| +----------+ |       +------>| | anchor utxo |   | wallet utxo | |
+--------------+               | +-------------+   +-------------+ |
                               | +-------------+                   |
  unrelated tx         +------>| | wallet utxo |                   |
+--------------+       |       | +-------------+                   |
|   vout       |       |       +-----------------------------------+
| +----------+ |       |
| | output 1 | |-------+
| +----------+ |
|     ...      |
| +----------+ |
| | output m | |
| +----------+ |
+--------------+

The bitcoind wallet doesn't have the keys necessary to spend the "anchor"; these are handled by the lightning node. But I'd like to let bitcoind chose what inputs and outputs to add to that transaction to achieve a given feerate.

This looks like a perfect use-case for PSBT:

use bitcoind's walletcreatefundedpsbt to obtain a wallet psbt
create a lightning psbt with only the anchor utxo as input
use joinpsbts to gather all inputs/outputs
use walletprocesspsbt to get signatures for the wallet inputs
add the signature for the anchor input and finalize the psbt

Once that's done, I can publish my "claim anchor tx". However if it still doesn't confirm in time, I'd like to RBF that transaction. But obviously bumpfee will not work out of the box because there's one input that it can't automatically re-sign. What would be really great would be if bumpfee could replace all wallet inputs/outputs to bump the fee (abiding by all the BIP 125 rules) and then return a psbt with all the wallet inputs signed; I would then only need to re-sign the anchor input, finalize the psbt and broadcast it.

IIUC 0.20.0 has taken a first step in that direction (returning a psbt in bumpfee), but it looks like it will only do that with a watch-only wallet, whereas I'd like that behavior with normal wallet too. Does this request make sense, and if so is this being currently worked on?

t-bast added the label Feature on Jul 10, 2020

t-bast commented at 10:05 AM on July 17, 2020: member

@instagibbs would you have some time to enlighten me regarding this (as the author of #16373 you're probably the most relevant point of contact)? Sorry for the ping, hope you don't mind :)

achow101 commented at 3:07 PM on July 17, 2020: member

@t-bast You might be interested in #18654

t-bast commented at 3:51 PM on July 17, 2020: member

Great thanks @achow101, this definitely goes in the right direction for my usecase.

In my case where some inputs are signed by the bitcoind wallet and one input is signed with a lightning priv key, I'll be able to use psbtbumpfee to obtain a psbt where the bitcoind wallet's inputs/outputs will have been modified to bump the fee, and then use the other psbt RPC to complete the psbt into a complete transaction. That's great!

instagibbs commented at 4:05 PM on July 23, 2020: member

So one note is that the Core wallet will have to consider all the transaction inputs as its "own" to make the bump succeed(see feebumper::PreconditionChecks). In the PSBT setting maybe this logic can/should be relaxed. @achow101 ?

t-bast commented at 4:28 PM on July 23, 2020: member

I may be missing edge cases, but it seems to me that as long as the bitcoind wallet has one input that it can modify (and ideally one output or the ability to add a change output) it should be able to do its fee bumping work, right?

instagibbs commented at 4:47 PM on July 23, 2020: member

I'm being descriptive of checks currently made. They may be more strict than necessary.

On Thu, Jul 23, 2020 at 12:28 PM Bastien Teinturier < notifications@github.com> wrote:

I may be missing edge cases, but it seems to me that as long as the bitcoind wallet has one input that it can modify (and ideally one output or the ability to add a change output) it should be able to do its fee bumping work, right?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/19481#issuecomment-663104617, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMAFU4FXF3RS4PNJ6KNGL3R5BQK7ANCNFSM4OWPAXUA .

t-bast commented at 12:17 PM on July 31, 2020: member

Gotcha, but do you think my suggestion makes sense? Or am I missing something?

instagibbs commented at 12:21 PM on July 31, 2020: member

I think it makes sense.

t-bast commented at 2:14 PM on October 14, 2020: member

I've been experimenting with psbtbumpfee on master, and it looks like it's still failing when the tx contains non-wallet inputs (for the reasons described above). @achow101 do you think there is a chance to change that behaviour before 0.21?

instagibbs commented at 2:15 PM on October 14, 2020: member

Feature freeze is ~tomorrow so unlikely unfortunately.

On Wed, Oct 14, 2020, 10:14 AM Bastien Teinturier notifications@github.com wrote:

I've been experimenting with psbtbumpfee on master, and it looks like it's still failing when the tx contains non-wallet inputs (for the reasons described above).

@achow101 https://github.com/achow101 do you think there is a chance to change that behaviour before 0.21?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/19481#issuecomment-708431896, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMAFUZDDEN7KNCZ62YNDP3SKWW47ANCNFSM4OWPAXUA .

t-bast commented at 2:16 PM on October 14, 2020: member

Thanks for the quick reply, too bad! I'll try dipping my toes in bitcoin core code to see if I can implement this myself.

instagibbs commented at 2:18 PM on October 14, 2020: member

Feel free to reach out for help.

On Wed, Oct 14, 2020, 10:17 AM Bastien Teinturier notifications@github.com wrote:

Thanks for the quick reply, too bad! I'll try dipping my toes in bitcoin core code to see if I can implement this myself.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/issues/19481#issuecomment-708433528, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMAFU6PGTN34VM2ZWBTXJTSKWXGZANCNFSM4OWPAXUA .

t-bast commented at 3:11 PM on October 14, 2020: member

It seems to me that the reason why it wasn't completely trivial to implement is this line:

https://github.com/bitcoin/bitcoin/blob/99a1d572eabca89790216b3919a237e07063a376/src/wallet/feebumper.cpp#L188

The feebumper first calculates the old fee, then computes the new one from it and update inputs/outputs accordingly. For non-wallet inputs, we won't have the input amounts cached in the wallet (obviously).

I'm leaning towards adding origFee as an optional input parameter to the psbtbumpfee RPC (and when you have non-wallet inputs, this parameter is in fact mandatory). A caller that works with PSBTs had the finalized PSBT at some point, which allowed him to easily calculate the old fee, so he should be able to provide that parameter to the RPC.

Do you think it's a reasonable way to implement this?

instagibbs commented at 5:29 PM on October 14, 2020: member

Remember to ping me in a couple weeks, forgot to mention I don't have time right now...

t-bast commented at 4:05 PM on October 15, 2020: member

Posting my findings, no rush to look at them. What's blocking here is really the overall support for non-wallet inputs, and it's needed in many places across the codebase. For instance, even walletcreatefundedpsbt fails with a non-wallet input at this line:

https://github.com/bitcoin/bitcoin/blob/0d22482353752ebfb11aa29f4b26113b817a448a/src/wallet/wallet.cpp#L2469

We need to either provide the (trusted) input amount to the RPC and then propagate it mostly everywhere, or we need to be able to fetch non-wallet utxo amounts from somewhere. In both cases it looks unfortunately non-trivial...

t-bast commented at 6:22 PM on January 28, 2021: member

I'd be very interested to know if someone is looking into this issue, as it's clearly too much for someone like me who doesn't know the wallet codebase.

Right now, I'm forced to do quite horrible hacks to implement CPFP/RBF in lightning and I believe that any application that deals with non-wallet inputs will run into the same problems (which is probably why most lightning implementations re-implemented a bitcoin wallet from scratch instead of using bitcoin-core's built-in one). I understand this may be a lot of work, but it seems beneficial to many projects in the long run.

laanwj added the label Questions and Help on Jan 28, 2021

t-bast commented at 2:19 PM on February 28, 2022: member

This has become much better with #23201 and future work (https://github.com/bitcoin/bitcoin/pull/23202), closing this issue.

t-bast closed this on Feb 28, 2022

DrahtBot locked this on Feb 28, 2023