path: root/30/f8b403bdc51bb86b1f58b717bd8d885e5f72f0

Return-Path: <sdaftuar@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 59813C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Sep 2020 18:05:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 4A23D870AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Sep 2020 18:05:27 +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 iT4040+3cU+S
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Sep 2020 18:05:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com
 [209.85.166.43])
 by hemlock.osuosl.org (Postfix) with ESMTPS id CADDF870AA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Sep 2020 18:05:25 +0000 (UTC)
Received: by mail-io1-f43.google.com with SMTP id y13so20658099iow.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Sep 2020 11:05:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=LvSZtKMc/4Dud5pVcKeDZQxRcaoXdFwQiaoS/bTmhoU=;
 b=re5LQBAT17+08keXbdfpszQqdTEYHDmWLurb3kjQoNMaGx9h72BCP156UbH3/N0chu
 sZ0aCzcHdBBnzRdneYb8BCP1S43xhUDHhAhdB+XvIP16VZ4Tz5RNFceDQQ2+NneUGdgp
 XTlY+8SUN6+uxnyp02Keu+bZ6gTvLujtCcM34lZUPK97w/WIdAh3IvUk1QsXc4S26V+s
 YeEdYxv+OmnjBltJURDKYl3hY2rJX0Vgoxne7DXTFM61ejSe43vK4nSjrpf/ceIpt6ju
 fKi5xkadfLe4y5NKiUMFk9nU7BOTnA702t40BompUU2qJVatTscbgv2R01nARYYKOFOR
 BSYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=LvSZtKMc/4Dud5pVcKeDZQxRcaoXdFwQiaoS/bTmhoU=;
 b=qciMbYFbvbxzBKaEO1Uzg8qZlnQOW5v6SLEZ7pxy4XoQtXV79bsDzNHUJjzuFnuq7F
 IRO551AIGHLML2wVvW2+FULAKuPtjONpilECuiGQ6AeW+zlrnXo5kNe/9uyQFZcdpzX5
 attdFfL/JVJfgKxzMMyZIpbN+MvPAGHM89mPpUqTKiQVzRba7rmln9nuYbxbo44iCrk7
 lBeyAcj4ROn9TtKVRoHga1cITx4OC932n+jEjr2DYKq5pqOj9wMp7iNzrCr+jw//Wp6Z
 T4zox5eb+s/Picfgt1XAVRQciKCCcggqPkfq5ZfvRQZd3/DcZkVSFudn8d0tSMSqjHrk
 Q/vw==
X-Gm-Message-State: AOAM531enPnUyvRkusT51BDLSZZgo2NLW9sT9dHE92soF4OHX+h4bqFM
 ga9TVm4Gv/IZc3pNcPMdDwAXQB8LojnbPeoy0vwmL9e1
X-Google-Smtp-Source: ABdhPJyJneECbmeWz8Wf1iBrnvVMIKnwfdYUpY3SZ236iLLYVJtvWNDnIm3H1ccmc9UXCyRnA6M31KQvgkWeSIX8Ils=
X-Received: by 2002:a5d:8b4a:: with SMTP id c10mr4433954iot.143.1600797924427; 
 Tue, 22 Sep 2020 11:05:24 -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>
In-Reply-To: <CAD5xwhiwhCEZdpfXc9Z1kePaoSc7qAoin6Sz3zdRWWr67zNm3g@mail.gmail.com>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 22 Sep 2020 14:05:13 -0400
Message-ID: <CAFp6fsG8Wu12bnu3jN38Gz3xf5o9tg9Nf8eiMK_e4eW3+RyWZg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a48e0905afeacff4"
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: Tue, 22 Sep 2020 18:05:27 -0000

--000000000000a48e0905afeacff4
Content-Type: text/plain; charset="UTF-8"

Hi,

I think the topic of how to improve transaction relay policy and fee
bumping is an important one that needs to be worked on, so I'm glad
this is a topic of discussion.  However I am pretty skeptical of this
consensus change proposal:

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.

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

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.

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.

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.



