path: root/d1/d7081e666f2e8db1362c7afcfda3d5c6051f2d

Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C9A9FC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Jun 2020 06:43:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id B184487D80
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Jun 2020 06:43:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ztnWYhR-4tcZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Jun 2020 06:43:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 5313587D65
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Jun 2020 06:43:53 +0000 (UTC)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com
 [209.85.166.47]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0586hoO7006617
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 8 Jun 2020 02:43:51 -0400
Received: by mail-io1-f47.google.com with SMTP id m81so17389594ioa.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 07 Jun 2020 23:43:51 -0700 (PDT)
X-Gm-Message-State: AOAM533SPPbX1Zr8tce3p//+DSyuRFfHy1q/937EXm+zEF7wFZVAbPKc
 fdaCV5kE8wBCr3UB91yFdSKeBmmSWWyn8BsPWh8=
X-Google-Smtp-Source: ABdhPJy5Qm3dMrJ/PmeVqPhAAehM5tQ9HOXvabgN0/If0l5y8odF+Wax6cTw58pTlAyYzliumzQc9sI+tXREqcfrMZI=
X-Received: by 2002:a6b:fd18:: with SMTP id c24mr19271249ioi.97.1591598630524; 
 Sun, 07 Jun 2020 23:43:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
 <1cQUGt1pX0_lWPJm-tFDr9fQCvrPd5vqmCorgN89jy7gUF0m9wsouUosrFm1eal3jO9oB1BvMtORGE2htLdFjyDD5lno_QkXCFn971LQNZY=@protonmail.com>
 <CAD5xwhhZyAkQE3DpLku_xrOnixL344AqkWB=+a=fOBbekobY6g@mail.gmail.com>
 <20200608110545.078f8e81@simplexum.com>
