Date: Sat, 04 Jul 2020 21:05:34 +0000
To: "David A. Harding" <dave@dtrt.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <iywK1t3ddjnrn5h4bhLTHNJdKJpCjn9PmuI4eueLw_QOEgEovahDvdbm4gd74roj5eq5KT6b2oXRCNdi8omn0E4pTaRL_wxpOxvifY2l5wE=@protonmail.com>
In-Reply-To: <20200628164132.mmpimgcrxpai2gnb@ganymede>
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>
 <20200628164132.mmpimgcrxpai2gnb@ganymede>
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 Dave,


> > > -   Inputs:
> > >     -   Bob 1 BTC - HTLC amount
> > >     -   Bob 1 BTC - Bob fidelity bond
> > > -   Cases:
> > >     -   Alice reveals hashlock at any time:
> > >         -   1 BTC goes to Alice
> > >         -   1 BTC goes to Bob (fidelity bond refund)
> > >     -   Bob reveals bob-hashlock after time L:
> > >         -   2 BTC goes to Bob (HTLC refund + fidelity bond refund)
> > >     -   Bob cheated, anybody reveals both hashlock and bob-hashlock:
> > >         -   2 BTC goes to miner
> > >
> > > [...]
> >
> > The cases you present are exactly how MAD-HTLC works. It comprises two
> > contracts (UTXOs):
> >
> > -   Deposit (holding the intended HTLC tokens), with three redeem paths=
:
> >     -   Alice (signature), with preimage "A", no timeout
> >     -   Bob (signature), with preimage "B", timeout T
> >     -   Any entity (miner), with both preimages "A" and "B", no timeout
> > -   Collateral (the fidelity bond, doesn't have to be of the same amoun=
t)
> >     -   Bob (signature), no preimage, timeout T
> >     -   Any entity (miner), with both preimages "A" and "B", timeout T
>
> I'm not these are safe if your counterparty is a miner. Imagine Bob
> offers Alice a MAD-HTLC. Alice knows the payment preimage ("preimage
> A"). Bob knows the bond preimage ("preimage B") and he's the one making
> the payment and offering the bond.
>
> After receiving the HTLC, Alice takes no action on it, so the timelock
> expires. Bob publicly broadcasts the refund transaction with the bond
> preimage. Unbeknownst to Bob, Alice is actually a miner and she uses her
> pre-existing knowledge of the payment preimage plus her received
> knowledge of the bond preimage to privately attempt mining a transaction
> that pays her both the payment ("deposit") and the bond ("collateral").
>
> Assuming Alice is a non-majority miner, she isn't guaranteed to
> succeed---her chance of success depends on her percentage of the network
> hashrate and how much fee Bob paid to incentivize other miners to
> confirm his refund transaction quickly. However, as long as Alice has a
> non-trivial amount of hashrate, she will succeed some percentage of the
> time in executing this type of attack. Any of her theft attempts that
> fail will leave no public trace, perhaps lulling users into a false
> sense of security.


This note seems to have gotten missed in discussion.

Another note is that from what I can tell, the preimages "A" and "B" can be=
 provided by any miner.

If the fund value plus the collateral is large enough, it may incentivize c=
ompeting miners to reorg the chain, redirecting the funds of the MAD-HTLC t=
o themselves, rather than advance the blockchain state, at least until alte=
rnative transctions bump their fees up enough that the collateral + fund is=
 matched.

This may not apply to Lightning at least if you do not go beyond the Wumbo =
limit, but *could* apply to e.g. SwapMarket, if it uses MAD-HTLCs.

Regards,
ZmnSCPxj