Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 88C90C0051 for ; 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 ; 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 ; 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 ; 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 ; Wed, 23 Sep 2020 18:10:35 -0400 Received: by mail-ej1-f49.google.com with SMTP id i26so1662915ejb.12 for ; 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: <20200921145221.76bg5rnw7ohkm3ck@ganymede> In-Reply-To: From: Jeremy Date: Wed, 23 Sep 2020 15:10:22 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Suhas Daftuar , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 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's better to pay a security sensitive engi= neering cost once, than to have to pay it repeatedly and perhaps insufficie= ntly.

Specific responses inline below:

Best,

Jeremy
=C2=A0
>> 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.
> 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've come to accept, such as transaction chains bein= g valid across small reorgs in the absence of malicious (double-spend) beha= vior.

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's also important= to note this property is not preserved against reorgs longer than 100 bloc= ks.
> 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'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.

I think this is possibly co= rrect.

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.

It'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.


> But if policy changes a= re the direction we'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>> 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'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 pre= vents additional child transactions and makes it more expensive to RBF).

It'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.

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 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't think that approaches in that direction w= ould be unique to this proposal.

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).


>> We allow one Sponsor to replace an= other subject to normal replacement policies, they are treated as conflicts= .
> 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.

If you'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.
=


> 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.

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 c= oordinate.

Given the complexity of CPFP, it'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).

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.

<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r= gb(0,0,0)" class=3D"gmail_default">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.



2)
Third parties can already -- trustf= ully -- insert themselves into another'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.

3)
=
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. 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, bu= t it's fine either way.

4)
It'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.

<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r= gb(0,0,0)" class=3D"gmail_default">5)
The behavior of sponsors is already emulable in a transac= tion graph. A more complicated construction is possible that's a more a= ccurate 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 th= e block to an OP_RETURN.
<= b>
Then it would be pos= sible 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 mechani= sm into this transaction graph (and back again), I don't see a sponsors= mechanism as breaking any strong inherent property of the transaction grap= h, it's merely an optimization of a pattern that could be implemented w= ithout breaking the property.
=
Therefore I am unco= ncerned with the impact that a sponsors-like mechanism has on the propertie= s of the transaction graph itself.


=


<= br>


--0000000000003cfdb805b0025af8--