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>
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
Date: Tue, 04 Aug 2020 12:38:20 +0200 [thread overview]
Message-ID: <87zh7ay9ur.fsf@gmail.com> (raw)
In-Reply-To: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com>
> 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
next prev parent reply other threads:[~2020-08-04 10:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 21:40 Anthony Towns
2020-07-09 22:30 ` Anthony Towns
2020-07-10 7:46 ` Christian Decker
2020-07-10 3:29 ` ZmnSCPxj
2020-08-03 19:27 ` Richard Myers
2020-08-04 1:38 ` ZmnSCPxj
2020-08-04 4:02 ` lf-lists
2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker [this message]
2020-08-04 13:10 ` Matt Corallo
2020-08-04 14:59 ` ZmnSCPxj
2020-08-06 15:58 ` Matt Corallo
2020-08-07 15:34 ` Richard Myers
2020-08-11 0:14 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zh7ay9ur.fsf@gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox