public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bastien TEINTURIER <bastien@acinq.fr>
To: "David A. Harding" <dave@dtrt.org>
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: Sat, 20 Jun 2020 10:54:03 +0200	[thread overview]
Message-ID: <CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com> (raw)
In-Reply-To: <20200619205220.fshbr7pbijaerbf2@ganymede>

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

Hello Dave and list,

Thanks for your quick answers!

The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.
>

Exactly, if the attacker submits an outdated transaction he would be
shooting himself in the foot,
as we could claim the revocation paths when seeing the transaction in a
block and get all the
channel funds (since the attacker's outputs will be CSV-locked).

The only way your Bitcoin peer will relay your blind child
> is if it already has the parent transaction.
>

That's an excellent point that I missed in the blind CPFP carve-out trick!
I think this makes the
blind CPFP carve-out quite hard in practice (even using getdata - thanks
for detailing that option)...

In the worst case scenario where most miners' mempools contain the
attacker's tx and the rest of
the network's mempools contains the honest participant's tx, I think there
isn't much we can do.
We're simply missing information, so it looks like the only good solution
is to avoid being in that
situation by having a foot in miners' mempools. Do you think it's
unreasonable to expect at least
some LN nodes to also invest in running nodes in mining pools, ensuring
that they learn about
attackers' txs and can potentially share discovered preimages with the
network off-chain (by
gossiping preimages found in the mempool over LN)? I think that these
recent attacks show that
we need (at least some) off-chain nodes to be somewhat heavily invested in
on-chain operations
(layers can't be fully decoupled with the current security assumptions -
maybe Eltoo will help
change that in the future?).

Thank you for your time!
Bastien



Le ven. 19 juin 2020 à 22:53, David A. Harding <dave@dtrt.org> a écrit :

> On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev
> wrote:
> > I think you're assuming here that the attacker broadcast a particular
> > state.
>
> Whoops, I managed to confuse myself despite looking at Bastien's
> excellent explainer.  The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child.  However, the blind child will only be relayed by a Bitcoin peer
> if the peer also has the parent transaction (the latest state) and, if
> it has the parent transaction, you should be able to just getdata('tx',
> $txid) that transaction from the peer without CPFPing anything.  That
> will give you the preimage and so you can immediately resolve the HTLC
> with the upstream channel.
>
> Revising my conclusion from the previous post:
>
> I think the strongman argument for the attack would be that the attacker
> will be able to perform a targeted relay of the low-feerate
> preimage-containing transaction to just miners---everyone else on the
> network will receive the honest user's higher-feerate expired-timelock
> transaction.  Unless the honest user happens to have a connection to a
> miner's node, the user will neither be able to CPFP fee bump nor use
> getdata to retrieve the preimage.
>
> Sorry for the confusion.
>
> -Dave
>

[-- Attachment #2: Type: text/html, Size: 4112 bytes --]

  reply	other threads:[~2020-06-20  8:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  2:43 [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest 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 [this message]
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
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='CACdvm3O+A5M17rqejzAMUzE+fxLdzqnDY2m5+rnc5C=nzyPp9g@mail.gmail.com' \
    --to=bastien@acinq.fr \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@dtrt.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /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