Lnd: [Request] Command to anchor funding transactions with extra fees

[junderw]

Problem: Funded channel with small fee. Confirmation doesn't occur for weeks (some block explorers re-broadcast transactions too)... This command will allow a user to add more fee after the fact.

Ideal (Does this require change in protocol spec? idk):

1. Set sequence for all inputs in the funding transaction as < MAX - 1.
2. Fund normally.
3. Fee too low.
4. Run this command, and it will use the same inputs, and decrease the change output to increase fees. The partner will cooperate with signing the refund transaction for the same channel. (Will this fail? Does it break protocol spec?)

Less than ideal:

1. When possible ensure that all funding transactions will always have a change output.
2. Fund normally.
3. Fee too low.
4. Run this command which will calculate the missing fees from the funding transaction to match the given sat_per_byte, then it will create a transaction with that change output, and add the missing fees from the funding transaction on top of the dependent transaction. (causing CPFP)

• This will allow the user to speed up confirmation on funding transactions.
• This will allow the user to risk using lower confirmation targets since they can use this afterward when necessary.
• This will NOT allow the user to revert a funding transaction. (the output scripts must remain the same.)

[jamesob]

I'd like to start working on this, but it'd be nice to get some feedback on an approach:

I think initially we should go with the "less than ideal" CPFP solution because it doesn't require any protocol changes or nasty hacks like somehow interpreting rebroadcasts of open_channel with say an incremented temporary_channel_id (if that'd even be feasible - sounds pretty bad).

We can paper over the fact that CPFP is more or less a temporary bandaid by introducing an rpc/lncli command called fundingbump <temporary_channel_id> [<new_sat_per_byte>] or something along those lines. Once (and if) we can facilitate replace-by-fee, add some flag like --method={rbf,cpfp} which has some sensible default.

If maintainers agree that the CPFP approach outlined in OP is an acceptible stopgap and my approach sounds okay, I'll get coding.

[junderw]

ACK CPFP approach for now.

RBF is kind of messy...

[Roasbeef]

Agreed that the CPFP route is easier for now, and also has less edge cases. Rather than make it specific to funding transactions, I think we can instead make it fully generalized. So maybe a command like: lncli feebump cpfp --outpoints=op1, op2, op3 --fee_rate=X. Notice that it takes a list of outpoints, so one could even anchor down a series of transactions with a single child.

One Q with this method would be how to interpret the --fee_rate param. One interoperation would be the new _cumulative_ package should have that particular fee rate. Another would be that this should just be the feerate of the child transaction, so it's up to the caller to properly compute this value.

[jamesob]

Yup, agree that a more general feebump mechanism that'd allow multiple parent inputs seems very useful. I'll go that route.

[rashlab]

Great, and important! any estimate as to when such feature could be available, and what could be a temporary solution?? (my funding transaction is stuck, miners "low priority"...). Thanks,

[jamesob]

@rashlab I'm working on this at the moment, but I'm still getting to know lnd so I might be kinda slow. I'd say I'll have a PR up in the next two weeks?

[jamesob]

Needless to say, I've fallen down on the job here - my apologies for the bad estimate. I took a crack at this, but not sure I'll have the time and/or skill to continue. Got stuck trying to figure out how to retrieve the outpoints to bump from the wallet and construct a txn using them as inputs.

Here's a rough outline of the task:

• Take in a list of txids ([]string?) to bump and a desired net-effective s/B feerate f (feeRate)
  
  
  
  • Add method to rpcServer
  
  
• For each txid, verify that it has a change output owned by us
• Create a txn spending those outputs as inputs, with a single output back to us
  
  
  
  • Construct with a feerate which will raise package (parent+child txns) net-effective feerate to f
  
  
  • Get size of all parent txns (?) and then do weighted average calc including expected size
    
    of child to get feerate.
  
  
• Broadcast txn (WalletController.PublishTransaction)
• Store txn somewhere?

[halseth]

The sweeper currently being worked on by @joostjager will be possible to extend to handle this.

[Roasbeef]

Got stuck trying to figure out how to retrieve the outpoints to bump from the wallet and construct a txn using them as inputs.

The assumption is that the outpoints would be passed over to the RPC, from there, there're calls to the WalletController to allow you to get things like the script and fee rate needed to sign for the change address.

[Roasbeef]

Store txn somewhere?

The PublishTransaction method will automatically store the transaction before publishing. On restart, it'll re-publish them as necessary if they haven't been mined.