public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt.org>
To: Bastien TEINTURIER <bastien@acinq.fr>
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: Fri, 19 Jun 2020 15:58:46 -0400	[thread overview]
Message-ID: <20200619195846.fclw4ilngvbbf2kk@ganymede> (raw)
In-Reply-To: <CACdvm3Of_9zhNmzCxeK-z8oz6wU=8RuDjr0R9+yrGeFjLYz9pg@mail.gmail.com>

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

On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev wrote:
> The gist is here, and I'd appreciate your feedback if I have wrongly
> interpreted some of the ideas:
> https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12

Quoted text below is from the gist:

> The trick to protect against a malicious participant that broadcasts a
> low-fee HTLC-success or Remote-HTLC-success transaction is that we can
> always blindly do a CPFP carve-out on them; we know their txid

I think you're assuming here that the attacker broadcast a particular
state.  However, in a channel which potentially had thousands of state
changes, you'd have to broadcast a blind child for each previous state
(or at least each previous state that pays the attacker more than the
latest state).  That's potentially thousands of transactions times
potentially dozens of peers---not impossible, but it seems messy.

I think there's a way to accomplish the same goal for less bandwidth and
zero fees.  The only way your Bitcoin peer will relay your blind child
is if it already has the parent transaction.  If it has the parent, you
can just request it using P2P getdata(type='tx', id=$txid).[1]  You can
batch multiple txid requests together (up to 50,000 IIRC) to minimize
overhead, making the average cost per txid a tiny bit over 36 bytes.
If you receive one of the transactions you request, you can extract the
preimage at no cost to yourself (except bandwidth).  If you don't
receive a transaction, then sending a blind child is hopeless
anyway---your peers won't relay it.

Overall, it's hard for me to guess how effective your proposal would be
at defeating the attack.  I think the strongman argument for the attack
would be that the attacker will be able to perform a targeted relay of
their outdated state to just miners---everyone else on the network
will receive the counterparty's honest final-state close.  Unless the
counterparty happens to have a connection to a miner's node, the
counterparty will neither be able to CPFP fee bump nor use getdata to
retrieve the preimage.

It seems to me it's practical for a motivated attacker to research which
IP addresses belong to miners so that they can target them, whereas
honest users won't practically be able to do that research (and, even if
they could, it would create a centralizing barrier to new miners
entering the market if users focused on maintaining connections to
previously-known miners).

-Dave

[1] You'd have to be careful to not attempt the getdata too soon after
    you think the attacker broadcast their old state, but I think that
    only means waiting a single block, which you have to do anyway to
    see if the honest final-commitment transaction confirmed.  See
    https://github.com/bitcoin/bitcoin/pull/18861


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-06-19 19:59 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 [this message]
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
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=20200619195846.fclw4ilngvbbf2kk@ganymede \
    --to=dave@dtrt.org \
    --cc=bastien@acinq.fr \
    --cc=bitcoin-dev@lists.linuxfoundation.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