path: root/c2/f20baf05ba5a6743146a4f15f105b67014e9f1

Return-Path: <jlrubin@mit.edu>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 88C90C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Sep 2020 22:10:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 5CF5486A1A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Sep 2020 22:10:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Grlw9wagNdhf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Sep 2020 22:10:37 +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 whitealder.osuosl.org (Postfix) with ESMTPS id 129F9869EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Sep 2020 22:10:36 +0000 (UTC)
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com
 [209.85.218.49]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08NMAYsV019427
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Sep 2020 18:10:35 -0400
Received: by mail-ej1-f49.google.com with SMTP id i26so1662915ejb.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Sep 2020 15:10:35 -0700 (PDT)
X-Gm-Message-State: AOAM530eOmQEYe4dI2BNQBhiQNMn43w3nfBgfXwqoa9umGXRIF/xPjNp
 xGLD8ByKZbkZfMHdvBqeG9WoQD+hZyaEZn1N6TQ=
X-Google-Smtp-Source: ABdhPJw1nbFj1Wf3yI8xIygoIlkrHfksMZFeDnxOfqi1se70IgjVFQEmvwfEdTO6XXEoIRbisxS28J4lATjKyYu9+Jc=
X-Received: by 2002:a17:907:b0c:: with SMTP id
 h12mr1658678ejl.115.1600899033919; 
 Wed, 23 Sep 2020 15:10:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
 <CALZpt+FbRGrcW7LZY=4NtR9w4CP=kavVdqutfrX86OYnouHUJg@mail.gmail.com>
 <CALZpt+EAWbPWh_knT7yDdPT396jEL1g+XSEv1JALuwaJVqNS7w@mail.gmail.com>
 <CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com>
 <CALZpt+HtuVC6YmZvABaZUWmN9c3pV1FnX1UUJgGbd_iLuuU8hg@mail.gmail.com>
 <20200921145221.76bg5rnw7ohkm3ck@ganymede>
 <CAD5xwhiwhCEZdpfXc9Z1kePaoSc7qAoin6Sz3zdRWWr67zNm3g@mail.gmail.com>
 <CAFp6fsG8Wu12bnu3jN38Gz3xf5o9tg9Nf8eiMK_e4eW3+RyWZg@mail.gmail.com>
In-Reply-To: <CAFp6fsG8Wu12bnu3jN38Gz3xf5o9tg9Nf8eiMK_e4eW3+RyWZg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 23 Sep 2020 15:10:22 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhiOFQgkewji0Nd4cYkD-kSH396=YsJ6aw5pzZiGhRutA@mail.gmail.com>
Message-ID: <CAD5xwhhiOFQgkewji0Nd4cYkD-kSH396=YsJ6aw5pzZiGhRutA@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003cfdb805b0025af8"
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
 TXID Dependencies for Fee Sponsoring
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: Wed, 23 Sep 2020 22:10:39 -0000

--0000000000003cfdb805b0025af8
Content-Type: text/plain; charset="UTF-8"

Hi Suhas,

Thanks for your thoughtful response!

Overall I'll boil down my thoughts to the following:

If we can eventually come up with something clever at the user+policy layer
to emulate a sponsor like mechanism, I would still greatly prefer to expose
that sort of functionality directly and in a fully-abstracted usable way
for the minimum amount of mempool attack risk in 2nd layer protocols, even
at the expense of some base layer complexity. It's better to pay a security
sensitive engineering cost once, than to have to pay it repeatedly and
perhaps insufficiently.

Specific responses inline below:

Best,

Jeremy

>> The Sponsor Vector TXIDs must also be in the block the transaction is
validated in, with no restriction on order or on specifying a TXID more
than once.
> That means that if a transaction is confirmed in a block without its
sponsor, the sponsor is no longer valid.  This breaks a design principle
that has been discussed many times over the years, which is that once a
valid transaction is created, it should not become invalid later on unless
the inputs are double-spent.  This principle has some logical consequences
that we've come to accept, such as transaction chains being valid across
small reorgs in the absence of malicious (double-spend) behavior.

