Date: Fri, 03 Jul 2020 10:16:55 +0000
To: Tejaswi Nadahalli <nadahalli@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-R0O_3IqpmbxNSONd1A2peCnpEIRs73ZELJgsBf06ygq4BGMo3Hg9h4OlXiGuIUyaITWixSY7LlgVyJ2MkAFQb7Y6I1gC8AXiAeS7eMlSso=@protonmail.com>
In-Reply-To: <CAAifmATpg21K=yvi8OaPgr2esdtciu_uNLmNbA8983iht7Ru_Q@mail.gmail.com>
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
 <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
 <20200628121517.f3l2mjcy7x4566v3@ganymede>
 <WYQRrIi65yvBWc9qsqCxHWadrMFtYPh2wI-IzVS15FBTFmpIXqHwj5yrj3Igpr-9sKygWsH4DkI_maWcULKKQb51Xp_xZBvKuPF_HmCvqb4=@protonmail.com>
 <CAAifmATmQSUUsEbouVYTNNMu-BT8vQiGvh3jwLNK4CUB11s7mg@mail.gmail.com>
 <Fh70O0CqbkbLaOUEqRzIG3MOOZi_tYz69xRDPlIlF5tgTIPdYF9LyeoJjypo-agN9-WkuoXJD896R6CQygTozeHA_CFULp3k7007PioaDrs=@protonmail.com>
 <CAAifmARxvG+_Wo3zba6MCd=jxwesb2JhWAwRErq6QPVTe1AQEA@mail.gmail.com>
 <YhzMZ419vB1BY4Opd3lwfSSJ6_4AIQUDDtZPPhyB2HgskDZv0DKCQlEOAFklskLp1mj5AZrI43VPXOslX25MO-3Fijl9pBWrWYlYiaERr70=@protonmail.com>
 <CAAifmATpg21K=yvi8OaPgr2esdtciu_uNLmNbA8983iht7Ru_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
Precedence: list

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 g=
radually 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 spi=
ke 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_dela=
y.=C2=A0

Currently, we say `to_self_delay` is a parameter of how long you can be off=
line, 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 c=
ounterparty which is asking this of them, and that they ask a similar numbe=
r 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 u=
nder 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 t=
o 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 rev=
ocation public key. In fact, this is how the Poon-Dryja construction is exp=
lained 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).=
=C2=A0

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

> You could further argue that the hashlock=C2=A0is an incidental artefact,=
 and our paper mostly refers to timelocked transactions. And the rest of yo=
ur email describes applications of timelocked (and obviously presigned) tra=
nsactions, which are all vulnerable to the same bribing attack. Additionall=
y, the Wattehnofer in our paper is the same Wattenhofer from the Duplex Cha=
nnel 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 wit=
h a later locktime.
Whether it involves presigned transactions or hashlocks are incidental arte=
facts.
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 lo=
ok at it again; in our case the `<A>` is a combination of keys from both pa=
rties, that cannot be signed with unless one party knows both sub-keys.)

>
> > My current analysis suggests that in practice, the MAD-HTLC argument do=
es not apply at all (else I would not be revealing that all channel mechani=
sms 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.=C2=A0
> =C2=A0
>
> > But it would still be best to investigate further until we are fully co=
nvinced that the MAD-HTLC argument ("'earlier supersedes later' might be fa=
lsified 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 construc=
tion.=C2=A0
>
> We could have addressed Spilman's one-way channels or Decker-Wattenhofer =
duplex channels, but that would have been pointless as they were never goin=
g to make it into production after Poon-Dryja and subsequently, Eltoo were =
proposed.

I suggested that, until `SIGHASH_ANYPREVOUT` gets enabled, the Decker-Watte=
nhofer construction (removing the duplex Spilman-like channels at the end a=
nd leaving just the decrementing-`nSequence` constructions) could be used f=
or Ruben Somsen StateChains, so you might not want to dismiss that so readi=
ly.

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

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

> But not addressing Eltoo in the paper is an omission that I am a bit upse=
t about. We additionally do not address more sophisticated atomic swaps fro=
m 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 timelo=
cked bribe might be possible.=C2=A0

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


Regards,
ZmnSCPxj