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 A120FC0733 for ; Thu, 2 Jul 2020 12:23:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 8D05F8A998 for ; Thu, 2 Jul 2020 12:23:04 +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 vOlbf0CdYvek for ; Thu, 2 Jul 2020 12:23:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by hemlock.osuosl.org (Postfix) with ESMTPS id 920818A840 for ; Thu, 2 Jul 2020 12:23:03 +0000 (UTC) Received: by mail-pg1-f179.google.com with SMTP id o13so10428763pgf.0 for ; Thu, 02 Jul 2020 05:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yWnN8HHEnKcgEjXTnVyjpz1/10TwyNecE7rWdwoN5/M=; b=LslQBwiKKXyeveupjnOIyJZ9NGXa6n0sjdCtikUabvHiz26NtFRwj1A2wWEgNt9ccX Knv8iMlkRIuaaxa4cPe7xGYxv6Fn9cEh8e4eT39rlXH7Yf2amkmheyer7KOlkO6rWw1P F6IVpSWh6GL6tjofWT3emDxbHyqI5Mdl266M6enxS3vRrihlBPJOzpSi0pZcDXVDZW90 AvxYKEp6uaKqug9Qv0mVtRcVckBVBvTJI/Cqxo+jr9THH/cl99iPFOn+lje37rUOf+8x EUq7yqaxtauhe+4cEcULoFVCU6f3R4htyJmE5XNGQdR4Pb6SPN0jUL7WJ9P14KMPvEpZ 3amg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yWnN8HHEnKcgEjXTnVyjpz1/10TwyNecE7rWdwoN5/M=; b=NG4wKIaocYWLI5ub5YxE6IqGulAVULeOHuMgVuy6XPEq/C73lGVexqiNyxNN1RNaxk FHVmobyCkaxLUxccpFTmaGx2T9fB8qcpepqVwkorMhKff2FE03uQmZr/eKoJ9bJBiT0p kQEKTHuvSaLP7oW+AWCEwqwCS9C2WNzx90In90d4DuIoYKsURBEuh1BRSyvDVxf0v4V3 rK2/grvkR3yE0zVw/V9d4kyBvLFBqnBtDi1d2BrQoQzIoKRqopr0DWX0CcvjJqmFYnXz 519SEsLq+17C5lMwBIPCoZ0nJS5Ctuf81ocSU51u194hpOI7XnHNWkDxb4JuKw1zWaE5 6BAA== X-Gm-Message-State: AOAM531PwxTumEc9uI6Ds6x2RfB0mjbHU/FWBYmABnbPdqnqPXUN5hwD cZTvxr7RHF1aF5rgUjrTbG5//z9k6fyX11BZmpc= X-Google-Smtp-Source: ABdhPJzR4HeiPyvpOQm8dBJCMs8cuTg2hyeZORE2E36tjQaS7bR0hk4kondd1Rnh4DdtPeOzdZtE23Joyy+PFeUNIXM= X-Received: by 2002:a63:b255:: with SMTP id t21mr15201567pgo.78.1593692582905; Thu, 02 Jul 2020 05:23:02 -0700 (PDT) MIME-Version: 1.0 References: <20200628121517.f3l2mjcy7x4566v3@ganymede> In-Reply-To: From: Tejaswi Nadahalli Date: Thu, 2 Jul 2020 14:22:51 +0200 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000490db305a97478cf" X-Mailman-Approved-At: Thu, 02 Jul 2020 13:29:09 +0000 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: Thu, 02 Jul 2020 12:23:04 -0000 --000000000000490db305a97478cf Content-Type: text/plain; charset="UTF-8" On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj wrote: > And your paper posits that if a miner is weak, its best strategy is to > take the myopic strategy and include the currently-valid Alice transaction. > Yes. The proof is quite trivial and follows from the definition of weak: if the myopic miner's hashpower percentage is p_i, and it's lower than f/b, that means that f > b*p_i. By including the currently-valid Alice transaction, the myopic miner could make f, which is higher than their expected gain, which is b*p_i. The myopic miner has a p_i chance of mining the first block when Bob's transaction becomes valid, and it's most likely to stay valid for just 1 block, as every miner would want that immediately when it gets valid. This is where we disagree with the MAD-HTLC paper. They assume that there are not any miners with sub-1% hashrate around. We find that there are many such miners, and with channel_reserve_satoshi set to 1% of the channel value, Alice can bump her fees to at least 1% of the channel value without worry (because she will get Bob's channel_reserve_satoshi's for herself if Bob is cheating by releasing a previous commitment TXN). We additionally also show that when strong miners know that weak miners are around, some of their strategies get dominated as well, and they will be forced to include Alice's transaction as well. This, if there is just one *known* weak miner, things are good for Alice. As an FYI, in our paper Alice is the cheater and Bob is the victim. There were reasons to "reverse the convention", so to speak - but that's for another day :-) > > Thus, if Alice even *matches* Bob, it seems to me that this ratio f / b is > 1.0 implying a miner can only be powerful if it has already 51%-attacked > Bitcoin (which tends to invalidate all our security assumptions of > higher-layer protocols anyway, since a 51% attacker can censor anything > with impunity). > We assume that Bob will bribe with the entire channel value - because he has received commensurate goods and services off-chain. So, Alice will find it difficult to match Bob's bribe, but she doesn't have to. > > Of course, Bob can offer up to the entire fund amount, for free, to miners > as a bribe, without loss to Bob. > Yes. Precisely. > > For more realistic scenarios where no miner has 100% hashrate, then Alice > can make all miners weak by being willing to pay up to 50% of the fund as > fee, as a miner that achieves greater than 50% hashrate share would already > effectively pwnzored Bitcoin and gained UNLIMITED POWAH anyway. > But she doesn't have to go as far as 50%. Just 1% seems quite reasonable, given a reasonable timelock. We have a closed form solution for the timelock T as well. In Lightning's case, with 1% channel_reserve_satoshis around, we arrive at T = 316, which is much longer than the current default of 144. > > So it looks to me that scorched-earth is a possible mitigation against > this attack. > I don't follow this. We show that a reasonable value of fees and timelock are enough to avoid the attack. Why scorch the earth? --000000000000490db305a97478cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 1, 2020 at 6:58 PM ZmnSCPxj &= lt;ZmnSCPxj@protonmail.com&g= t; wrote:
And your paper posits that if a miner is weak, its bes= t strategy is to take the myopic strategy and include the currently-valid A= lice transaction.

