Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add cpfp-bump-fees API #1783

Merged
merged 7 commits into from
May 4, 2023
Merged

Add cpfp-bump-fees API #1783

merged 7 commits into from
May 4, 2023

Conversation

t-bast
Copy link
Member

@t-bast t-bast commented Apr 30, 2021 •
edited
Loading

We add a cpfpbumpfees API that lets you bump the fees of a package of unconfirmed transactions.

This lets node operators ensure their funding txs confirm before they hit the 2016 funding timeout (lightning/bolts#839). It's also very useful when you have a long chain of unconfirmed funding transactions and/or mutual close transactions and want to bump them all at once.

If for example a node has the following set of unconfirmed transactions:

+-------------+
| Funding Tx1 |----------> channel output
| txid=111... |-----+
+-------------+     |                +-------------+
                    | change output  | Funding Tx2 |----------> channel output
                    +--------------->| txid=222... |-----+
                                     +-------------+     |                +-------------+
                                                         | change output  | Funding Tx3 |----------> channel output
                                                         +--------------->| txid=333... |----------> change output (index=1)
                                                                          +-------------+
+-------------+
| Funding Tx4 |----------> change output (index=0)
| txid=444... |----------> channel output
+-------------+

+------------------+
| Mutual Close Tx1 |----------> remote output
| txid=555...      |----------> local output (index=1)
+------------------+

+------------------+
| Mutual Close Tx2 |----------> local output (index=0)
| txid=666...      |----------> remote output
+------------------+

Assuming 40 sat/byte would be a good feerate for quick confirmation, the node operator can use the following command to get all these transactions confirmed quickly:

./eclair-cli cpfpbumpfees --targetFeerateSatByte=40 --outpoints=333...:1,444...:0,555...:1,666...:0

NB: this call must be made manually by the node operator, who needs to figure out which outpoints belong to him (which should be fairly easy using existing APIs). A good tree visualization of wallet unconfirmed transactions could be a useful addition to help node operators see the state of their unconfirmed packages and select what they want to bump.

@t-bast t-bast requested review from pm47 and sstone April 30, 2021 15:51
@viaj3ro
Copy link

viaj3ro commented May 3, 2021 •
edited
Loading

This seems reasonable to me. TargetFeerate will be used by the node as an input to calculate the necessary fee (to reach this target for the CPFP tx) dependent on the individual feerate of the stuck txs?

Would be a nice to have if APIs were available that make CPFPing simple to implement in RTL for example. But works for me as described already.

@t-bast
Copy link
Member Author

t-bast commented May 3, 2021

TargetFeerate will be used by the node as an input to calculate the necessary fee (to reach this target for the CPFP tx) dependent on the individual feerate of the stuck txs?

The node will ensure the whole package of unconfirmed txs pays a fee at that feerate.
So the flow is:

  1. Check what feerate would get a transaction included in N blocks (where N is your target). For example, 50 sat/byte looks good.
  2. List the outpoints of the txs you want to get confirmed.
  3. Call this CPFP API with targetFeerate=50 sat/byte and the list of outpoints, and it will be as if these txs were all paying 50 sat/byte

@dscotese
Copy link
Contributor

"I'd like to get it merged, if it's useful to you please add a comment on the PR to make it known!" -t-bast.

Let it be known that I think its useful. Adding code "to figure out which outpoints belong to him (which should be fairly easy using existing APIs)" would make it even better.

@t-bast
Copy link
Member Author

t-bast commented Mar 30, 2023

Rebased on master. @pm47 @sstone I think this is a very useful tool for node operators, especially in high fee environments such as what we've seen recently. It's not an overly complex addition either, it's worth the review time!

t-bast added 3 commits April 14, 2023 09:47
@t-bast
Bitcoin client allows CPFP
0cf396e 
Our bitcoin client can create a CPFP tx that spends unconfirmed outpoints
that belong to our wallet.

Note that this only works for wallet outpoints, not outpoints using lightning
pubkey scripts.
@t-bast
Add API for CPFP fee bumping
1a4a9a9 
Add API to let node operators initiate CPFP.
It's up to the node operator to select which outpoints to spend and ensure
that they are spendable by the bitcoind wallet.
@t-bast
Add documentation section
486d186 
Explain how to configure bitcoind to ensure you'll be able to use CPFP without
hitting unconfirmed transaction chains mempool limits.
sstone
sstone reviewed Apr 26, 2023
View reviewed changes
Copy link
Member

@sstone sstone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a few nits.
It could also be useful to add the option to RBF the spend-local-anchor tx ?

pm47
pm47 reviewed May 4, 2023
View reviewed changes
Copy link
Member

@pm47 pm47 left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from the points raised by @sstone it LGTM.

@t-bast
Copy link
Member Author

t-bast commented May 4, 2023

It could also be useful to add the option to RBF the spend-local-anchor tx ?

This is a completely separate concern. Also, we already have code to automatically RBF those transactions, I don't think this is necessary?

@t-bast t-bast requested a review from sstone May 4, 2023 12:58
@t-bast t-bast merged commit ee63c65 into master May 4, 2023
@t-bast t-bast deleted the cpfp-engine branch May 4, 2023 16:20
t-bast added a commit that referenced this pull request Jun 16, 2023
@t-bast
Update for release 0.9.0
5639ffc 
This release introduces a few API changes:

- `audit` now accepts `--count` and `--skip` parameters to limit the
  number of retrieved items (#2474, #2487)
- `sendtoroute` removes the `--trampolineNodes` argument and
  implicitly uses a single trampoline hop (#2480)
- `sendtoroute` now accept `--maxFeeMsat` to specify an upper bound
  of fees (#2626)
- `payinvoice` always returns the payment result when used with
  `--blocking`, even when using MPP (#2525)
- `node` returns high-level information about a remote node (#2568)
- `channel-created` is a new websocket event that is published when
  a channel's funding transaction has been broadcast (#2567)
- `channel-opened` websocket event was updated to contain the final
  `channel_id` and be published when a channel is ready to process
  payments (#2567)
- `getsentinfo` can now be used with `--offer` to list payments sent
  to a specific offer
- `listreceivedpayments` lists payments received by your node (#2607)
- `closedchannels` lists closed channels. It accepts `--count` and
  `--skip` parameters to limit the number of retrieved items as well
  (#2642)
- `cpfpbumpfees` can be used to unblock chains of unconfirmed
  transactions by creating a child transaction that pays a high fee
  (#1783)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pm47 pm47 pm47 left review comments

@sstone sstone sstone approved these changes

Assignees
No one assigned
Labels
Optech Make Me Famous!
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@t-bast @viaj3ro @dscotese @sstone @pm47