*Certainly, this property is strictly broken by this proposal. It does not
break the weaker property that the transactions can be reorged onto another
chain, however (like OP_GETBLOCKHASH or similar would), which is important
to note. It's also important to note this property is not preserved against
reorgs longer than 100 blocks.*

> I think that this principle is a useful one and that there should be a
high bar for doing away with it.  And it seems to me that this proposal
doesn't clear that bar -- the fee bumping improvement that this proposal
aims at is really coming from the policy change, rather than the consensus
change.

*I think this is possibly correct.*

*IMO the ability to implement the policy changes is purely derived from the
consensus changes. The consensus changes add a way of third parties to a
transaction to specify economic interest in the resolution of a
transaction. This requires a consensus change to work generically and
without forethought.*


*It's possible that with specific planning or opt-in, you can make
something roughly equivalent. But such a design might also consume more
bandwidth on-chain as you would likely have to e.g. always include a CPFP
hook output.*


> But if policy changes are the direction we're going to solve these
problems, we could instead just propose new policy rules for the existing
types of transaction chaining that we have, rather than couple them to a
new transaction type.
>
> My understanding of the main benefit of this approach is that this allows
3rd parties to participate in fee bumping.  But that behavior strikes me as
also problematic, because it introduces the possibility of 3rd party
griefing, to the extent that sponsor transactions in any way limit chains
of transactions that would be otherwise permitted.  If Alice sends Bob some
coins, and Alice and Bob are both honest and cooperating, Mallory shouldn't
be able to interfere with their low-feerate transaction by (eg) pinning it
with a large transaction that "sponsors" it (ie a large transaction that is
just above the feerate of the parent, which prevents additional child
transactions and makes it more expensive to RBF).

*It's possible to modify my implementation of the policy such that there is
no ability to interfere with the otherwise permitted limits, it just
requires a little bit more work to always discount sponsors on the
descendant counting.*


*W.r.t. griefing, the proposed amendment to limit sponsors to 1000 bytes
minimizes this concern. Further, pinning in this context is mainly an issue
if Alice and Bob are intending to RBF a transaction, at a policy level we
could make Sponsoring require that the transaction be RBF opted-out (or
sponsor opted in). *


> This last issue of pinning could be improved in this proposal by
requiring that a sponsor transaction bring the effective feerate of its
package up to something which should be confirmed soon (rather than just
being a higher feerate than the tx it is sponsoring).  However, we could
also carve out a policy rule just like that today, without any consensus
changes needed, to help with pinning (which is probably a good idea!  I
think this would be useful work).  So I don't think that approaches in that
direction would be unique to this proposal.

*I agree this is useful work and something that Ranked indexes would help
with if I understand them correctly, and can be worked on independently of
Sponsors. Overall I am skeptical that we want to accept any child if it
puts something into an upper percentile as we still need to mind our DoS
budgets (which the sponsors implementation keeps a tight bound on). *


>> We allow one Sponsor to replace another subject to normal replacement
policies, they are treated as conflicts.
> This policy rule of allowing sponsor transactions to RBF each other also
seems problematic; that means that if Alice is paying Bob in a transaction
that is also sponsoring some other transaction (perhaps from Alice to
someone else), then Mallory can cause the transaction going to Bob to
become invalid by RBF bumping it and sponsoring the parent transaction
herself?  Allowing 3rd parties to interfere with transactions between
others seems like a complex and undesirable design to introduce.

*If you'll note in the BIP draft text and implementation recursive
sponsoring is not permitted by policy for this reason. Sponsors may not
sponsor a transaction that is sponsoring another transaction, and a further
restriction that sponsors may not have any children.*


