From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lf-lists\@mattcorallo.com" <lf-lists@mattcorallo.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au>
 <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com>
 <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
Date: Tue, 04 Aug 2020 12:38:20 +0200
Message-ID: <87zh7ay9ur.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Precedence: list

> Ah, right.
>
> A feasible attack, without the above, would be to connect to the
> fullnode 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*
> confirmed transactions.  So I think all the victim needs to do, in a
> Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based
> mechanisms, is to monitor onchain events and ignore mempool events.
>
> So if we give fairly long timeouts for our mechanisms, it should be
> enough, I think, since once a transaction is confirmed its txid does
> not malleate 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 malleated prevout until the tx being spent is deeply confirmed.

This is indeed part of the reason why we chose to describe the protocol
on-chain first in the paper and lift it off-chain after showing the
basic functionality. This means that the protocol is still correct even
if executed solely on information derived from blocks and confirmed
transactions in those blocks. The timeouts have to be chosen carefully
to allow reacting in a timely fashion, however that is true for all
off-chain protocols.

> In addition, we want to implement scorch-the-earth,
> keep-bumping-the-fee strategies anyway, so we would keep
> rebroadcasting new versions of the spending transaction, and spending
> from a transaction that is confirmed.

Correct, it might be desirable to give a misbehaving node a papercut by
letting their update transaction confirm (taking their fee along with
it) and then reacting to the outdated update by overriding the effects
with a new update-settlement pair.

So, while being able to react to a transaction in the memory pool early
might be a nice addition, it is not strictly required for safety of the
protocol. I say nice addition, because it can allow replacing the
outdated transaction directly, thus saving the misbehaving node from the
fee papercut, but also save a bit of blockspace which that fee would
have paid for, and leave it available for other transactions.

Cheers,
Christian