From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D6982C0733 for ; Fri, 3 Jul 2020 10:17:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id C5FF2898B9 for ; Fri, 3 Jul 2020 10:17:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaEY7dtM+zeU for ; Fri, 3 Jul 2020 10:17:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by hemlock.osuosl.org (Postfix) with ESMTPS id EB02B898AC for ; Fri, 3 Jul 2020 10:17:04 +0000 (UTC) Date: Fri, 03 Jul 2020 10:16:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1593771422; bh=2qwsLli10co8rtlCeNqblTvEt1w0Bs6y0v4NtONQTr8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=xdtlBKf0fLWuo/7CGOwFdQGMacm3DdrMmh18GTL9Dd0Z2zB1iQP5mdUB6qBFO+bQW 7A3MMPCrLt8cheWga9BImGKrVr7HXqDITzT8oW+mVL5AlnEPwM9sX3XBnM2lZ91Mw7 2yiHLxLvstG0E+yFb+ids3VRV7bpLvrH3nBkoK88= To: Tejaswi Nadahalli From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <-R0O_3IqpmbxNSONd1A2peCnpEIRs73ZELJgsBf06ygq4BGMo3Hg9h4OlXiGuIUyaITWixSY7LlgVyJ2MkAFQb7Y6I1gC8AXiAeS7eMlSso=@protonmail.com> In-Reply-To: References: <20200628121517.f3l2mjcy7x4566v3@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Matan Yehieli , Bitcoin Protocol Discussion , Itay Tsabary Subject: Re: [bitcoin-dev] MAD-HTLC X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 10:17:07 -0000 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 OP_ELSE <1 day> OP_CHECKSEQUENCEVERIFY = OP_DROP 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 `` 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