path: root/30/74484292f4681d8303e7bc830e0e996a3f3e35

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 B1C19C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 16:27:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 9C8A186685
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 16:27:26 +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 tD5ffGg7yUBG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 16:27:24 +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 4C197866C4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 16:27:24 +0000 (UTC)
Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com
 [209.85.218.50]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08LGRLU0014808
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 21 Sep 2020 12:27:22 -0400
Received: by mail-ej1-f50.google.com with SMTP id z22so18575442ejl.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 09:27:22 -0700 (PDT)
X-Gm-Message-State: AOAM531ACZxIulTn0ucWoqSKu7bcQIHiDqR5Ctg2R/ZU9zF5H//FUK+f
 TMyPwjjuRpzAEEhgx/8dye8/O3O/4bcYm5zneik=
X-Google-Smtp-Source: ABdhPJx5lQGOLHlWEJJBiUNeKMHrx/trJmacGScrLuBO2ho8Wqu/5jv76A+z9WJVCfJ6wLUNez/ASIdp5axRdGf40oc=
X-Received: by 2002:a17:906:15c4:: with SMTP id l4mr283178ejd.78.1600705641379; 
 Mon, 21 Sep 2020 09:27:21 -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>
In-Reply-To: <20200921145221.76bg5rnw7ohkm3ck@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 21 Sep 2020 09:27:09 -0700
X-Gmail-Original-Message-ID: <CAD5xwhiwhCEZdpfXc9Z1kePaoSc7qAoin6Sz3zdRWWr67zNm3g@mail.gmail.com>
Message-ID: <CAD5xwhiwhCEZdpfXc9Z1kePaoSc7qAoin6Sz3zdRWWr67zNm3g@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="00000000000024fe7a05afd553d7"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Mon, 21 Sep 2020 16:27:26 -0000

--00000000000024fe7a05afd553d7
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">Responses Inline:</div=
><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t: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)=
" class=3D"gmail_default"><b>This seems like a fine suggestion and I think =
addresses Antoine&#39;s issue.</b></div><div style=3D"font-family:arial,hel=
vetica,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>I think there are =
likely some cases where you do want TXID and not Output (e.g., if you <br><=
/b></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><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). T=
his isn&#39;t a concern when the root utxo is multisig &amp; you are a part=
icipant.<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>The serialization to support both, w=
hile slightly more complicated, can be done in a manner that permits future=
 extensibility as well if there are other modes people require.</b><br></di=
v><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
<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)" class=3D"gmail_default"><b=
>I think it&#39;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 sol=
ve different but related problems.</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>Where you migh=
t be able to simplify package relay with sponsors is by doing a sponsor-onl=
y package relay, which is always limited to 2 transactions, 1 sponsor, 1 sp=
onsoree. This would not have some of the challenges with arbitrary-package =
package-relay, and would (at least from a ux perspective) allow users to su=
ccessfully get parents with insufficient  fee into the mempool.<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"><br></div><div style=3D"font-family:a=
rial,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-serif;fon=
t-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default"><br></div></div></div>

--00000000000024fe7a05afd553d7--