On Fri, Oct 20, 2023 at 10:58:32PM -1000, David A. Harding wrote: > On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: > > The basic problem here is after the HTLC-timeout path becomes spendable, > > the > > HTLC-preimage path remains spendable. That's bad, because in this case > > we want > > spending the HTLC-preimage - if possible - to have an urgency attached > > to it to > > ensure that it happens before the previous HTLC-timeout is mined. > > > > So, why can't we make the HTLC-preimage path expire? > > If the goal is to ensure the HTLC-preimage should be mined before an > upstream HTLC-timeout becomes mineable, then I don't think a consensus > change is required. We can just make the HTLC-preimage claimable by anyone > some time after the HTLC-timeout becomes mineable. > > For example, imagine that Alice offers Bob an HTLC with a timeout at block > t+200. Bob offers Carol an HTLC with a timeout at block t+100. The > Bob-Carol HTLC script looks like this: > > If > # Does someone have the preimage? > Hash <digest> EqualVerify > If > # Carol has the preimage at any time > <Carol key> CheckSig > Else > # Anyone else has the preimage after t+150 > <t+150> CLTV > EndIf > Else > # Bob is allowed a refund after t+100 > <Bob key> CheckSigVerify > <t+100> CLTV > EndIf > > In English: > > - At any time, Carol can spend the output by releasing the preimage > - After t+100, Bob can spend the output > - After t+150, anyone with the preimage can spend the output
This is a clever idea. But it doesn't prevent this attack. Think about it this way: where previously there was one Carol who could perform the replacement cycling attack, with the anyone-can-spend branch the situation eventually transforms into a situation where there is an unlimited set of Carols who can perform the attack and, if they are a miner, benefit from it. Either way Bob is in a position where they might not learn about the preimage in time, and thus fail to redeem the received HTLC output. From Carol's point of view the situation didn't significantly change. Either they manage to succesfully spend the offered HTLC output after the redeemed HTLC output times out. Or they fail. Whether or not that failure happens because Bob got their refund, or someone else spent the offered HTLC output via the anyone-can-spend path is not relevant to Carol. Finally, this solution is inferior to OP_Expire in another important way: the anyone-can-spend branch represents a strict deadline for Bob too. With OP_Expire, once HTLC preimage branch has expired, Bob can spend the offered HTLC output at their leisure, as they are the only party with the ability to do that (assuming of course that we're talking about a valid commitment transaction, not an illegitmate revoked once). > [2] Although miners may want to consider running code that allows them to > rewrite any malleable transactions to pay themselve With full-RBF _anyone_ can run that code on behalf of miners, modulo edge cases where the replacement isn't possible due to the RBF anti-DoS rules. Indeed, people are apparently already doing this to screw over signature-less ordinal transactions. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
