-
Notifications
You must be signed in to change notification settings - Fork 901
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.
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
dual-fund: no feestep #4648
dual-fund: no feestep #4648
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack 2263a7c
blocked on merge of rustyrussell/lnprototest#16 (updates to rbf tests in protocol tests) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack 2263a7c
Depending on ElementsProject#4648 Signed-off-by: Vincenzo Palazzo <[email protected]>
2263a7c
to
a82baae
Compare
We were getting off-by-one for the total amount that the change is for, since it rounds the fee *down*, independent of the total weight of the entire tx. We fix this by using the diff btw the fee of the total weight (w/ and w/o the change output)
a82baae
to
8084926
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack 8084926
ERROR tests/test_db.py::test_backfill_scriptpubkeys - OSError: [Errno 39] Dir...
The github action look a like a unluck run
Using a 'feestep' is more restrictive than you'd want, instead we enforce that the next feerate must be at least 1/64th more than the last, but put no upper limit on it Includes update to lnprototest changes Contributed-By: Vincenzo Palazzo <[email protected]> Changelog-EXPERIMENTAL: Protocol: Replaces init_rbf's `fee_step` for RBF of v2 opens with `funding_feerate_perkw`, breaking change
8084926
to
26f9692
Compare
ACK 26f9692 |
The
fee_step
portion of the spec was cute but not really servicable, especially given that there's no guarantee that bumping the fee by 25% will put you over the required min_relay fee bump.Instead, we just let the opener specify a new feerate, and require that it's at least 1/64th more than the last "successful" one (that means we've swapped tx_sigs for it successfully, it might still fail to broadcast).
Includes a fix for estimating the additional fee that a change output adds to the tx; we weren't considering the total weight which means it was possible to get off-by-one errors on the rounding.
This is a breaking change with prior dual-funding implementations.