MIME-Version: 1.0
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
 <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
 <20200628121517.f3l2mjcy7x4566v3@ganymede>
In-Reply-To: <20200628121517.f3l2mjcy7x4566v3@ganymede>
From: Tejaswi Nadahalli <nadahalli@gmail.com>
Date: Mon, 29 Jun 2020 13:57:52 +0200
Message-ID: <CAAifmAS6jX5f4XThSw_ygFpCU7JVdmQSgVjOj+if3p4qeO8sNg@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005b415505a937c5a5"
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
 Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
Precedence: list

--0000000000005b415505a937c5a5
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 28, 2020 at 2:16 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> So, if I understand correctly, even a small amount of "myopic" hashrate
> and long timeouts---or modest amounts of hashrate and short
> timeouts---makes this attack unlikely to succeed (and, even in the cases
> where it does succeed, Bob will have to offer a very large bribe to
> compensate "rational" miners for their high chance of losing out on
> gaining any transaction fees).
>

We were separately working on a similar problem, and wrote a paper as well:
https://eprint.iacr.org/2020/774 *

We look at the Alice's-Fees/Bob's-Bribe ratio. We also look at "strong" and
"weak" miners in this context. If a miner is weak, their hash-rate is lower
than this fees/bribe ratio. If they are strong, their hash rate is more
than this fees/bribe ratio. In this setting, it turns out that if there are
only strong miners, Bob will win. If there is at least one weak miner,
Alice has to win, given a reasonable timeout value. We found it awesome
that lightning has a parameter called "channel-reserve_satoshis", which
directly helps in countering this bribe by giving Alice some leeway in fees.

* Ph.D students want to write papers, unfortunately.

--0000000000005b415505a937c5a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span class=3D"gmail-im" style=3D"color:r=
gb(80,0,80)"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 28, 2020 at =
2:16 PM David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">So, if I understand correctly, even a small amount of &quot;myopic&q=
uot; hashrate<br>and long timeouts---or modest amounts of hashrate and shor=
t<br>timeouts---makes this attack unlikely to succeed (and, even in the cas=
es<br>where it does succeed, Bob will have to offer a very large bribe to<b=
r>compensate &quot;rational&quot; miners for their high chance of losing ou=
t on<br>gaining any transaction fees).<br></blockquote><div><br></div></spa=
n><div>We were separately working on a similar problem, and wrote a paper a=
s well:=C2=A0<a href=3D"https://eprint.iacr.org/2020/774" target=3D"_blank"=
>https://eprint.iacr.org/2020/774</a>=C2=A0*<div><br></div><div>We look at =
the Alice&#39;s-Fees/Bob&#39;s-Bribe ratio. We also look at &quot;strong&qu=
ot; and &quot;weak&quot; miners in this context. If a miner is weak, their =
hash-rate is lower than this fees/bribe ratio. If they are strong, their ha=
sh rate is more than this fees/bribe ratio. In this setting, it turns out t=
hat if there are only=C2=A0strong miners, Bob will win. If there is at leas=
t one weak miner, Alice has to win, given a reasonable timeout value. We fo=
und it awesome that lightning=C2=A0has a parameter called &quot;channel-res=
erve_satoshis&quot;, which directly helps in countering this bribe by givin=
g Alice some leeway in fees.</div><div><div><div><br></div><div>* Ph.D stud=
ents=C2=A0want to write papers, unfortunately.</div></div></div></div></div=
></div>

--0000000000005b415505a937c5a5--