About (not) dying on the dynamic feebumping hill

[darosior]

Given that in the past 2 years we could not find reasonable workarounds to the pinning vectors of pre-signing revocation transactions with ANYONECANPAY [0] and sponsoring via RBF by adding new inputs [1], releasing the first version of Revault with a mechanism for dynamic fee-bumping would cause more harm than good. Instead, we presign a set of Cancel transactions in advance at a given distribution of feerates (say, 20sats/vb, 100sats/vb, 200sats/vb, 500sats/vb and 1000sats/vb). For the Emergency, we presign it at an enormous feerate in advance (1000sats/vb) since it's not supposed to be used.

It's conceptually a reduction in security, as if the market feerate gets above 1000sats/vb at any point in time in the future after a v0 deployment of Revault all bets are off regarding the enforceability of the policies or the Emergency deterrent on this deployment (apart if it was reset with new parameters in the meantime).

Another downside is that it prevents the anti fee sniping protection that i projected to implement by using the fee-bumping inputs' nSequence. We now have transactions that pay a lot of fee and can end up on the network without any such protection (since they are presigned you cant set an appropriate timelock).

On the other hand, this helps a lot with some other things:

• No need to allocate fee bumping reserves, nor the need for the complexity of managing those reserves
• There was a very slight perverse incentive to wait before broadcasting the Cancel transactions, as its fees were mostly paid from single-owned coins (feebumping reservers). They are now paid from the shared coins.
• This closes #83, as we don't have this concern anymore with SIGHASH_ALL.

Fixes #114

[0] Mentioned for instance here in the third section. [1] https://github.com/bitcoin/bitcoin/pull/23121

[kloaec]

extra considerations:

• need to sign multiple "fee versions" of the security txs, so the hardware wallet may take some time to do its job
• more granularity decreases wasted fees, but increases number of security transactions signatures. Not too much of an issue as security transactions aren't supposed to be needed unless under attack (so wasting some fees is a lesser issue)
• SO MUCH SIMPLER <3

I feel so sorry for all the work that the team put into the feebumping strategy, WT reserves, optimizations etc, to end up with such a specific attack. Hopefully this work can be reused in the future!

[darosior]

Worth mentioning, covenants (even the most basic ones) would help here. Combined with Taproot you could have N different Cancel transactions for a cost of log(N) in the witness script size and a cost of 0 in added communications.

Actually, you could have Cancel transactions with a feerate up to the value of the vault itself so you don't need dynamic feebumping anymore. But then it allows any party with knowledge of the Script to burn the funds (or if you add a pubkey challenge anyone taking part in the contract). EDIT: actually you could add a timelock. So you can say if after 90% of the timelock expired, burn everything to fees. But then you skew miner incentives.

[JSwambo]

Nice! I just have one suggestion to update introduction.md too. Can you add this to the end of the file:

"Since Cancel TXs may (or may not) occur frequently, it is important to minimise their feerates while still ensuring timely confirmation. The best solution currently is to prepare multiple variants of the same Cancel TX with a broad distribution of feerates, from typical to extreme and with many in-between. At the time of broadcast, the one with the appropriate fee should be selected."

[darosior]

Thanks, i knew i had forgotten something!

------- Original Message ------- Le vendredi 18 février 2022 à 11:47 AM, JSwambo @.***> a écrit :

Nice! I just have one suggestion to update introduction.md too. Can you add this to the end of the file:

"Since Cancel TXs may (or may not) occur frequently, it is important to minimise their feerates while still ensuring timely confirmation. The best solution currently is to prepare multiple variants of the same Cancel TX with a broad distribution of feerates, from typical to extreme and with many in-between. At the time of broadcast, the one with the appropriate fee should be selected."

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.***>

[darosior]

TODO:

• [x] check that we respect the replacement rules for all possible sizes
• [ ] increase the feerates a bit I don't think it's justified, and it is not specified here.
• [ ] Apply the message serialization changes There was none actually
• [x] Update introduction.md

[darosior]

cc @JSwambo, @edouardparis. This was implemented and is now ready for final review before merging.