> In summary: this proposal seems like a CPFP replacement, requiring many
policy rules along with a consensus change to be worked out to get right; I
think we could achieve largely the same effect by improving the current
policy rules to make CPFP work better without a consensus change.  And
while what is unique about this proposal is that it allows for 3rd parties
to attach themselves to the transaction graph of other parties, I think
that is a complex interaction to introduce and has negative side effects as
well.


*This is where I most significantly disagree. Some thoughts below on why a
consensus change is likely required for this and why the sponsors mechanism
may not be that invasive (if done right) on the way we currently understand
the transaction graph.*


*1)*
*The main issue with CPFP like mechanisms is that they require an
omniscient like behavior around how to coordinate.*


*Given the complexity of CPFP, it's not possible to ever abstract its use
from the contract protocol you are implementing. It always requires deep
integration into any protocol as a mechanism, and many bespoke protocols
for game theoretically ensuring you can pay fees is much more brittle than
one higher-order composable mechanism (which is what sponsors aims to
achieve, but may fall short on in current incarnation).*


*Further, CPFP based protocols can be wasteful, requiring at least one CPFP
hook/anchor output per participant always. These CPFP hooks need a mempool
CPFP exemption (so that you don't get pinned by a sibling), which will have
to apply recursively in case your payment protocol is not at the base of a
transaction chain (as can happen within a multiparty channel factory). Thus
CPFP as a mechanism inherently suffers from chain bloat issues and it
composes poorly when used recursively.*


*I think it will be essentially impossible to generically handle CPFP based
on transaction graph anchors both from a protocol implementers side and
from a mempool policy side. And in the event that a new attack is
discovered, a mechanism that works with fewer assumptions about the setup
of your protocol should be more robust, or at least fixable. Whereas with a
pure CPFP transaction graph based design, once you are pinned, it may be
impossible to externally correct the incentives. *




*2)*
*Third parties can already -- trustfully -- insert themselves into
another's transaction chain by bribing mining pools to escalate priority of
a transaction. These out-of-band fees are somewhat inevitable, so if your
protocol is not robust against 3rd party feerate boosting you may have
larger issues.*

*3)*
*Because we already do not handle 100 block reorgs with the replayability
property, one fine change to the BIP would be to enforce a 100 block
maturing period on sponsor transactions outputs after confirmation. This
might make usage a little bit more unwieldy, but then it would not have the
issue on small reorg validity.* *I believe this could be safely done* *only
via policy and not consensus, as if someone wants to double spend a
transaction in a reorg they can, but it's fine either way.*

*4)*

*It's not particularly important that a transaction be in the same block
once sponsored, it could also be in the last 100 blocks (the opposite of
proposed change 3). The main benefit to having same-block resolution is
that you never pay for something that would have gone in anyways, but this
mechanism could actually be generically useful if you are operating a
business and need to make reorg safe payments contingent on funds received
into cold-storage. This implies a new rolling index of txids, which has
some overhead, but combined with appropriate mempool policy (e.g., a 200
block txid index in consensus and only a 100 block index available by
mempool policy) would ensure that most reorgs could be handled cleanly.*


*5)*
*The behavior of sponsors is already emulable in a transaction graph. A
more complicated construction is possible that's a more accurate emulation,
but a simple version is as follows:*


*if you were to require:*

*A) All non-sponsor transactions include a single CPFP anchor output/CPFP
hook with an OP_TRUE as the last output*

*B) Miners sweep all OP_TRUE outputs at the end of the block to an
OP_RETURN.*


*Then it would be possible for third parties to be a sponsor by spending
that OP_TRUE output.*

*With a couple modifications (happy to discuss off-list, they end up being
aggregately more complicated than the sponsors mechanism) this can also
permit multiple sponsors in the same block.*

*Because it's possible to convert sponsors mechanism into this transaction
graph (and back again), I don't see a sponsors mechanism as breaking any
strong inherent property of the transaction graph, it's merely an
optimization of a pattern that could be implemented without breaking the
property.*

