Date: Thu, 25 Jun 2020 04:04:09 +0000
To: Nadav Ivgi <nadav@shesek.info>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <XcV-a5p3nVenGEXgv4CO2X6lh4UXi18PM4-iKnfY3_SSoi5xCeCp84wsS1yHdHMVvDftNX5TrOnhUfvei371OQQHIVAJmcF-UQ_EAAZONyE=@protonmail.com>
In-Reply-To: <CAGXD5f0PXDMbVMiUNnqK-HGwB1yDEmBQgtLbQU4xcad3pDaGmw@mail.gmail.com>
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
 <CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
 <ahTHfoyyTpBrMiKdJWMn9Qa8CMCEd1-y8OXPSjsDmttTOVC3zGuDoSHkm_oOe5mBYgIAY7jOPocQhLW29n544xFsqVyq51NFApvaFYYSvFY=@protonmail.com>
 <CABT1wWknczx62uCpJPWku-KeYuaFvJHrvOS74YzqfoVe5x=edg@mail.gmail.com>
 <CABT1wWmm=rx1MkFeNhGeEgdu7XpBXYeq_PWaZFfBOA7MRSKezw@mail.gmail.com>
 <xFJlIP6z6qhjxDAP8xUBnqPF-Wulexjr9izry8mIWCQzQdNrULtX_TwWGfuHo7VNfTdXZNmy05QHxMF3iJbjZm_-jFO_WRJjSQR0N_Dreic=@protonmail.com>
 <CAGXD5f0PXDMbVMiUNnqK-HGwB1yDEmBQgtLbQU4xcad3pDaGmw@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 Nadav,

> > I and some number of Lightning devs consider this to be sufficient disi=
ncentive to Bob not attacking in the first place.
>
> An additional disincentive could be introduced in the form of bribery pro=
ofs for failed attempts.
>
> If we assume that "honest" users of the LN protocol won't reveal their ti=
melocked transactions before reaching the timelock expiry (they shouldn't a=
nyway because standard full node implementations won't relay them), we can =
prove that Bob attempted bribery and failed to an outside observer by showi=
ng Bob's signed timelocked transaction, spending an output that was in real=
ity spent by a different transaction prior to the locktime expiry, which sh=
ould not be possible if Bob had waited.


Unfortunately this could be subject to an inversion of this attack.

Alice can wait for the timelock to expire, then bribe miners to prevent con=
firmation of the Bob timelocked transaction, getting the Alice hashlocked t=
ransaction confirmed.

Now of course you do mention "prior to the locktime expiry" but there is no=
w risk at around locktime.

Particularly, "natural" orphaned blocks and short-term chainsplits can exis=
t.
Bob might see that the locktime has arrived and broadcast the signed timelo=
cked transaction, then Alice sees the locktime has not yet arrived (due to =
short-term chainsplits/propagation delays) and broadcast the signed hashloc=
ked transaction, then in the end the Alice side of the short-term chainspli=
t is what solidifies into reality due to random chance on which miner wins =
which block.
Then Bob can now be accused of bribery, even though it acted innocently; it=
 broadcasted the timelock branch due to a natural chainsplit but Alice hash=
locked branch got confirmed.

Additional complications can be added on top to help mitigate this edge cas=
e but more complex =3D=3D worse in general.
For example it could "prior to locktime expiry" can ignore a few blocks bef=
ore the actual timelock, but this might allow Bob to mount the attack by in=
itiating its bribery behavior earlier by those few blocks.

Finally, serious attackers would just use new pseudonyms, the important thi=
ng is to make pseudonyms valuable and costly to lose, so it is considered s=
ufficient that LN nodes need to have some commitment to the LN in the form =
of actual channels (which are valuable, potentially money-earning construct=
s, and costly to set up).

Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris =
Belcher, could use similar disincentivizing; I know Chris is planning a fid=
elity bond system for SwapMarket makers, for example, which would mimic the=
 properties of LN channels (costly to set up, money-earning).

Regards,
ZmnSCPxj