From: Bastien TEINTURIER <bastien@acinq•fr>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest
Date: Mon, 22 Jun 2020 10:25:09 +0200 [thread overview]
Message-ID: <CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com> (raw)
In-Reply-To: <F7ZA7-s3UnfMlhYdA1esEhJIhgNIBSKCfHWG64UAcMvQM-ZS6Do7xMg8OfYhbkHIFNodbLIe51TQG7Ps3jFXFoS80EJ6oEh8n2009vbnl04=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]
Hey ZmnSCPxj,
I agree that in theory this looks possible, but doing it in practice with
accurate control
of what parts of the network get what tx feels impractical to me (but maybe
I'm wrong!).
It feels to me that an attacker who would be able to do this would break
*any* off-chain
construction that relies on absolute timeouts, so I'm hoping this is
insanely hard to
achieve without cooperation from a miners subset. Let me know if I'm too
optimistic on
this!
Cheers,
Bastien
Le lun. 22 juin 2020 à 10:15, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit :
> Good morning Bastien,
>
> > Thanks for the detailed write-up on how it affects incentives and
> centralization,
> > these are good points. I need to spend more time thinking about them.
> >
> > > This is one reason I suggested using independent pay-to-preimage
> > > transactions[1]
> >
> > While this works as a technical solution, I think it has some incentives
> issues too.
> > In this attack, I believe the miners that hide the preimage tx in their
> mempool have
> > to be accomplice with the attacker, otherwise they would share that tx
> with some of
> > their peers, and some non-miner nodes would get that preimage tx and be
> able to
> > gossip them off-chain (and even relay them to other mempools).
>
> I believe this is technically possible with current mempool rules, without
> miners cooperating with the attacker.
>
> Basically, the attacker releases two transactions with near-equal fees, so
> that neither can RBF the other.
> It releases the preimage tx near miners, and the timelock tx near
> non-miners.
>
> Nodes at the boundaries between those that receive the preimage tx and the
> timelock tx will receive both.
> However, they will receive one or the other first.
> Which one they receive first will be what they keep, and they will reject
> the other (and *not* propagate the other), because the difference in fees
> is not enough to get past the RBF rules (which requires not just a feerate
> increase, but also an increase in absolute fee, of at least the minimum
> relay feerate times transaction size).
>
> Because they reject the other tx, they do not propagate the other tx, so
> the boundary between the two txes is inviolate, neither can get past that
> boundary, this occurs even if everyone is running 100% unmodified Bitcoin
> Core code.
>
> I am not a mempool expert and my understanding may be incorrect.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 2954 bytes --]
next prev parent reply other threads:[~2020-06-22 8:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 2:43 [bitcoin-dev] " Matt Corallo
2020-04-22 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-04-22 4:18 ` Olaoluwa Osuntokun
2020-04-22 6:08 ` ZmnSCPxj
2020-04-22 8:01 ` Antoine Riard
2020-04-22 8:55 ` Bastien TEINTURIER
2020-04-22 23:05 ` Olaoluwa Osuntokun
2020-04-22 23:11 ` Olaoluwa Osuntokun
2020-04-22 16:56 ` Matt Corallo
2020-04-22 4:13 ` [bitcoin-dev] " Olaoluwa Osuntokun
2020-04-22 11:51 ` David A. Harding
2020-04-27 21:26 ` Rusty Russell
2020-04-22 16:50 ` Matt Corallo
2020-04-22 23:13 ` Olaoluwa Osuntokun
2020-04-22 23:20 ` Matt Corallo
2020-04-22 23:27 ` Olaoluwa Osuntokun
2020-04-23 1:10 ` Matt Corallo
2020-04-23 4:50 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-04-23 6:21 ` Matt Corallo
2020-04-23 12:46 ` ZmnSCPxj
2020-04-23 22:47 ` Matt Corallo
2020-06-19 7:44 ` Bastien TEINTURIER
2020-06-19 19:58 ` David A. Harding
2020-06-19 20:52 ` David A. Harding
2020-06-20 8:54 ` Bastien TEINTURIER
2020-06-20 10:36 ` David A. Harding
2020-06-20 16:01 ` ZmnSCPxj
2020-06-21 2:10 ` ZmnSCPxj
2020-06-22 7:35 ` Bastien TEINTURIER
2020-06-22 8:15 ` ZmnSCPxj
2020-06-22 8:25 ` Bastien TEINTURIER [this message]
2020-06-24 8:32 ` Matt Corallo
2020-04-23 1:18 ` [bitcoin-dev] " Jeremy
2020-04-22 18:24 ` David A. Harding
2020-04-22 19:03 ` Antoine Riard
2020-04-22 20:28 ` David A. Harding
2020-04-22 22:53 Matt Corallo
2020-04-23 9:59 ` David A. Harding
2020-04-23 12:52 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
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='CACdvm3O3UmZcYYGaY2x23MYY=3saPFkgQtaDELd=kY93SRLLaA@mail.gmail.com' \
--to=bastien@acinq$(echo .)fr \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/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