*Therefore I am unconcerned with the impact that a sponsors-like mechanism
has on the properties of the transaction graph itself.*

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">Hi Suhas,</div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">Thanks for your thoughtful response!<br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Overall I=
&#39;ll boil down my thoughts to the following:</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">If we can eventually =
come up with something clever at the user+policy layer to emulate a sponsor=
 like mechanism, I would still greatly prefer to expose that sort of functi=
onality directly and in a fully-abstracted usable way for the minimum amoun=
t of  mempool attack risk in  2nd layer protocols, even at the expense of s=
ome base layer complexity. It&#39;s better to pay a security sensitive engi=
neering cost once, than to have to pay it repeatedly and perhaps insufficie=
ntly.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:#000000">Specific responses inline below:</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000">Best,</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy<b=
r></div><div>=C2=A0</div>&gt;<span class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">&gt;</spa=
n> The Sponsor Vector TXIDs must also be in the block the transaction is va=
lidated in, with no restriction on order or on specifying a TXID more than =
once.<br>&gt; That means that if a transaction is confirmed in a block with=
out its sponsor, the sponsor is no longer valid.=C2=A0 This breaks a design=
 principle that has been discussed many times over the years, which is that=
 once a valid transaction is created, it should not become invalid later on=
 unless the inputs are double-spent.=C2=A0 This principle has some logical =
consequences that we&#39;ve come to accept, such as transaction chains bein=
g valid across small reorgs in the absence of malicious (double-spend) beha=
vior.<br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te"><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)" class=3D"gmail_default"><b>Certainly, this property is stri=
ctly broken by this proposal. It does not break the weaker property that th=
e transactions can be reorged onto another chain, however (like OP_GETBLOCK=
HASH or similar would), which is important to note. It&#39;s also important=
 to note this property is not preserved against reorgs longer than 100 bloc=
ks.</b><br><b></b></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b></b></div><b=
r>&gt; I think that this principle is a useful one and that there should be=
 a high bar for doing away with it.=C2=A0 And it seems to me that this prop=
osal doesn&#39;t clear that bar -- the fee bumping improvement that this pr=
oposal aims at is really coming from the policy change, rather than the con=
sensus change.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote"><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><b>I think this is possibly co=
rrect.</b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)" class=3D"gmail_default"><b>IMO the ability to implement the policy ch=
anges is purely derived from the consensus changes. The consensus changes a=
dd a way of third parties to a transaction to specify economic interest in =
the resolution of a transaction. This requires a consensus change to work g=
enerically and without forethought.</b></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_def=
ault"><b><br></b></div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>It&#39;s poss=
ible that with specific planning or opt-in, you can make something roughly =
equivalent. But such a design might also consume more bandwidth on-chain as=
 you would likely have to e.g. always include a CPFP hook output.<br></b></=
div><br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e"><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">&gt; </span>But if policy changes a=
re the direction we&#39;re going to solve these problems, we could instead =
just propose new policy rules for the existing types of transaction chainin=
g that we have, rather than couple them to a new transaction type.<br>&gt;<=
br>&gt; My understanding of the main benefit of this approach is that this =
allows 3rd parties to participate in fee bumping.=C2=A0 But that behavior s=
trikes me as also problematic, because it introduces the possibility of 3rd=
 party griefing, to the extent that sponsor transactions in any way limit c=
hains of transactions that would be otherwise permitted.=C2=A0 If Alice sen=
ds Bob some coins, and Alice and Bob are both honest and cooperating, Mallo=
ry shouldn&#39;t be able to interfere with their low-feerate transaction by=
 (eg) pinning it with a large transaction that &quot;sponsors&quot; it (ie =
a large transaction that is just above the feerate of the parent, which pre=
vents additional child transactions and makes it more expensive to RBF).</d=
iv><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><b>It&#39;s possible to modify my implementatio=
n of the policy such that there is no ability to interfere with the otherwi=
se permitted limits, it just requires a little bit more work to always disc=
ount sponsors on the descendant counting.</b></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default"><b><br></b></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>W.r.t. =
griefing, the proposed amendment to limit sponsors to 1000 bytes minimizes =
this concern. Further, pinning in this context is mainly an issue if Alice =
and Bob are intending to RBF a transaction, at a policy level we could make=
 Sponsoring require that the transaction be RBF opted-out (or sponsor opted=
 in). <br></b></div><br></div><div class=3D"gmail_quote"><br>&gt; This last=
 issue of pinning could be improved in this proposal by requiring that a sp=