On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Responses Inline:
>
> Would it make sense that, instead of sponsor vectors
>> pointing to txids, they point to input outpoints?  E.g.:
>>
>> 1. Alice and Bob open a channel with funding transaction 0123...cdef,
>>    output 0.
>>
>> 2. After a bunch of state updates, Alice unilaterally broadcasts a
>>    commitment transaction, which has a minimal fee.
>>
>> 3. Bob doesn't immediately care whether or not Alice tried to close the
>>    channel in the latest state---he just wants the commitment
>>    transaction confirmed so that he either gets his money directly or he
>>    can send any necessary penalty transactions.  So Bob broadcasts a
>>    sponsor transaction with a vector of 0123...cdef:0
>>
>> 4. Miners can include that sponsor transaction in any block that has a
>>    transaction with an input of 0123...cdef:0.  Otherwise the sponsor
>>    transaction is consensus invalid.
>>
>> (Note: alternatively, sponsor vectors could point to either txids OR
>> input outpoints.  This complicates the serialization of the vector but
>> seems otherwise fine to me.)
>>
>
> *This seems like a fine suggestion and I think addresses Antoine's issue.*
>
>
> *I think there are likely some cases where you do want TXID and not Output
> (e.g., if you *
>
> *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP)
> from an untrusted third party (no RBF), they can grift you into paying for
> an unrelated payment). This isn't a concern when the root utxo is multisig
> & you are a participant.*
>
> *The serialization to support both, while slightly more complicated, can
> be done in a manner that permits future extensibility as well if there are
> other modes people require.*
>
>
>
>>
>> > If we want to solve the hard cases of pinning, I still think mempool
>> > acceptance of a whole package only on the merits of feerate is the
>> easiest
>> > solution to reason on.
>>
>> I don't think package relay based only on feerate solves RBF transaction
>> pinning (and maybe also doesn't solve ancestor/dependent limit pinning).
>> Though, certainly, package relay has the major advantage over this
>> proposal (IMO) in that it doesn't require any consensus changes.
>> Package relay is also very nice for fixing other protocol rough edges
>> that are needed anyway.
>>
>> -Dave
>>
>
> *I think it's important to keep in mind this is not a rival to package
> relay; I think you also want package relay in addition to this, as they
> solve different but related problems.*
>
>
> *Where you might be able to simplify package relay with sponsors is by
> doing a sponsor-only package relay, which is always limited to 2
> transactions, 1 sponsor, 1 sponsoree. This would not have some of the
> challenges with arbitrary-package package-relay, and would (at least from a
> ux perspective) allow users to successfully get parents with insufficient
> fee into the mempool.*
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><pre style=3D"white-space:pre-wrap;color:=
rgb(0,0,0)"><span style=3D"font-family:arial,helvetica,sans-serif;white-spa=
ce:normal">Hi,</span></pre><pre style=3D"white-space:pre-wrap;color:rgb(0,0=
,0)"><font face=3D"arial, sans-serif">I think the topic of how to improve t=
ransaction relay policy and fee bumping is an important one that needs to b=
e worked on, so I&#39;m glad this is a topic of discussion.  However I am p=
retty skeptical of this consensus change proposal:</font></pre><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" class=3D"gmail_quote">The Sponsor Vector TXIDs  must also b=
e in the block the transaction is validated in, with no restriction on orde=
r or on specifying a TXID more than once.</blockquote><div><br></div><div>T=
hat means that if a transaction is confirmed in a block without 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 t=
ransaction is created, it should not become invalid later on unless the inp=
uts are double-spent.=C2=A0 This principle has some logical consequences th=
at we&#39;ve come to accept, such as transaction=C2=A0chains being=C2=A0val=
id across small reorgs in the absence of malicious (double-spend) behavior.=
</div><div><br></div><div>I think that this principle is a useful one and t=
hat there should be a high bar for doing away with it.=C2=A0 And it seems t=
o me that this proposal doesn&#39;t clear that bar -- the fee bumping impro=
vement that this proposal aims at is really coming from the policy change, =
rather than the consensus change. But if policy changes are the direction w=
e&#39;re going to solve these problems, we could instead just propose new p=
olicy rules for the existing types of transaction chaining that we have, ra=
ther than couple them to a new transaction type.</div><div><br></div><div>M=
y understanding of the main benefit of this approach is that this allows 3r=
d parties to participate in fee bumping.=C2=A0 But that behavior strikes me=
 as also problematic, because it introduces the possibility of 3rd party gr=
iefing, to the extent that sponsor transactions in any way limit chains of =
transactions that would be otherwise permitted.=C2=A0 If Alice sends Bob so=
me coins, and Alice and Bob are both honest and cooperating, Mallory should=
n&#39;t be able to interfere with their low-feerate transaction by (eg) pin=
ning it with a large transaction that &quot;sponsors&quot; it (ie a large t=
ransaction that is just above the feerate of the parent, which prevents add=
itional child transactions and makes it more expensive to RBF).</div><div><=
br></div><div>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 b=
eing a higher feerate than the tx it is sponsoring).=C2=A0 However, we coul=
d 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!=C2=A0 =
I think this would be useful work).=C2=A0 So I don&#39;t think that approac=
hes in that direction would be unique to this proposal.</div><div><br></div=
><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex" class=3D"gmail_quote">We allow one Sponso=
r to replace another subject to normal replacement policies, they are treat=
ed as conflicts.</blockquote><br></div><div>This policy rule of allowing sp=
onsor transactions to RBF each other also seems problematic; that means tha=
t if Alice is paying Bob in a transaction that is also sponsoring some othe=
r transaction (perhaps from Alice to someone else), then Mallory can cause =
the transaction going to Bob to become invalid by RBF bumping it and sponso=
ring the parent transaction herself?=C2=A0 Allowing 3rd parties to interfer=
e with transactions between others seems like a complex and undesirable des=
ign to introduce.</div><div><br></div><div>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.=C2=A0 And while what is unique about this prop=
osal is that it allows for 3rd parties to attach themselves to the transact=
ion graph of other parties, I think that is a complex interaction to introd=
uce and has negative side effects as well.<br></div><div><br></div><div><br=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Responses Inline=
:</div><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
Would it make sense that, instead of sponsor vectors<br>
pointing to txids, they point to input outpoints?=C2=A0 E.g.:<br>
<br>
1. Alice and Bob open a channel with funding transaction 0123...cdef,<br>
=C2=A0 =C2=A0output 0.<br>
<br>
2. After a bunch of state updates, Alice unilaterally broadcasts a<br>
=C2=A0 =C2=A0commitment transaction, which has a minimal fee.<br>
<br>
3. Bob doesn&#39;t immediately care whether or not Alice tried to close the=
<br>
=C2=A0 =C2=A0channel in the latest state---he just wants the commitment<br>
=C2=A0 =C2=A0transaction confirmed so that he either gets his money directl=
y or he<br>
=C2=A0 =C2=A0can send any necessary penalty transactions.=C2=A0 So Bob broa=
dcasts a<br>
=C2=A0 =C2=A0sponsor transaction with a vector of 0123...cdef:0<br>
<br>
4. Miners can include that sponsor transaction in any block that has a<br>
=C2=A0 =C2=A0transaction with an input of 0123...cdef:0.=C2=A0 Otherwise th=
e sponsor<br>
=C2=A0 =C2=A0transaction is consensus invalid.<br>
<br>
(Note: alternatively, sponsor vectors could point to either txids OR<br>
input outpoints.=C2=A0 This complicates the serialization of the vector but=
<br>
seems otherwise fine to me.)<br></blockquote><div><br></div><div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><b>This seems like a fine suggestion and I think addresses Antoine&#39;s =
issue.</b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><b><br></b></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>I think there a=
re likely some cases where you do want TXID and not Output (e.g., if you <b=
r></b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)"><b>are sponsoring a payment to your locktime&#39;d =
cold storage wallet (no CPFP) from an untrusted third party (no RBF), they =
can grift you into paying for an unrelated payment). This isn&#39;t a conce=
rn when the root utxo is multisig &amp; you are a participant.<br></b></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><b><br></b></div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)"><b>The serialization to support b=
oth, while slightly more complicated, can be done in a manner that permits =
future extensibility as well if there are other modes people require.</b><b=
r></div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
&gt; If we want to solve the hard cases of pinning, I still think mempool<b=
r>
&gt; acceptance of a whole package only on the merits of feerate is the eas=
iest<br>
&gt; solution to reason on.<br>
<br>
I don&#39;t think package relay based only on feerate solves RBF transactio=
n<br>
pinning (and maybe also doesn&#39;t solve ancestor/dependent limit pinning)=
.<br>
Though, certainly, package relay has the major advantage over this<br>
proposal (IMO) in that it doesn&#39;t require any consensus changes.<br>
Package relay is also very nice for fixing other protocol rough edges<br>
that are needed anyway.<br>
<br>
-Dave<br></blockquote><div><br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>I think it&#39;s import=
ant to keep in mind this is not a rival to package relay; I think you also =
want package relay in addition to this, as they solve different but related=
 problems.</b></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><b><br></b></div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b>Where you m=
ight be able to simplify package relay with sponsors is by doing a sponsor-=
only package relay, which is always limited to 2 transactions, 1 sponsor, 1=
 sponsoree. This would not have some of the challenges with arbitrary-packa=
ge package-relay, and would (at least from a ux perspective) allow users to=
 successfully get parents with insufficient  fee into the mempool.<br></b><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)"><br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div>

--000000000000a48e0905afeacff4--