Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be
performed by either side of the closure, as the HTLCs are now, at max, only signed
SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the
broadcaster.
I don't think its really viable to walk that change back to fix this, as it also fixed plenty of
other issues with channel usability and important edge-cases.
I'll highlight that fixing this issue on the lightning end isn't really the right approach generally
- we're talking about a case where a lightning counterparty engineered a transaction broadcast
ordering such that miners are *not* including the optimal set of transactions for fee revenue. Given
such a scenario exists (and its not unrealistic to think someone might wish to engineer such a
situation), the fix ultimately needs to lie with Bitcoin Core (or other parts of the mining stack).
Now, fixing this in the Bitcoin Core stack is no trivial deal - the reason for this attack is to
keep enough history to fix it Bitcoin Core would need unbounded memory. However, its not hard to
imagine a simple external piece of software which monitors the mempool for transactions which were
replaced out but which may be able to re-enter the mempool later with other replacements and store
them on disk. From there, this software could optimize the revenue of block template selection,
while also accidentally fixing this issue.
Matt
On 10/20/23 2:35 PM, Matt Morehouse via bitcoin-dev wrote:
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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