Yes. The proof is qui= te trivial and follows from the definition of weak: if the myopic miner'= ;s hashpower percentage is p_i, and it's lower than f/b, that means tha= t f > b*p_i. By including the currently-valid Alice transaction, the myo= pic miner could make f, which is higher than their expected gain, which is = b*p_i. The myopic miner has a p_i chance of mining the first block when Bob= 's transaction becomes valid, and it's most likely to stay valid fo= r just 1 block, as every miner would want that immediately when it gets val= id. This is where we disagree with the MAD-HTLC paper. They assume that the= re are not any miners with sub-1% hashrate around. We find that there are m= any such miners, and with channel_reserve_satoshi set to 1% of the channel = value, Alice can bump her fees to at least 1% of the channel value without = worry (because she will get Bob's channel_reserve_satoshi's for her= self if Bob is cheating by releasing a previous commitment TXN).
=
We additionally also show that when strong miners know that = weak miners are around, some of their strategies get dominated as well, and= they will be forced to include Alice's transaction as well. This, if t= here is just one *known* weak miner, things are good for Alice. As an FYI, = in our paper Alice is the cheater and Bob is the victim. There were reasons= to "reverse the convention", so to speak - but that's for an= other day :-)
=C2=A0

Thus, if Alice even *matches* Bob, it seems to me that this ratio f / b is = 1.0 implying a miner can only be powerful if it has already 51%-attacked Bi= tcoin (which tends to invalidate all our security assumptions of higher-lay= er protocols anyway, since a 51% attacker can censor anything with impunity= ).

We assume that Bob will bribe with t= he entire channel value - because he has received commensurate goods and se= rvices off-chain. So, Alice will find it difficult to match Bob's bribe= , but she doesn't have to.=C2=A0
=C2=A0

Of course, Bob can offer up to the entire fund amount, for free, to miners = as a bribe, without loss to Bob.

Yes. P= recisely.
=C2=A0

For more realistic scenarios where no miner has 100% hashrate, then Alice c= an make all miners weak by being willing to pay up to 50% of the fund as fe= e, as a miner that achieves greater than 50% hashrate share would already e= ffectively pwnzored Bitcoin and gained UNLIMITED POWAH anyway.

But she doesn't have to go as far as 50%. Just = 1% seems quite reasonable, given a reasonable timelock. We have a closed fo= rm solution for the timelock T as well. In Lightning's case, with 1% ch= annel_reserve_satoshis around, we arrive at T =3D 316, which is much longer= than the current default of 144.=C2=A0
=C2=A0

So it looks to me that scorched-earth is a possible mitigation against this= attack.

I don't follow this. We sh= ow that a reasonable value of fees and timelock are enough to avoid the att= ack. Why scorch the earth?
--000000000000490db305a97478cf--