I think if we apply this presigned fee multiplier idea to HTLC spends, we can prevent replacement cycles from happening.
We could modify HTLC scripts so that *both* parties can only spend the HTLC via presigned second-stage transactions, and we can always sign those with SIGHASH_ALL. This will prevent the attacker from adding inputs to their presigned transaction, so (AFAICT) a replacement cycling attack becomes impossible. The tradeoff is more bookkeeping and less fee granularity when claiming HTLCs on chain. On Fri, Oct 20, 2023 at 11:04 AM Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrote: > > As I have suggested before, the correct way to do pre-signed transactions > > is to > > pre-sign enough *different* transactions to cover all reasonable needs for > > bumping fees. Even if you just increase the fee by 2x each time, > > pre-signing 10 > > different replacement transactions covers a fee range of 1024x. And you > > obviously can improve on this by increasing the multiplier towards the end > > of > > the range. > > To be clear, when I say "increasing the multiplier", I mean, starting with a > smaller multiplier at the beginning of the range, and ending with a bigger > one. > > Eg feebumping with fee increases pre-signed for something like: > > 1.1 > 1.2 > 1.4 > 1.8 > 2.6 > 4.2 > 7.4 > > etc. > > That would use most of the range for smaller bumps, as a %, with larger % > bumps > reserved for the end where our strategy is changing to something more > "scorched-earth" > > And of course, applying this idea properly to commitment transactions will > mean > that the replacements may have HTLCs removed, when their value drops below the > fees necessary to get those outputs mined. > > Note too that we can sign simultaneous variants of transactions that deduct > the > fees from different party's outputs. Eg Alice can give Bob the ability to > broadcast higher and higher fee txs, taking the fees from Bob's output(s), and > Bob can give Alice the same ability, taking the fees from Alice's output(s). I > haven't thought through how this would work with musig. But you can certainly > do that with plain old OP_CheckMultisig. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
