Date: Tue, 04 Aug 2020 14:59:52 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <KSfad5I1vkw0QoInOkoVtxk9Sw6ypolsQu6TwMd_Y9CzaQsLTElk14434R3Rc2gwC88oAfiH3cITp4do0gtSKknUUBfrmbRKGeYW0ldeevU=@protonmail.com>
In-Reply-To: <735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com>
References: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
 <735E5B6A-785E-408B-8658-FA36200923C7@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Precedence: list

Good morning Matt,

> Hmm, apologies that little context was provided - this was meant in the c=
ontext of the current crop of relay-based attacks that have been discovered=
. As we learned in those contexts, =E2=80=9Cjust handle it when it confirms=
=E2=80=9D doesn=E2=80=99t provide the types of guarantees we were hoping fo=
r as placing commitment transactions in mempools can be used to prevent hon=
est nodes from broadcasting the latest state. This implies that HTLC securi=
ty may be at risk.
>

Ah, okay.

So the attack is this:

* Attacker connects twice to the LN: one to any node near the victim, one t=
o the victim.
* Attacker arranges for the attacker-victim channel to have most funds in t=
he side of the victim.
* The attacker routes a circular payment terminating in the victim-attacker=
 channel.
  * The victim accepts some incoming HTLC, and provides an outgoing HTLC to=
 the attacker via the victim-attacker channel.
* The attacker broadcasts a very low-fee old-state transaction of the victi=
m-attacker channel, one that is too low-fee to practically get confirmed, j=
ust before the HTLC timeout.
* The victim-outgoing HTLC times out, making the victim broadcast a unilate=
ral close attempt for the victim-attacker channel in order to enforce the H=
TLC onchain.
  * Unfortunately for the victim, relay shenanigans prevent the latest comm=
itment from being broadcast.
* The attacker waits for the victim-incoming HTLC to timeout, which forces =
the victim to `update_htlc_failed` the incoming HTLC or risk having that ch=
annel closed (and losing future routing fees).
  * The attacker now gets back its outgoing funds.
* The attacker lets the old-state transaction get relayed, and then re-seat=
s the latest update transaction to that.
* Once the latest transaction allows the HTLCs to be published, the attacke=
r claims the victim-outgoing HTLC with the hashlock branch.
  * The attacker now gets its incoming funds, doubling its money, because t=
hat is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works ri=
ght?

Hmmm.

The only thing I can imagine helping here is for the forwarding node to dro=
p channels onchain "early", i.e. if the HTLC will time out in say 14 blocks=
 we drop the channel onchain, so we have a little leeway in bumping up fees=
 for the commitment transaction.
Maybe.
I am sure Matt can find yet another relay attack that prevents that, at thi=
s point, haha.

"Are we *still* talking about onchain fees....?" - Adelaide 2018

Regards,
ZmnSCPxj


> > On Aug 4, 2020, at 00:23, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > Good morning Matt,
> >
> > > While I admit I haven=E2=80=99t analyzed the feasibility, I want to t=
hrow one additional design consideration into the ring.
> > > Namely, it would ideally be trivial, at the p2p protocol layer, to re=
lay a transaction to a full node without knowing exactly which input transa=
ction that full node has in its mempool/active chain. This is at least pote=
ntially important for systems like lighting where you do not know which cou=
nterparty commitment transaction(s) are in a random node=E2=80=99s mempool =
and you should be able to describe to that node that you are spending then =
nonetheless.
> > > This is (obviously) an incredibly nontrivial problem both in p2p prot=
ocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT =
rather useless for lighting without it.
> > > The least we could do is think about the consensus design in that con=
text, even if we have to provide an external overlay relay network in order=
 to make lighting transactions relay properly (presumably with miners runni=
ng such software).
> >
> > Ah, right.
> > A feasible attack, without the above, would be to connect to the fullno=
de of the victim, and connect to miners separately.
> > Then you broadcast to the victim one of the old txes, call it tx A, but=
 you broadcast to the miners a different old tx, call it B.
> > The victim reacts only to tA, but does not react to B since it does not=
 see B in the mempool.
> > On the other hand --- what the victim needs to react to is onchain conf=
irmed transactions.
> > So I think all the victim needs to do, in a Lightning universe utilizin=
g primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain event=
s and ignore mempool events.
> > So if we give fairly long timeouts for our mechanisms, it should be eno=
ugh, I think, since once a transaction is confirmed its txid does not malle=
ate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" =
to that txid, unless a reorg unconfirms the transaction.
> > We only need to be aware of deep reorgs and re-broadcast with a malleat=
ed prevout until the tx being spent is deeply confirmed.
> > In addition, we want to implement scorch-the-earth, keep-bumping-the-fe=
e strategies anyway, so we would keep rebroadcasting new versions of the sp=
ending transaction, and spending from a transaction that is confirmed.
> > Or are there other attack vectors you can see that I do not?
> > I think this is fixed by looking at the blockchain.
> > Regards,
> > ZmnSCPxj