public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Matt Corallo <lf-lists@mattcorallo.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
Date: Fri, 30 Nov 2018 12:38:04 -0500	[thread overview]
Message-ID: <CAMZUoKnF65_4V6Lngg2eO2R+maqahEOzpgt=Z3EN5xTmMY=LKA@mail.gmail.com> (raw)
In-Reply-To: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>

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

On Fri, Nov 30, 2018 at 9:50 AM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> To partially-address the CPFP security model considerations, a next step
> might involve tweaking Lightning's commitment transaction to have two
> small-value outputs which are immediately spendable, one by each channel
> participant, allowing them to chain children off without allowng
> unrelated third-parties to chain children. Obviously this does not
> address the specific attack so we need a small tweak to the anti-DoS
> CPFP rules in Bitcoin Core/BIP 125:
>

It seems to me that this two-output scheme does address the specific attack
without tweaking the RBF rules of BIP 125, since you are not doing an RBF
at all.

Suppose we have a 1k-vbyte unconfirmed transaction, TX0, with outputs Z, A,
and B, where A and B are small outputs controlled by the participants Alice
and Bob respectively, with a 1ksat fee, yielding a fee rate of 1sat/vbyte.
Someone, maybe Alice, attempts to pin the transaction, maliciously or not,
by attaching a 10k-vbyte transaction, TX1, to either output Z or output A,
with a fee of 21ksats.  This brings the fee rate for the TX0-TX1 package to
2sat/vbyte, being 11k-vbyte total size with 22ksats in total fees.

Now Bob wants to CPFP to increase the effective fee rate of TX0 to
3sats/vbyte using output B.  He attaches a 1k-vbyte transaction, TX2, to
output B with a fee of 5ksats.  This ought to create a new TX0-TX2 package
with a 3sat/vbyte fee rate, being 2k-vbyte total size with 6ksats in total
fees.  TX1 has now been excluded from the package containing TX0. But TX1
hasn't been replaced, so the RBF rules from BIP125 don't apply.  TX1 is
still a valid unconfirmed transaction operating at a fee rate of
2.1sats/vbyte.

That said, I'm not an expert on how packages and package fee rates are
calculated in Bitcoin Core, so I am speculating a bit.  And, because I'm
talking with Matt, it's more likely that I'm mistaken.  AFAIK, any rules
about CPFP's behaviour in Bitcoin Core is undocumented.

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

  reply	other threads:[~2018-11-30 17:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 19:37 [bitcoin-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning) Matt Corallo
2018-11-30 17:38 ` Russell O'Connor [this message]
2018-11-30 19:33   ` Matt Corallo
2018-12-02 15:08 ` Bob McElrath
2018-12-03  4:16   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-12-04  3:33 ` Rusty Russell
2019-01-07 15:18   ` Matt Corallo
2019-01-08  5:50     ` Rusty Russell
2019-01-08 14:46       ` Matt Corallo
2019-02-13  4:22         ` Rusty Russell
2019-10-24 13:49           ` Johan Torås Halseth
2019-10-24 21:25             ` Matt Corallo
2019-10-25  7:05               ` Johan Torås Halseth
2019-10-25 17:30                 ` Matt Corallo
2019-10-27 19:13                   ` Jeremy
2019-10-28  9:45                     ` Johan Torås Halseth
2019-10-28 17:14                       ` David A. Harding
2019-10-30  7:22                         ` Johan Torås Halseth
2019-10-27 22:54             ` David A. Harding

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='CAMZUoKnF65_4V6Lngg2eO2R+maqahEOzpgt=Z3EN5xTmMY=LKA@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --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