public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Johan Torås Halseth" <johanth@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
Date: Fri, 25 Oct 2019 09:05:15 +0200	[thread overview]
Message-ID: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com> (raw)
In-Reply-To: <83915e8a-f49a-8233-0389-934c189f770c@mattcorallo.com>

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

It essentially changes the rule to always allow CPFP-ing the commitment as
long as there is an output available without any descendants. It changes
the commitment from "you always need at least, and exactly, one non-CSV
output per party. " to "you always need at least one non-CSV output per
party. "

I realize these limits are there for a reason though, but I'm wondering if
could relax them. Also now that jeremyrubin has expressed problems with the
current mempool limits.

On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> I may be missing something, but I'm not sure how this changes anything?
>
> If you have a commitment transaction, you always need at least, and
> exactly, one non-CSV output per party. The fact that there is a size
> limitation on the transaction that spends for carve-out purposes only
> effects how many other inputs/outputs you can add, but somehow I doubt
> its ever going to be a large enough number to matter.
>
> Matt
>
> On 10/24/19 1:49 PM, Johan Torås Halseth wrote:
> > Reviving this old thread now that the recently released RC for bitcoind
> > 0.19 includes the above mentioned carve-out rule.
> >
> > In an attempt to pave the way for more robust CPFP of on-chain contracts
> > (Lightning commitment transactions), the carve-out rule was added in
> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked on
> > an implementation of a new commitment format for utilizing the Bring
> > Your Own Fees strategy using CPFP, I’m wondering if the special case
> > rule should have been relaxed a bit, to avoid the need for adding a 1
> > CSV to all outputs (in case of Lightning this means HTLC scripts would
> > need to be changed to add the CSV delay).
> >
> > Instead, what about letting the rule be
> >
> > The last transaction which is added to a package of dependent
> > transactions in the mempool must:
> >   * Have no more than one unconfirmed parent.
> >
> > This would of course allow adding a large transaction to each output of
> > the unconfirmed parent, which in effect would allow an attacker to
> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
> > this a problem with the current mempool acceptance code in bitcoind? I
> > would imagine evicting transactions based on feerate when the max
> > mempool size is met handles this, but I’m asking since it seems like
> > there has been several changes to the acceptance code and eviction
> > policy since the limit was first introduced.
> >
> > - Johan
> >
> >
> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty@rustcorp.com.au
> > <mailto:rusty@rustcorp.com.au>> wrote:
> >
> >     Matt Corallo <lf-lists@mattcorallo.com
> >     <mailto:lf-lists@mattcorallo.com>> writes:
> >     >>> Thus, even if you imagine a steady-state mempool growth, unless
> the
> >     >>> "near the top of the mempool" criteria is "near the top of the
> next
> >     >>> block" (which is obviously *not* incentive-compatible)
> >     >>
> >     >> I was defining "top of mempool" as "in the first 4 MSipa", ie.
> next
> >     >> block, and assumed you'd only allow RBF if the old package wasn't
> >     in the
> >     >> top and the replacement would be.  That seems incentive
> >     compatible; more
> >     >> than the current scheme?
> >     >
> >     > My point was, because of block time variance, even that criteria
> >     doesn't hold up. If you assume a steady flow of new transactions and
> >     one or two blocks come in "late", suddenly "top 4MWeight" isn't
> >     likely to get confirmed until a few blocks come in "early". Given
> >     block variance within a 12 block window, this is a relatively likely
> >     scenario.
> >
> >     [ Digging through old mail. ]
> >
> >     Doesn't really matter.  Lightning close algorithm would be:
> >
> >     1.  Give bitcoind unileratal close.
> >     2.  Ask bitcoind what current expidited fee is (or survey your
> mempool).
> >     3.  Give bitcoind child "push" tx at that total feerate.
> >     4.  If next block doesn't contain unilateral close tx, goto 2.
> >
> >     In this case, if you allow a simpified RBF where 'you can replace if
> >     1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
> >     old tx isnt',
> >     it works.
> >
> >     It allows someone 100k of free tx spam, sure.  But it's simple.
> >
> >     We could further restrict it by marking the unilateral close somehow
> to
> >     say "gonna be pushed" and further limiting the child tx weight (say,
> >     5kSipa?) in that case.
> >
> >     Cheers,
> >     Rusty.
> >     _______________________________________________
> >     Lightning-dev mailing list
> >     Lightning-dev@lists.linuxfoundation.org
> >     <mailto:Lightning-dev@lists.linuxfoundation.org>
> >     https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>

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

  reply	other threads:[~2019-10-25  7:05 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
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 [this message]
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=CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com \
    --to=johanth@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    --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