In-Reply-To: <20200608110545.078f8e81@simplexum.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 7 Jun 2020 23:43:39 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
Message-ID: <CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
Cc: Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ff5b3705a78cee11"
Subject: [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2020 06:43:54 -0000

--000000000000ff5b3705a78cee11
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Broke out to a separate thread.

At core, the reason why this method *might* work is that it's essentially
just CPFP but we can guarantee that the link we're examining is always
exactly one hop away, so we get rid of most of the CPFP graph traversal
issues.

Your description largely matches my thinking for how something like this
could work (pay for neighbor). The issue is that the extant CPFP logic is
somewhat brittle and doesn't work as expected (Child not Children, which is
problematic for multiple PFN's).

> PFN transaction would still be valid if some of 'ghost parents' are
already confirmed, so the miners could have more fees than strictly
necessary. But this is the same as with CPFP.

This is problematic and can't be done as it requires a new index of all
past txns for consensus.

My thinking is that a Fee Bump transaction can name a list of TXIDs (Or one
TXID which implies all ancestors of) that it wishes to be included in a
block with. It must be included in that block. A Fee Bump transaction may
have no unconfirmed ancestors nor any children. Potentially, it also may
not be RBF'd. You treat the Fee Bump Transactions as the lowest descendant
of whatever it targets and then set it's feerate/total fee based on the
package that would have to co-confirm for it to be worth mining. This makes
it sort like normal transactions for inclusion. You can require some
minimums for mempool inclusion at all.

If it's target is confirmed or replaced, it should drop from the mempool.

Transactions in the mempool may set a flag that opts out of CPFP for
descendants/blocks any descendants. Channel protocols should set this bit
to prevent pinning, and then use the Fee Bump to add fees to whatever txns
need to go through. If done right you can also layer a coinswap protocol
with the fee-bumping txns change so that you are getting a privacy benefit
at the same time.

BTW the annex *could* be used for this purpose, but it would also be
acceptable to have it be in some kind of anyone can spend output. Then it
would just be a anyone-can-spend tx with OP_CHECK_TXID_IN_BLOCK (or
OP_CHECK_UTXO_SPENT_IN_BLOCK), and a miner could claim all such outputs at
the end of the block. This is worse in terms of on-chain overheads, but
nice in that it's the minimal semantic change & introduces some general
purpose functionality.

But my thoughts are still pretty loose at the moment around it. I suspect
that to make fee bumping work nicely would require removing CPFP entirely,
but I don't know that to be the case concretely.

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Sun, Jun 7, 2020 at 11:02 PM Dmitry Petukhov <dp@simplexum.com> wrote:

> =D0=92 Sun, 7 Jun 2020 15:45:16 -0700
> Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > What I think we'll eventually land on is a way of doing a tx
> > that contributes fee to another tx chain as a passive observer to
> > them. While this breaks one abstraction around how dependencies
> > between transactions are processed, it also could help resolve some
> > really difficult challenges we face with application-DoS (pinning and
> > other attacks) in the mempool beyond CTV. I have a napkin design for
> > how this could work, but nothing quite ready to share yet.
>
> I had an idea of 'Pay for neighbor' transaction where a transaction
> that is not directly a child of some other transaction can specify that
> it wants to pay the fee for that other transaction(s). It can become
> like 'ghost child' transaction for them, in what it cannot be mined
> unless its 'ghost parents' are confirmed, too. It will be like CPFP,
> but without direct dependency via inputs. Such 'PFN' transaction would
> not spend any coins beside what it specifies in its own inputs, of
> course.
>
> The idea required a hardfork at first, but Anthony Towns suggested
> a way to make it into a soft fork (past-taproot) by putting the txids of
> 'ghost parents' into taproot annex.
>
> PFN transaction would still be valid if some of 'ghost parents' are
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>
> Looking at the mempool code, it seems that only a way how parent/child
> transactions relationships are established will need to be adjusted to
> account for this 'ghost relationships', and once established, other
> logic will work as with CPFP. There could be complications regarding
> transaction package size. But I cannot claim that I understand that
> code enough to say something about this with certainty.
>
>

--000000000000ff5b3705a78cee11
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Broke ou=
t to a separate thread.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000">At core, the reason why this method *might* w=
ork is that it&#39;s essentially just CPFP but we can guarantee that the li=
nk we&#39;re examining is always exactly one hop away, so we get rid of mos=
t of the CPFP graph traversal issues.</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:#000000">Your description largely matche=
s my thinking for how something like this could work (pay for neighbor). Th=
e issue is that the extant CPFP logic is somewhat brittle and doesn&#39;t w=
ork as expected (Child not Children, which is problematic for multiple PFN&=
#39;s).</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">&gt; PFN transaction would still be valid if some of &#39;gho=
st parents&#39; are<br>
already confirmed, so the miners could have more fees than strictly<br>
necessary. But this is the same as with CPFP.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000">This is problematic and=
 can&#39;t be done as it requires a new index of all past txns for consensu=
s.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000">My thinking is that a Fee Bump transaction can name a list of TXID=
s (Or one TXID which implies all ancestors of) that it wishes to be include=
d in a block with. It must be included in that block. A Fee Bump transactio=
n may have no unconfirmed ancestors nor any children. Potentially, it also =
may not be RBF&#39;d. You treat the Fee Bump Transactions as the lowest des=
cendant of whatever it targets and then set it&#39;s feerate/total fee base=
d on the package that would have to co-confirm for it to be worth mining. T=
his makes it sort like normal transactions for inclusion. You can require s=
ome minimums for mempool inclusion at all.</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">If it&#39;s target is conf=
irmed or replaced, it should drop from the mempool.</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">Transactions in t=
he mempool may set a flag that opts out of CPFP for descendants/blocks any =
descendants. Channel protocols should set this bit to prevent pinning, and =
then use the Fee Bump to add fees to whatever txns need to go through. If d=
one right you can also layer a coinswap protocol with the fee-bumping txns =
change so that you are getting a privacy benefit at the same time.</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">B=
TW the annex *could* be used for this purpose, but it would also be accepta=
ble to have it be in some kind of anyone can spend output. Then it would ju=
st be a anyone-can-spend tx with OP_CHECK_TXID_IN_BLOCK (or OP_CHECK_UTXO_S=
PENT_IN_BLOCK), and a miner could claim all such outputs at the end of the =
block. This is worse in terms of on-chain overheads, but nice in that it&#3=
9;s the minimal semantic change &amp; introduces some general purpose funct=
ionality. <br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">But my thoughts are still pretty loose at the moment=
 around it. I suspect that to make fee bumping work nicely would require re=
moving CPFP entirely, but I don&#39;t know that to be the case concretely. =
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div><div dir=3D"ltr" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https:=
//twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"htt=
ps://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Sun, Jun 7, 2020 at 11:02 PM Dmitry Petukhov &lt;<a href=3D"mailto:dp@sim=
plexum.com" target=3D"_blank">dp@simplexum.com</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">=D0=92 Sun, 7 Jun 2020 15:45:=
16 -0700<br>
Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br>
<br>
&gt; What I think we&#39;ll eventually land on is a way of doing a tx<br>
&gt; that contributes fee to another tx chain as a passive observer to<br>
&gt; them. While this breaks one abstraction around how dependencies<br>
&gt; between transactions are processed, it also could help resolve some<br=
>
&gt; really difficult challenges we face with application-DoS (pinning and<=
br>
&gt; other attacks) in the mempool beyond CTV. I have a napkin design for<b=
r>
&gt; how this could work, but nothing quite ready to share yet.<br>
<br>
I had an idea of &#39;Pay for neighbor&#39; transaction where a transaction=
<br>
that is not directly a child of some other transaction can specify that<br>
it wants to pay the fee for that other transaction(s). It can become<br>
like &#39;ghost child&#39; transaction for them, in what it cannot be mined=
<br>
unless its &#39;ghost parents&#39; are confirmed, too. It will be like CPFP=
,<br>
but without direct dependency via inputs. Such &#39;PFN&#39; transaction wo=
uld<br>
not spend any coins beside what it specifies in its own inputs, of<br>
course.<br>
<br>
The idea required a hardfork at first, but Anthony Towns suggested<br>
a way to make it into a soft fork (past-taproot) by putting the txids of<br=
>
&#39;ghost parents&#39; into taproot annex.<br>
<br>
PFN transaction would still be valid if some of &#39;ghost parents&#39; are=
<br>
already confirmed, so the miners could have more fees than strictly<br>
necessary. But this is the same as with CPFP.<br>
<br>
Looking at the mempool code, it seems that only a way how parent/child<br>
transactions relationships are established will need to be adjusted to<br>
account for this &#39;ghost relationships&#39;, and once established, other=
<br>
logic will work as with CPFP. There could be complications regarding<br>
transaction package size. But I cannot claim that I understand that<br>
code enough to say something about this with certainty.<br>
<br>
</blockquote></div></div>

--000000000000ff5b3705a78cee11--