path: root/f8/1f90a1f622691b4f1c705aa1002bc41f47daba

Return-Path: <antoine.riard@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7F832C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Sep 2020 23:10:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 66C5186764
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Sep 2020 23:10:38 +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 B4xro9Lzd5wl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Sep 2020 23:10:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com
 [209.85.221.54])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 1AC7F8667D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Sep 2020 23:10:37 +0000 (UTC)
Received: by mail-wr1-f54.google.com with SMTP id c18so10837205wrm.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Sep 2020 16:10:36 -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=heQqqsVd1ZRUgukNEQ5b9GJUREmF2gW+u818X5UOrfk=;
 b=Y7kcaPmkpxs8/z3M9eWDlu+dUikPq4bchpJXya3/O+Hgt89HYNRFmpoj6o+UFay5qf
 QVbyh7bQ5OigwP5Iq0ionq3GVhE2ONGvtDQ0nUtGZUS3etzEf7pmT+c3CJgdMdHWpz3u
 +50H8T5J3FIVHEJjvAalwbNOdzHuh8WtaDzKk/K92U7bodLAzDSBzw4Ni0/KICVZjkNS
 Nv39bQNu6wdntktpZCMgGdUp5HylHf60EalWDcV48xqLK8+Xy/h17rc/fAUiFG4ASm66
 2L5ss+rTegLaz1Qp1i2aOfgMjGbhu0EhNs2sTZx80CjEIlfFTO3/nhukzLyXTjVi24ZH
 z8QQ==
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=heQqqsVd1ZRUgukNEQ5b9GJUREmF2gW+u818X5UOrfk=;
 b=FD7nKdyvqm7yUOnjIHHMb5s3nMxW1eZ3VTM8f/NWEnla2Bm9R0xU91cmEdh7jqF2tC
 ZfN9BMiWJByPSFSR+gKgOjWJTikmR4zbTtwRU60M7LS0i+mgTEeKumOj6jd5Pwgm/bTP
 ZmijRc4kwjPmt0ISJjaEyv4beiXUijERDeV+RpQSjCQ4aQLUEDFIIjB0vuIWXgmsT5hg
 SwDZ9WZKq19YDhloopCqyl2LKUh7AGlepXMoaMq8sfuFtgjptPSyDyO+4Lx0ytygbFM4
 XnmKY6ftkSIoYFTqvfHJtNwpqjAB4PEWkzAINnyn8Wey/XbYWVslljyjS90CC1T63VhR
 tpHg==
X-Gm-Message-State: AOAM532YojMVnF0ZP1T9WkmAuCBSWWZkPf2+uRLQvAQPVILsxGt1Icoe
 x9y4Cl6uicUfAdXt/IsrcRB+tb2f2ct0tgrlWEu0T36ZRS2HXQ==
X-Google-Smtp-Source: ABdhPJxEIEUybhrd0Ac9sQ+sP+r/m0rTiCklRWMpWjZXDyTMt5I4kOomaoRhqiKeFIpoNnff9rs9oisRSJd1vOODCoc=
X-Received: by 2002:a5d:608f:: with SMTP id w15mr26228698wrt.244.1600643435371; 
 Sun, 20 Sep 2020 16:10:35 -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>
In-Reply-To: <CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 20 Sep 2020 19:10:23 -0400
Message-ID: <CALZpt+HtuVC6YmZvABaZUWmN9c3pV1FnX1UUJgGbd_iLuuU8hg@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="00000000000060a12305afc6d748"
X-Mailman-Approved-At: Mon, 21 Sep 2020 00:57:29 +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: Sun, 20 Sep 2020 23:10:38 -0000

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

Right, I was off the shot. Thanks for the explanation.

As you mentioned, if the goal of the sponsor mechanism is to let any party
drive a state N's first tx to completion, you still have the issue of
concurrent states being pinned and thus non-observable for sponsoring by an
honest party.

E.g, Bob can broadcast a thousand of revoked LN states and pin them with
low-feerate sponsors such as these malicious packages absolute fee are
higher than the honest state N. Alice can't fee-sponsor
them as we can assume she hasn't a global view of network mempools. Due to
the proposed policy rule "The Sponsor Vector's entry must be present in the
mempool", Alice's sponsors won't propagate. Even amending this rule, we
can't assume Alice has a thousand of sponsoring utxos to avoid conflict
between her own broadcast.

Of course, offchain protocols designers can limit a participant's
capability to construct a pinning package by constraining its malleability
and thus to always have a compelling feerate. E.g in Lightning you can bind
the size of a commitment transaction by refusing relayed HTLCs and thus
have less HTLC outputs. This security increase comes at the price of less
protocol flexibility, e.g reducing payments throughput.

Further, a malicious counterparty can still take advantage of
mempool-congestion spikes. Even if the pinning package has a compelling
feerate, high enough to bounce off a honest broadcast, there is no
guarantee it stays such. Just after the pinning, congestion can increase
and bury it for long-enough until a timelock expires.

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.

Le sam. 19 sept. 2020 =C3=A0 15:46, Jeremy <jlrubin@mit.edu> a =C3=A9crit :

