path: root/de/980f7f5250f369cd797c6f3594492723aa9839

Return-Path: <antoine.riard@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 79187C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 23:40:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 6107B858D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 23:40:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4KiHsy_FGlk3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 23:40:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com
 [209.85.221.53])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id F1222858C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 23:40:57 +0000 (UTC)
Received: by mail-wr1-f53.google.com with SMTP id w5so14970816wrp.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Sep 2020 16:40:57 -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
 :cc; bh=afrsqn6fogVB3J7GprFqqazinZO/gWwkwTJP5bwYniE=;
 b=TTUbjRjgZFv/WlhzPurbYaIGFOkDw80E+BP1Vyvsysy1YP0TqgZ3Bsr3De2XYYQroK
 NdhH9p31mnhy9CQuZZctGOG/HomSThvtoqgQMrsF68IFbWXCp5S/KbqKMOHriLefRhfA
 MtlMmm9t4YxigEayeVSGCr2BfiN1aisDkJq7ALtVGenTxLkT45PRw3cMS7rNSbmYJU8f
 dWQQQc2WtMbFzcplj05VxMs/j2DyW59q1kxwOo4p2LU0VqxxC3vjvheebpiIaQljuTL/
 taMDo4IMSyG9LkQLQU21n25lr2jfAJCs39ub6BrwBysOjWGlkLZqYfLnMwfWGn/bjakK
 bi2w==
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:cc;
 bh=afrsqn6fogVB3J7GprFqqazinZO/gWwkwTJP5bwYniE=;
 b=ENaNN1vDLSW7iV8NcR42fwiRqvx+qVXg2ZN7Swti6pXrn/0jOmcZhmCxOLPCt20S+O
 CJH3W2pF5ds7e9/9Qouc40GWxvpZv48XRDbmpaI/0swJAfTsZ9JZupw6ud4DWU/If15Y
 KZsItJQhokv7xtBtWr0HzR7/Y/BertvmeBCMT+okyk2J+cWghDFsmNjN2NcQTTcY/UQ8
 WgSrPolV6h9Afkc+Fj3/UvtCCON6p28Q0h96KsBEbSaTP97vGtoOiGxpwxK9BX2cHcPl
 YhPNTa+irox3h0gz81lKxgXbRAsZj7DtLxHxEgGYqBxDOTb1wLr1c6c2HPR505tRiAH8
 aZgA==
X-Gm-Message-State: AOAM532u07X8SNF+e6fFxmj/+NTzFtSM6TRQssAf3DvxYX+RV30E8CDR
 W9lx4ZTCq3qmJo/PVW23Rqun1IVykWnzebNrrO0=
X-Google-Smtp-Source: ABdhPJwxS5EvZ/XvRhsS4HyJNYrQcmCtvr3hfmgT7etHqncNvvgNPXVrm3lVt47v4SIZGd5aLiCCoz8QhWD0RG185sI=
X-Received: by 2002:adf:ffc3:: with SMTP id x3mr1586240wrs.290.1600731656272; 
 Mon, 21 Sep 2020 16:40:56 -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: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 21 Sep 2020 19:40:44 -0400
Message-ID: <CALZpt+FtQCdLPuJeiB5Ew99-Y7iO-JpV1EXGo_cnWo7HuDOw-Q@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000c0bd5d05afdb619d"
X-Mailman-Approved-At: Tue, 22 Sep 2020 02:45:53 +0000
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 23:40:59 -0000

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

I think this is a worthy idea as the funding outpoint of any off-chain
protocols is an invariant known by participants. Thus by sponsoring an
outpoint you're requiring from network mempools to increase the feerate of
the package locally known without assuming about the concrete state as any
of them confirming is moving protocol forward.

That said, a malicious counterparty can still broadcast a heavy-weighted
transaction such as an honest party, devoid of knowledge of this weight,
won't attach a sponsor with a fee high enough to timely confirm the
sponsoree. This counterparty capability is a function of package
malleability allowed by the off-chain protocol.

Thus an honest party has to overshoot your bump as a default setting. Now
this is a new concern as such a mechanism can be used as a fee-burning one
by your counterparty. I believe we want a fee-burning equilibrium for any
pinning solution, Mallet shouldn't force Alice to overpay in fee more than
Mallet is ready to feerate-bid in network mempools.

> I don't think package relay based only on feerate solves RBF transaction
> pinning (and maybe also doesn't solve ancestor/dependent limit pinning).

Yes I agree with this. There are some really nasty cases of pinning where
an adversary with knowledge of the tx-relay topology can block your
compelling feerate bids (sponsors/package relay/anchor whatever) from
propagating by leveraging conflicts and RBF logic.

Outbound tx-relay peers rotation which makes the tx-relay topology harder
to observe could help.

Antoine

Le lun. 21 sept. 2020 =C3=A0 12:27, Jeremy <jlrubin@mit.edu> a =C3=A9crit :

> 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 Outpu=
t
> (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 fo=
r
> an unrelated payment). This isn't a concern when the root utxo is multisi=
g
> & 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 ar=
e
> 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.*
>
>
>
>
>

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

<div dir=3D"ltr">I think this is a worthy idea as the funding outpoint of a=
ny off-chain protocols is an invariant known by participants. Thus by spons=
oring an outpoint you&#39;re requiring from network mempools to increase th=
e feerate of the package locally known without assuming about the concrete =
state as any of them confirming is moving protocol forward.<br><br>That sai=
d, a malicious counterparty can still broadcast a heavy-weighted transactio=
n such as an honest party, devoid of knowledge of this weight, won&#39;t at=
tach a sponsor with a fee high enough to timely confirm the sponsoree. This=
 counterparty capability is a function of package malleability allowed by t=
he off-chain protocol.<br><br>Thus an honest party has to overshoot your bu=
mp as a default setting. Now this is a new concern as such a mechanism can =
be used as a fee-burning one by your counterparty. I believe we want a fee-=
burning equilibrium for any pinning solution, Mallet shouldn&#39;t force Al=
ice to overpay in fee more than Mallet is ready to feerate-bid in network m=
empools.<br><br>&gt; I don&#39;t think package relay based only on feerate =
solves RBF transaction<br>&gt; pinning (and maybe also doesn&#39;t solve an=
cestor/dependent limit pinning).<br><br>Yes I agree with this. There are so=
me really nasty cases of pinning where an adversary with knowledge of the t=
x-relay topology can block your compelling feerate bids (sponsors/package r=
elay/anchor whatever) from propagating by leveraging conflicts and RBF logi=
c.<br><br>Outbound tx-relay peers rotation which makes the tx-relay topolog=
y harder to observe could help.<br><br>Antoine<br></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 21 sept. 202=
0 =C3=A0=C2=A012:27, Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@=
mit.edu</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Re=
sponses Inline:</div><br><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-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)=
" 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>
</blockquote></div>

--000000000000c0bd5d05afdb619d--