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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