> Antoine,
>
> Yes I think you're a bit confused on where the actual sponsor vector is.
> If you have a transaction chain A->B->C and a sponsor S_A, S_A commits to
> txid A and A is unaware of S.
>
>
> W.r.t your other points, I fully agree that the 1-to-N sponsored case is
> very compelling. The consensus rules are clear that sponsor commitments a=
re
> non-rival, so there's no issue with allowing as many sponsors as possible
> and including them in aggregate. E.g., if S_A and S'_A both sponsor A wit=
h
> feerate(S*) > feerate(A), there's no reason not to include all of them in=
 a
> block. The only issue is denial of service in the mempool. In the future,
> it would definitely be desirable to figure out rules that allow mempools =
to
> track both multiple sponsors and multiple sponsor targets. But in the
> interest of KISS, the current policy rules are designed to be minimally
> invasive and maximally functional.
>
> In terms of location for the sponsor vector, I'm relatively indifferent.
> The annex is a possible location, but it's a bit odd as we really only ne=
ed
> to allow one such vector per tx, not one per input, and one per input wou=
ld
> enable some new use cases (maybe good, maybe bad). Further, being in the
> witness space would mean that if two parties create a 2 input transaction
> with a desired sponsor vector they would both need to specify it as you
> can't sign another input's witness data. I wholeheartedly agree with the
> sentiment though; there could be a more efficient place to put this data,
> but nothing jumps out to me as both efficient and simple in implementatio=
n
> (a new tx-level field sounds like a lot of complexity).
>
>
> > n >=3D1 ? I think you can have at least one vector and this is matching
> the code
>
> yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointin=
g
> it out first), but is correct in the code. Thank you for your careful
> reading.
>
>

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

<div dir=3D"ltr">Right, I was off the shot. Thanks for the explanation.<br>=
<br>As you mentioned, if the goal of the sponsor mechanism is to let any pa=
rty drive a state N&#39;s first tx to completion, you still have the issue =
of concurrent states being pinned and thus non-observable for sponsoring by=
 an honest party.<br><br>E.g, Bob can broadcast a thousand of revoked LN st=
ates and pin them with low-feerate sponsors such as these malicious package=
s absolute fee are higher than the honest state N. Alice can&#39;t fee-spon=
sor<br>them as we can assume she hasn&#39;t a global view of network mempoo=
ls. Due to the proposed policy rule &quot;The Sponsor Vector&#39;s entry mu=
st be present in the mempool&quot;, Alice&#39;s sponsors won&#39;t propagat=
e. Even amending this rule, we can&#39;t assume Alice has a thousand of spo=
nsoring utxos to avoid conflict between her own broadcast.<br><br>Of course=
, offchain protocols designers can limit a participant&#39;s capability to =
construct a pinning package by constraining its malleability and thus to al=
ways have a compelling feerate. E.g in Lightning you can bind the size of a=
 commitment transaction by refusing relayed HTLCs and thus have less HTLC o=
utputs. This security increase comes at the price of less protocol flexibil=
ity, e.g reducing payments throughput.<br><br>Further, a malicious counterp=
arty can still take advantage of mempool-congestion spikes. Even if the pin=
ning package has a compelling feerate, high enough to bounce off a honest b=
roadcast, there is no guarantee it stays such. Just after the pinning, cong=
estion can increase and bury it for long-enough until a timelock expires.<b=
r><br>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.<br></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">Le=C2=A0sam. 19 sept. 2020 =C3=A0=C2=A015:46, Jer=
emy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>&gt; a =C3=A9=
crit=C2=A0:<br></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"><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">Antoine,</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 style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Yes=
 I think you&#39;re a bit confused on where the actual sponsor vector is. I=
f you have a transaction chain A-&gt;B-&gt;C and a sponsor S_A, S_A commits=
 to txid A and A is unaware of S.</div><div style=3D"font-family:arial,helv=
etica,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;font-size:sm=
all;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">W.r.t your other points, I fully agree that the 1-to-N s=
ponsored case is very compelling. The consensus rules are clear that sponso=
r commitments are non-rival, so there&#39;s no issue with allowing as many =
sponsors as possible and including them in aggregate. E.g., if S_A and S&#3=
9;_A both sponsor A with feerate(S*) &gt; feerate(A), there&#39;s no reason=
 not to include all of them in a block. The only issue is denial of service=
 in the mempool. In the future, it would definitely be desirable to figure =
out rules that allow mempools to track both multiple sponsors and multiple =
sponsor targets. But in the interest of KISS, the current policy rules are =
designed to be minimally invasive and maximally functional.</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 style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">In =
terms of location for the sponsor vector, I&#39;m relatively indifferent. T=
he annex is a possible location, but it&#39;s a bit odd as we really only n=
eed to allow one such vector per tx, not one per input, and one per input w=
ould enable some new use cases (maybe good, maybe bad). Further, being in t=
he witness space would mean that if two parties create a 2 input transactio=
n with a desired sponsor vector they would both need to specify it as you c=
an&#39;t sign another input&#39;s witness data. I wholeheartedly agree with=
 the sentiment though; there could be a more efficient place to put this da=
ta, but nothing jumps out to me as both efficient and simple in implementat=
ion (a new tx-level field sounds like a lot of complexity).<br></div><span>=
</span><br><span></span><div style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><span><br></spa=
n>&gt; n &gt;=3D1 ? I think you can have at least one vector and this is ma=
tching the code</div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default">yes, this has been fixed in the=C2=A0gist (cred=
 to Dmitry Petukhov for pointing it out first), but is correct in the code.=
 Thank you for your careful reading.<br></div><br></div>
</blockquote></div>

--00000000000060a12305afc6d748--