[bitcoin-dev] MAD-HTLC

[ZmnSCPxj]

Good morning Tejaswi,



> > But if an attack happens during a fee spike, then even though we retain our current default `to_self_delay` of 144, we still have the ability to gradually and automatically move to higher fee regions until our transaction confirms, and we have a good excuse for it to present to users: "a fee spike was happening at the time, so you had to pay some extra miner fees".
>
> Agree on the UX. There is a tradeoff between the timelocked value of the channel balance to Alice during benign vs malicious abandonment by Bob. In your opinion, increasing the fees beyond 1% (and thereby cutting into Alice's share itself) is a slightly better tradeoff than increasing to_self_delay. 

Currently, we say `to_self_delay` is a parameter of how long you can be offline, and is imposed on your counterparty (so its effect on you is to allow the counterparty to safely be offline for that long).
This explanation seems palatable to users; they understand that it is the counterparty which is asking this of them, and that they ask a similar number of their counterparty, which is also their own protection.

On the other hand, we do not really expect to get beyond 1% unless we are under attack, *or* the fee spikes are really, really bad.
So this seems a practical tradeoff for us over in Lightning-land.


> > And since you and your paper openly discusses it anyway, I would like to reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
>
> We know. Maybe we should have made it clear in the paper that when we use the Poon-Dryja channel construction, we use the idea that the knowledge of the preimage of a hash is equivalent to knowing the private key of the revocation public key. In fact, this is how the Poon-Dryja construction is explained in McCorry's Ph.D thesis, and IMHO is easier to understand than the original description in the Poon-Dryja paper (or Bolt #3, for that matter). 

Yes, I realized it a little after reading MAD-HTLC that it applied to all the other known channel mechanisms as well, not just HTLCs, and decided to investigate this topic further, and have been circumspect regarding this.

> You could further argue that the hashlock is an incidental artefact, and our paper mostly refers to timelocked transactions. And the rest of your email describes applications of timelocked (and obviously presigned) transactions, which are all vulnerable to the same bribing attack. Additionally, the Wattehnofer in our paper is the same Wattenhofer from the Duplex Channel paper.

Yes, I agree that the hashlock is an incidental artefact.

What MAD-HTLC questions is our assumption that a valid transaction with an earlier locktime supersedes a valid transaction spending the same txout with a later locktime.
Whether it involves presigned transactions or hashlocks are incidental artefacts.
So for example, a SCRIPT `OP_IF <A> OP_ELSE <1 day> OP_CHECKSEQUENCEVERIFY OP_DROP <B> OP_ENDIF OP_CHECKSIG` would also be vulnerable to the MAD-HTLC argument.

(Indeed, BOLT spec uses something very much like that script, now that I look at it again; in our case the `<A>` is a combination of keys from both parties, that cannot be signed with unless one party knows both sub-keys.)

>
> > My current analysis suggests that in practice, the MAD-HTLC argument does not apply at all (else I would not be revealing that all channel mechanisms are broken **if** the MAD-HTLC argument *does* apply), since the myopic strategy seems to be pretty much inevitably dominant at stable states.
>
> We agree. 
>  
>
> > But it would still be best to investigate further until we are fully convinced that the MAD-HTLC argument ("'earlier supersedes later' might be falsified by bribery") does not apply.
>
> I think this is the analysis our paper does, and perhaps it's our mistake that we do not set the context better. We only mention (and propose fixes for) Poon-Dryja channel construction, and Tier Nolan's Atomic Swap construction. 
>
> We could have addressed Spilman's one-way channels or Decker-Wattenhofer duplex channels, but that would have been pointless as they were never going to make it into production after Poon-Dryja and subsequently, Eltoo were proposed.

I suggested that, until `SIGHASH_ANYPREVOUT` gets enabled, the Decker-Wattenhofer construction (removing the duplex Spilman-like channels at the end and leaving just the decrementing-`nSequence` constructions) could be used for Ruben Somsen StateChains, so you might not want to dismiss that so readily.

The decrementing-`nSequence` mechanisms have the advantage that it does not require a punishment/revocation branch, similar to Decker-Russell-Osuntokun "eltoo", and thus would work just as well to implement statechains, at least until all the debates around `SIGHASH_ANYPREVOUT` settle and it gets deployed.

Similarly, the proposed CoinPool as well could be implemented using Decker-Wattenhofer, assuming  it gets any details or support behind it sufficiently to push it before `SIGHASH_ANYPREVOUT` gets deployed.

> But not addressing Eltoo in the paper is an omission that I am a bit upset about. We additionally do not address more sophisticated atomic swaps from Somsen or Fournier. Nor do we address Kanzure's vault proposal. In fact, one rule of thumb might be that wherever watchtowers are required, a timelocked bribe might be possible. 

I think a better heuristic is that, if the logic of the construction assumes "transaction with earlier locktime supersedes transaction with later locktime", then it is timelocked-bribery-vulnerable.


Regards,
ZmnSCPxj