onsor transaction bring the effective feerate of its package up to somethin=
g which should be confirmed soon (rather than just being a higher feerate t=
han the tx it is sponsoring).=C2=A0 However, we could also carve out a poli=
cy rule just like that today, without any consensus changes needed, to help=
 with pinning (which is probably a good idea!=C2=A0 I think this would be u=
seful work).=C2=A0 So I don&#39;t think that approaches in that direction w=
ould be unique to this proposal.<br></div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote"><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>I agr=
ee this is useful work and something that Ranked indexes would help with if=
 I understand them correctly, and can be worked on independently of Sponsor=
s. Overall I am skeptical that we want to accept any child if it puts somet=
hing into an upper percentile as we still need to mind our DoS budgets (whi=
ch the sponsors implementation keeps a tight bound on). </b></div><br></div=
><div class=3D"gmail_quote"><br>&gt;&gt; We allow one Sponsor to replace an=
other subject to normal replacement policies, they are treated as conflicts=
.<br>&gt; This policy rule of allowing sponsor transactions to RBF each oth=
er also seems problematic; that means that if Alice is paying Bob in a tran=
saction that is also sponsoring some other transaction (perhaps from Alice =
to someone else), then Mallory can cause the transaction going to Bob to be=
come invalid by RBF bumping it and sponsoring the parent transaction hersel=
f?=C2=A0 Allowing 3rd parties to interfere with transactions between others=
 seems like a complex and undesirable design to introduce.<br></div><div cl=
ass=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><b>If you&#39;ll note in the BIP draft text and implemen=
tation recursive sponsoring is not permitted by policy for this reason. Spo=
nsors may not sponsor a transaction that is sponsoring another transaction,=
 and a further restriction that sponsors may not have any children.</b><br>=
</div><br></div><div class=3D"gmail_quote"><br>&gt; In summary: this propos=
al seems like a CPFP replacement, requiring many policy rules along with a =
consensus change to be worked out to get right; I think we could achieve la=
rgely the same effect by improving the current policy rules to make CPFP wo=
rk better without a consensus change.=C2=A0 And while what is unique about =
this proposal is that it allows for 3rd parties to attach themselves to the=
 transaction graph of other parties, I think that is a complex interaction =
to introduce and has negative side effects as well.</div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote"><div style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_de=
fault"><b>This is where I most significantly disagree. Some thoughts below =
on  why a consensus change is likely required for this and why the sponsors=
 mechanism may not be that invasive (if done right) on the way we currently=
 understand the transaction graph.<br></b></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default"><b><br></b></div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>1)<br></b>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default"><b>The main issue with CPFP like =
mechanisms is that they require an omniscient like behavior around how to c=
oordinate.</b></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><b>Given the complexity of CPFP, it&#39;s=
 not possible to ever abstract its use from the contract protocol you are i=
