public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: "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 04:23:03 +0000	[thread overview]
Message-ID: <i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com> (raw)
In-Reply-To: <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com>

Good morning Matt,

> While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
>
> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s 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 protocol 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 context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).

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.

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.

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


  reply	other threads:[~2020-08-04  4:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 21:40 [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT 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 [this message]
2020-08-04 10:38     ` Christian Decker
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='i9rsIn-lslFVgi9AZzyuLvD8sPJqibqSF0loi80tg0cQcGKW9Ccfvo-KSIQjhI7NvWCz8Bm5vTdiC1-TbWAf7s4QCabh6Kca4I6iBftpLQ0=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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