mplementing. It always requires deep integration into any protocol as a mec=
hanism, and many bespoke protocols for game theoretically ensuring you can =
pay fees is much more brittle than one higher-order composable mechanism (w=
hich is what sponsors aims to achieve, but may fall short on in current inc=
arnation).<br></b></div><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)" class=3D"gmail_default"><b>Further, CPFP based protocols can =
be wasteful,  requiring at least one CPFP hook/anchor output per participan=
t always. These CPFP hooks  need a mempool CPFP exemption (so that you don&=
#39;t get pinned by a sibling), which will have to apply recursively in cas=
e your payment protocol is not at the base of a transaction chain (as can h=
appen within a multiparty channel factory). Thus CPFP as a mechanism inhere=
ntly suffers from chain bloat issues and it composes poorly when used recur=
sively.<br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)" class=3D"gmail_default"><b>I think it will be essentially imposs=
ible to generically handle CPFP based on transaction graph anchors both fro=
m a protocol implementers side and from a mempool policy side. And in the e=
vent that a new attack is discovered, a mechanism that works with fewer ass=
umptions about the setup of your protocol should be more robust, or at leas=
t fixable. Whereas with a pure CPFP transaction graph based design, once yo=
u are pinned, it may be impossible to externally correct the incentives. <b=
r></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><b><br></b></div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defau=
lt"><b><br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>2)<br></b></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)" class=3D"gmail_default"><b>Third parties can already -- trustf=
ully -- insert themselves into another&#39;s transaction chain by bribing m=
ining pools to escalate priority of a transaction. These out-of-band fees a=
re somewhat inevitable, so if your protocol is not robust against 3rd party=
 feerate boosting you may have larger issues.</b></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>3)</b><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default"><b>Because we already do not hand=
le 100 block reorgs with the replayability property, one fine change to the=
 BIP would be to enforce a 100 block maturing period on sponsor transaction=
s outputs after confirmation. This might make usage a little bit more unwie=
ldy, but then it would not have the issue on small reorg validity.</b> <b>I=
 believe this could be safely done</b> <b>only via policy and not consensus=
, as if someone wants to double spend a transaction in a reorg they can, bu=
t it&#39;s fine either way.</b></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b=
><br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>4)</b></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default"><b>It&#39;s not particularly important that a tr=
ansaction be in the same block once sponsored, it could also be in the last=
 100 blocks (the opposite of proposed change 3). The main benefit to having=
 same-block resolution is that you never pay for something that would have =
gone in anyways, but this mechanism could actually be generically useful if=
 you are operating a business and need to make reorg safe payments continge=
nt on funds received into cold-storage. This implies a new rolling index of=
 txids, which has some overhead, but combined with appropriate mempool poli=
cy (e.g., a 200 block txid index in consensus and only a 100 block index av=
ailable by mempool policy) would ensure that most reorgs could be handled c=
leanly.<br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)" class=3D"gmail_default"><b>5)<br></b></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default"><b>The behavior of sponsors is already emulable in a transac=
tion graph. A more complicated construction is possible that&#39;s a more a=
ccurate emulation, but a simple version is as follows:</b></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><b><br></b></div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defau=
lt"><b>if you were to require:<br></b></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult"><b>A) All non-sponsor transactions include a single CPFP anchor output=
/CPFP hook with an OP_TRUE as the last output<br></b></div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" clas=
s=3D"gmail_default"><b>B) Miners sweep all OP_TRUE outputs at the end of th=
e block to an OP_RETURN.<br></b></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><=
b><br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>Then it would be pos=
sible for third parties to be a sponsor by spending that OP_TRUE output.<br=
></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><b>With a couple modifications (happy to discuss =
off-list, they end up being aggregately more complicated than the sponsors =
mechanism) this can also permit multiple sponsors in the same block.</b></d=
iv><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><b>Because it&#39;s possible to convert sponsors mechani=
sm into this transaction graph (and back again), I don&#39;t see a sponsors=
 mechanism as breaking any strong inherent property of the transaction grap=
h, it&#39;s merely an optimization of a pattern that could be implemented w=
ithout breaking the property.</b></div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">=
<b><br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>Therefore I am unco=
ncerned with the impact that a sponsors-like mechanism has on the propertie=
s of the transaction graph itself.</b></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult"><b><br></b></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)" class=3D"gmail_default"><b><br></b></div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default"><b><br></b></div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b></b><=
br></div><br></div><div class=3D"gmail_quote"><br></div></div>

--0000000000003cfdb805b0025af8--