path: root/4d/fb2e7bd2222737cb0657b5f29ddc83a7b7f4c4

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 15405C000C;
 Mon, 21 Jun 2021 08:13:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 03BEF6062F;
 Mon, 21 Jun 2021 08:13:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id qxR3qRPd4Nrh; Mon, 21 Jun 2021 08:13:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [IPv6:2a00:1450:4864:20::432])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B1E9D6061C;
 Mon, 21 Jun 2021 08:13:46 +0000 (UTC)
Received: by mail-wr1-x432.google.com with SMTP id j1so1327166wrn.9;
 Mon, 21 Jun 2021 01:13:46 -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=tj6/B/RtLT6sK2FVbfye2l6Ka7s+eMm5824P9DYOBKA=;
 b=iXeEk5aHFFEf1JSnFu2eEiztx5Hpm1becUJZ+weKJ3N7VSNQzPOcZK/4NGVkdGePkH
 Ormd82rkiIDgEesF8BgL4Ga+kuYXppab/W3AOpdaVqGF1moHczrHKnm1tcgI3Elk86HN
 /9gLd0Opem6HbGbUoCGqGpvErAM3yiNoprOKKqXU0fca6NQAk8aS5sIB5qWRq1pFhke8
 MRrCIsRiDEe+omnWvkR8x5IuZP6YbdCxflPPV/hWDCqUwoXwuNf+nj8C+A4qSMYQKksF
 9lsrGsy8MrknwP+XbqioDvu1jlA4IuGicJ3FvQ1EjcKLD8UXWV8qnB9I4kE+PgdjmSIW
 Z8mw==
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=tj6/B/RtLT6sK2FVbfye2l6Ka7s+eMm5824P9DYOBKA=;
 b=K832NDnIbuQX6JLPpMdUdO3U6Q2fHQXp++WzBN7i5VDKuF5rAB0NY4Rsyn6RKZlxX6
 /eq3sAYSDBsWFzbFhhrXBQfdmump5E6tH+UAliGDOARjvCkphXxJ9c9djElHxDmL4X5z
 RNIi/p1A/RBw0Jd0j82gaSfUDIAeVAVIc6wDmROmhVwy9+Q6Z+l56hUtViXgkvY/O54E
 7x+SxY2/JM22y/XqK1/yNNqKXTm46lN6aiJEaZkHlVVautZkfb7ULajOHLx2rgsMiNmU
 PaGe2Fk0uGCTxOb7OTtEiJL6EECYfe60iFW4ztlzaYZzAX/Izh/PewNsehJ+cdkiAjh/
 6jRA==
X-Gm-Message-State: AOAM530AWCTFm6IN23gWXYvgDethYyES4/rezVaMy+nJqrygEAVxa9z3
 8ojdX8lUZjEHFcp5Za6Ro7fosGnIHjTT1ESSXc4=
X-Google-Smtp-Source: ABdhPJy6vtwQRO9huOiubsxQVvy8ij5l+4UUj0wDjh+QqRv6rLZz0XVwoAmdD9NpbGOB2kuviy3HBCGWGLPnV+fNtLY=
X-Received: by 2002:a5d:4c52:: with SMTP id n18mr5823038wrt.14.1624263224757; 
 Mon, 21 Jun 2021 01:13:44 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+FF_TT_K3wjWhhaDE6Ue=RAsM2JWO7-mYjm5LtHqJvNmg@mail.gmail.com>
 <20210619133653.m2272jgna5geuuki@ganymede>
In-Reply-To: <20210619133653.m2272jgna5geuuki@ganymede>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 21 Jun 2021 04:13:32 -0400
Message-ID: <CALZpt+E0AbLBj+eQTffuW+W02OeguU+59Ak09UQ-y=vJXNJ0Ew@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000888fac05c54240da"
X-Mailman-Approved-At: Mon, 21 Jun 2021 08:30:35 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and
	Packing Packages
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 Jun 2021 08:13:49 -0000

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

Hi Dave,

> That might work for current LN-penalty, but I'm not sure it works for
eltoo.

Well, we have not settled yet on the eltoo design but if we take the later
proposal in date [0], signing the update transaction with
SIGHGASH_ANYPREVOUT lets you attach non-interactively a single-party
controlled input at broadcast-time. Providing the input amount is high
enough to bump the transaction feerate over network mempools, it should
allow the tx to propagate across network mempools and that way solve the
pre-signed feerate problem as defined in the post ?

>  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> to refer to any prevout, that implies anyone else can do the same.
> Miners who were aware of two or more states from an eltoo channel would
> be incentivized to rewrite to the oldest state, giving them fee revenue
> now and ensuring fee revenue in the future when a later state update is
> broadcast.

Yep, you can add a per-participant key to lockdown the transaction and
avoid any in-flight malleability ? I think this is discussed in the "A
Stroll through Fee-Bumping Techniques" thread.

> If the attacker using pinning is able to reuse their attack at no cost,
> they can re-pin the channel again and force the honest user to pay
> another anyprevout bounty to miners.

This is also true with package-relay where your counterparty, with a better
knowledge of network mempools, can always re-broadcast a CPFP-bumped
malicious package ? Under this assumption, I think you should always be
ready to bump our honest package.

Further, for the clarity of the discussion, can you point to which pinning
scenario you're thinking of or if it's new under SIGHASH_ANYPREVOUT,
describe it ?

> Repeat this a bunch of times and the honest user has now spent more on
fees than their balance from the
closed channel.

And sadly, as this concern also exists in case of a miner-harvesting attack
against LN nodes, a concern that Gleb and I expressed more than a year ago
in a public post [1], a good L2 client should always upper bound its
fee-bumping reserve. I've a short though-unclear note on this notion of
fee-bumping upper to warn other L2 engineers  in "On Mempool Funny Games
against Multi-Party Funded Transactions"

Please read so:

"A L2 client, with only a view of its mempool at best, won't understand why
 the transaction doesn't confirm and if it's responsible for the
 fee-bumping, it might do multiple rounds of feerate increase through CPFP,
 in vain. As the fee-bumping algorithm is assumed to be known if the victim
 client is open source code, the attacker can predict when the fee-bumping
 logic reaches its upper bound."

Though thanks for the recall! I should log dynamic-balances in RL's
`ChannelMonitorUpdate` for our ongoing implementation of anchor, updating
my TODO :p

> Even if my analysis above is wrong, I would encourage you or Matt or
someone to write up this anyprevout idea in more detail and distribute
it before you promote it much more.

That's a really fair point, as a lot of the reasoning was based on private
discussion with Matt. Though as SIGHASH_ANYPREVOUT isn't advocated for
community consensus and those things take time, should just take a few
hours of my time.

> Even if every protocol based on presigned transactions can magically
allow dynamically adding inputs and modifying outputs for fees, and we
also have a magic perfect transaction replacement protocol,

"=E2=80=9CAny sufficiently advanced technology is indistinguishable from ma=
gic.=E2=80=9D
Arthur C. Clarke

Wit apart, that might be the outcome with careful bitcoin protocol
development, where technical issues are laid out in a best effort (of
mine!) and spread to the Bitcoin community on the most public bitcoin
communication channel ?

And humbly, on all those L2 issues I did change my opinion, as I've written
so much explicitly in this thread post by pointing to an older post of mine
("Advances in Bitcoin Contracting : Uniform Policy and Package Relay").
This reversal, partially motivated by a lot of discussion with folks,
including yourself, initiated since at least mid last year.

> package relay is still fundamentally useful for CPFP fee bumping very low
> feerate transactions received from an external party.  E.g. Alice pays
> Bob, mempool min feerates increase and Alice's transaction is dropped,
> Bob still wants the money, so he submits a package with Alice's
> transaction plus his own high feerate spend of it.

I think this point would be a reverse of our p2p design where we are now
making the sender responsible for the receiver quality of its mempool
feerate ? This question has never been clear up during the years-long
discussion of package-relay design [1].

Though referring to the thread post and last week's transaction-relay
workshop, I did point out that package-relay might serve in the long-term
as a mempool-sync mechanism to prevent potential malicious mempool
partitions [2].

> Package relay is a clear improvement now, and one I expect to be
permanent for as long as we're using anything like the current protocol

Again, reading my post, I did point out that we might keep the "lower half"
of package-relay and deprecate only the higher part of it as we have more
feerate-efficient fee-bumping primitive available. If  it sounds too much
of a release engineering effort to synchronize on the scale of an
ecosystem, think about the ongoing deprecation of Tor V2.

Further, you did express a far less assertive opinion during last Tuesday
transaction-relay workshops, to which a lot of folks attended, where you
pointed it might not be a good idea for L2s to make more assumptions on
non-normative:

"harding> I do think we should be using miners profit incentive more for
stuff rather than trying to normalize mempool policy (which not entirely
possible), e.g. things like
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664=
.html
"

Arguing for package-relay "permanence" moves in the contrary decision IMHO =
?

> I don't think it's appropriate to be creating timelines like this that
depend on the work of a large number of contributors who I don't believe

Thanks Dave, this is your opinion and I respect this. I'll let any
participant of this mailing list make an opinion on its own, following
their private judgement. It might be based from a lot of different factors,
e.g "trusting the experts" or gathering diverse in-field authorities'
opinions or reasoning from scratch based on raw, public facts.

Though might I ask you on which information sources are you finding your
belief ? I'm curious if you're aware of any contributors who feel entitled
to be consulted in a decentralized development process...

For the records, I did consult no one. As even in the technical circle that
would have been a lot of open source projects teams to reach out : LND,
c-ligtning, Eclair, coin-teleport, revault, sapio, btcsuite, bcoin,
libbitcoin, wasabi's coinjoin, samourai wallet's coinjoin, ...

I was lazy, I just shot a mail :p

W.r.t to Greg's 4-year old's piece, I'll let him express his opinion on how
the expressed framework applies to my post, the Bitcoin dev stage has grown
a lot since then. What was making sense when you had like ~20 Bitcoin dev
with 90% of the technical knowledge doesn't scale when you have multiple
second-layers specifications of which you have multiple implementations
teams, some of them  decentralized and spread through different
countries/timezones, IMHO.

Though, Dave if you strongly hold your opinion on my behavior, I would
invite you to do this intellectual work by yourself.

Browsing quickly through Greg's piece, a lot of the reasoning is based on
FOSS experience from Linux/Juniper, which to the best of my knowledge are
centralized software projects ?

Note, also Paul Storzc's post has the simple phrase :

"I emphasized concrete numbers, and concrete dates"

I believe my post doesn't have such numbers and concrete dates ?

Presence of Core version numbers are motivated as clear signalling for L2
developpers to update their backend in case of undocumented, subtle policy
changes slipping in the codebase. Let's minimize CVE-2020-26895
style-of-bugs across the ecosystem :/

Finally, the presence of timelines in this post is also a gentle call for
the Bitcoin ecosystem to act on those safety holes, of which the
seriousness has been underscored by a lot of contributors in the past,
especially for the pre-signed feerate problem and even before I was in the
Bitcoin stage.

So better to patch them before they do manifest in the wild, and folks
start to bleed coins.  What you learn from practicing security research,
the lack of action can be harmful :/

> Stuff will get done when it gets done.

Don't forget bugs might slip in but that's fine if you have the skilled
folks around to catch them :)

And yes I really care about Lightning, and all those cute new L2 protocols
fostering in the community :)

Finally, you know Dave, I'm just spreading ideas.

If those ideas are sound and folks love them, awesome! They're free to use,
study, share and modify them to build better systems.

If I'm wrong, like I've been in the past, like I might be today and like
I'll be in the future, I hope they will be patient to teach me back and
we'll learn.

Hacker ethos :) ?

Cheers,
Antoine

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/0024=
48.html

[1] https://github.com/bitcoin/bitcoin/issues/14895

[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002=
569.html

Le sam. 19 juin 2021 =C3=A0 09:38, David A. Harding <dave@dtrt.org> a =C3=
=A9crit :

> On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> > 2) Solving the Pre-Signed Feerate problem : Package-Relay or
> > SIGHASH_ANYPREVOUT
> >
> > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be abl=
e
> to
> > solve the pre-signed feerate issue [3]
> >
> > [...]
> >
> > [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
> > solves pinnings beyond those LN meetings logs:
> > https://gnusha.org/lightning-dev/2020-06-08.log
>
> For anyone else looking, the most relevant line seems to be:
>
>   13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here
>   - assuming a lot of complicated logic in core to do so, you could
>   imagine blind-cpfp-bumping *any* commitment tx without knowing its
>   there or which one it is all with one tx.......in theory)
>
> That might work for current LN-penalty, but I'm not sure it works for
> eltoo.  If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> to refer to any prevout, that implies anyone else can do the same.
> Miners who were aware of two or more states from an eltoo channel would
> be incentivized to rewrite to the oldest state, giving them fee revenue
> now and ensuring fee revenue in the future when a later state update is
> broadcast.
>
> If the attacker using pinning is able to reuse their attack at no cost,
> they can re-pin the channel again and force the honest user to pay
> another anyprevout bounty to miners.  Repeat this a bunch of times and
> the honest user has now spent more on fees than their balance from the
> closed channel.
>
> Even if my analysis above is wrong, I would encourage you or Matt or
> someone to write up this anyprevout idea in more detail and distribute
> it before you promote it much more.
>
> > package-relay sounds a reasonable, temporary "patch".
>
> Even if every protocol based on presigned transactions can magically
> allow dynamically adding inputs and modifying outputs for fees, and we
> also have a magic perfect transaction replacement protocol, package
> relay is still fundamentally useful for CPFP fee bumping very low
> feerate transactions received from an external party.  E.g. Alice pays
> Bob, mempool min feerates increase and Alice's transaction is dropped,
> Bob still wants the money, so he submits a package with Alice's
> transaction plus his own high feerate spend of it.
>
> Package relay is a clear improvement now, and one I expect to be
> permanent for as long as we're using anything like the current protocol.
>
> > # Deployment timeline
> >
> > So what I believe as a rough deployment timeline.
>
> I don't think it's appropriate to be creating timelines like this that
> depend on the work of a large number of contributors who I don't believe
> you've consulted.  For details on this point of view, please see
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.=
html
>
> Stuff will get done when it gets done.
>
> -Dave
>

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

<div dir=3D"ltr"><div>Hi Dave,<br></div><div><br>&gt; That might work for c=
urrent LN-penalty, but I&#39;m not sure it works for<br>eltoo.<br><br>Well,=
 we have not settled yet on the eltoo design but if we take the later propo=
sal in date [0], signing the update transaction with SIGHGASH_ANYPREVOUT le=
ts you attach non-interactively a single-party controlled input at broadcas=
t-time. Providing the input amount is high enough to bump the transaction f=
eerate over network mempools, it should allow the tx to propagate across ne=
twork mempools and that way solve the pre-signed feerate problem as defined=
 in the post ?<br><br>&gt; =C2=A0If Bitcoin Core can rewrite the blind CPFP=
 fee bump transaction<br>&gt; to refer to any prevout, that implies anyone =
else can do the same.<br>&gt; Miners who were aware of two or more states f=
rom an eltoo channel would<br>&gt; be incentivized to rewrite to the oldest=
 state, giving them fee revenue<br>&gt; now and ensuring fee revenue in the=
 future when a later state update is<br>&gt; broadcast.<br><br>Yep, you can=
 add a per-participant key to lockdown the transaction and avoid any in-fli=
ght malleability ? I think this is discussed in the &quot;A Stroll through =
Fee-Bumping Techniques&quot; thread.<br><br>&gt; If the attacker using pinn=
ing is able to reuse their attack at no cost,<br>&gt; they can re-pin the c=
hannel again and force the honest user to pay<br>&gt; another anyprevout bo=
unty to miners.<br><br>This is also true with package-relay where your coun=
terparty, with a better knowledge of network mempools, can always re-broadc=
ast a CPFP-bumped malicious package ? Under this assumption, I think you sh=
ould always be ready to bump our honest package.<br><br>Further, for the cl=
arity of the discussion, can you point to which pinning scenario you&#39;re=
 thinking of or if it&#39;s new under SIGHASH_ANYPREVOUT, describe it ?<br>=
<br>&gt; Repeat this a bunch of times and the honest user has now spent mor=
e on fees than their balance from the<br>closed channel.<br><br>And sadly, =
as this concern also exists in case of a miner-harvesting attack against LN=
 nodes, a concern that Gleb and I expressed more than a year ago in a publi=
c post [1], a good L2 client should always upper bound its fee-bumping rese=
rve. I&#39;ve a short though-unclear note on this notion of fee-bumping upp=
er to warn other L2 engineers =C2=A0in &quot;On Mempool Funny Games against=
 Multi-Party Funded Transactions&quot;<br><br>Please read so:<br><br>&quot;=
A L2 client, with only a view of its mempool at best, won&#39;t understand =
why<br>=C2=A0the transaction doesn&#39;t confirm and if it&#39;s responsibl=
e for the<br>=C2=A0fee-bumping, it might do multiple rounds of feerate incr=
ease through CPFP,<br>=C2=A0in vain. As the fee-bumping algorithm is assume=
d to be known if the victim<br>=C2=A0client is open source code, the attack=
er can predict when the fee-bumping<br>=C2=A0logic reaches its upper bound.=
&quot;<br><br>Though thanks for the recall! I should log dynamic-balances i=
n RL&#39;s `ChannelMonitorUpdate` for our ongoing implementation of anchor,=
 updating my TODO :p<br><br>&gt; Even if my analysis above is wrong, I woul=
d encourage you or Matt or<br>someone to write up this anyprevout idea in m=
ore detail and distribute<br>it before you promote it much more.<br><br>Tha=
t&#39;s a really fair point, as a lot of the reasoning was based on private=
 discussion with Matt. Though as SIGHASH_ANYPREVOUT isn&#39;t advocated for=
 community consensus and those things take time, should just take a few hou=
rs of my time.<br><br>&gt; Even if every protocol based on presigned transa=
ctions can magically<br>allow dynamically adding inputs and modifying outpu=
ts for fees, and we<br>also have a magic perfect transaction replacement pr=
otocol,<br><br>&quot;=E2=80=9CAny sufficiently advanced technology is indis=
tinguishable from magic.=E2=80=9D Arthur C. Clarke<br><br>Wit apart, that m=
ight be the outcome with careful bitcoin protocol development, where techni=
cal issues are laid out in a best effort (of mine!) and spread to the Bitco=
in community on the most public bitcoin communication channel ?<br><br>And =
humbly, on all those L2 issues I did change my opinion, as I&#39;ve written=
 so much explicitly in this thread post by pointing to an older post of min=
e (&quot;Advances in Bitcoin Contracting : Uniform Policy and Package Relay=
&quot;). This reversal, partially motivated by a lot of discussion with fol=
ks, including yourself, initiated since at least mid last year.<br><br>&gt;=
 package relay is still fundamentally useful for CPFP fee bumping very low<=
br>&gt; feerate transactions received from an external party.=C2=A0 E.g. Al=
ice pays<br>&gt; Bob, mempool min feerates increase and Alice&#39;s transac=
tion is dropped,<br>&gt; Bob still wants the money, so he submits a package=
 with Alice&#39;s<br>&gt; transaction plus his own high feerate spend of it=
.<br><br>I think this point would be a reverse of our p2p design where we a=
re now making the sender responsible for the receiver quality of its mempoo=
l feerate ? This question has never been clear up during the years-long dis=
cussion of package-relay design [1].<br><br>Though referring to the thread =
post and last week&#39;s transaction-relay workshop, I did point out that p=
ackage-relay might serve in the long-term as a mempool-sync mechanism to pr=
event potential malicious mempool partitions [2].<br><br>&gt; Package relay=
 is a clear improvement now, and one I expect to be<br>permanent for as lon=
g as we&#39;re using anything like the current protocol<br><br>Again, readi=
ng my post, I did point out that we might keep the &quot;lower half&quot; o=
f package-relay and deprecate only the higher part of it as we have more fe=
erate-efficient fee-bumping primitive available. If=C2=A0 it sounds too muc=
h of a release engineering effort to synchronize on the scale of an ecosyst=
em, think about the ongoing deprecation of Tor V2.<br><br>Further, you did =
express a far less assertive opinion during last Tuesday transaction-relay =
workshops, to which a lot of folks attended, where you pointed it might not=
 be a good idea for L2s to make more assumptions on non-normative:<br><br>&=
quot;harding&gt; I do think we should be using miners profit incentive more=
 for stuff rather than trying to normalize mempool policy (which not entire=
ly possible), e.g. things like <a href=3D"https://lists.linuxfoundation.org=
/pipermail/lightning-dev/2020-April/002664.html">https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2020-April/002664.html</a>&quot;<br><br>Arg=
uing for package-relay &quot;permanence&quot; moves in the contrary decisio=
n IMHO ?<br><br>&gt; I don&#39;t think it&#39;s appropriate to be creating =
timelines like this that<br>depend on the work of a large number of contrib=
utors who I don&#39;t believe<br><br>Thanks Dave, this is your opinion and =
I respect this. I&#39;ll let any participant of this mailing list make an o=
pinion on its own, following their private judgement. It might be based fro=
m a lot of different factors, e.g &quot;trusting the experts&quot; or gathe=
ring diverse in-field authorities&#39; opinions or reasoning from scratch b=
ased on raw, public facts.<br><br>Though might I ask you on which informati=
on sources are you finding your belief ? I&#39;m curious if you&#39;re awar=
e of any contributors who feel entitled to be consulted in a decentralized =
development process...<br><br>For the records, I did consult no one. As eve=
n in the technical circle that would have been a lot of open source project=
s teams to reach out : LND, c-ligtning, Eclair, coin-teleport, revault, sap=
io, btcsuite, bcoin, libbitcoin, wasabi&#39;s coinjoin, samourai wallet&#39=
;s coinjoin, ...<br><br>I was lazy, I just shot a mail :p<br><br>W.r.t to G=
reg&#39;s 4-year old&#39;s piece, I&#39;ll let him express his opinion on h=
ow the expressed framework applies to my post, the Bitcoin dev stage has gr=
own a lot since then. What was making sense when you had like ~20 Bitcoin d=
ev with 90% of the technical knowledge doesn&#39;t scale when you have mult=
iple second-layers specifications of which you have multiple implementation=
s teams, some of them=C2=A0 decentralized and spread through different coun=
tries/timezones, IMHO.<br><br>Though, Dave if you strongly hold your opinio=
n on my behavior, I would invite you to do this intellectual work by yourse=
lf.<br><br>Browsing quickly through Greg&#39;s piece, a lot of the reasonin=
g is based on FOSS experience from Linux/Juniper, which to the best of my k=
nowledge are centralized software projects ?<br><br>Note, also Paul Storzc&=
#39;s post has the simple phrase :<br><br>&quot;I emphasized concrete numbe=
rs, and concrete dates&quot;<br><br>I believe my post doesn&#39;t have such=
 numbers and concrete dates ?<br><br>Presence of Core version numbers are m=
otivated as clear signalling for L2 developpers to update their backend in =
case of undocumented, subtle policy changes slipping in the codebase. Let&#=
39;s minimize CVE-2020-26895 style-of-bugs across the ecosystem :/<br><br>F=
inally, the presence of timelines in this post is also a gentle call for th=
e Bitcoin ecosystem to act on those safety holes, of which the seriousness =
has been underscored by a lot of contributors in the past, especially for t=
he pre-signed feerate problem and even before I was in the Bitcoin stage.<b=
r><br>So better to patch them before they do manifest in the wild, and folk=
s start to bleed coins.=C2=A0 What you learn from practicing security resea=
rch, the lack of action can be harmful :/<br><br>&gt; Stuff will get done w=
hen it gets done.<br><br>Don&#39;t forget bugs might slip in but that&#39;s=
 fine if you have the skilled folks around to catch them :)<br><br>And yes =
I really care about Lightning, and all those cute new L2 protocols fosterin=
g in the community :)<br><br>Finally, you know Dave, I&#39;m just spreading=
 ideas.<br><br>If those ideas are sound and folks love them, awesome! They&=
#39;re free to use, study, share and modify them to build better systems.<b=
r><br>If I&#39;m wrong, like I&#39;ve been in the past, like I might be tod=
ay and like I&#39;ll be in the future, I hope they will be patient to teach=
 me back and we&#39;ll learn. <br><br>Hacker ethos :) ?<br><br>Cheers,<br>A=
ntoine<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/li=
ghtning-dev/2020-January/002448.html">https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2020-January/002448.html</a><br><br>[1] <a href=3D"htt=
ps://github.com/bitcoin/bitcoin/issues/14895">https://github.com/bitcoin/bi=
tcoin/issues/14895</a><br><br>[2] <a href=3D"https://lists.linuxfoundation.=
org/pipermail/lightning-dev/2020-February/002569.html">https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2020-February/002569.html</a><br></di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">Le=C2=A0sam. 19 juin 2021 =C3=A0=C2=A009:38, David A. Harding &lt;<a href=
=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 18, 2021 at=
 06:11:38PM -0400, Antoine Riard wrote:<br>
&gt; 2) Solving the Pre-Signed Feerate problem : Package-Relay or<br>
&gt; SIGHASH_ANYPREVOUT<br>
&gt; <br>
&gt; For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be ab=
le to<br>
&gt; solve the pre-signed feerate issue [3]<br>
&gt;<br>
&gt; [...]<br>
&gt;<br>
&gt; [3] I don&#39;t think there is a clear discussion on how SIGHASH_ANYPR=
EVOUT<br>
&gt; solves pinnings beyond those LN meetings logs:<br>
&gt; <a href=3D"https://gnusha.org/lightning-dev/2020-06-08.log" rel=3D"nor=
eferrer" target=3D"_blank">https://gnusha.org/lightning-dev/2020-06-08.log<=
/a><br>
<br>
For anyone else looking, the most relevant line seems to be:<br>
<br>
=C2=A0 13:50 &lt; BlueMatt&gt; (sidenote: sighash_no_input is *really* eleg=
ant here<br>
=C2=A0 - assuming a lot of complicated logic in core to do so, you could<br=
>
=C2=A0 imagine blind-cpfp-bumping *any* commitment tx without knowing its<b=
r>
=C2=A0 there or which one it is all with one tx.......in theory)<br>
<br>
That might work for current LN-penalty, but I&#39;m not sure it works for<b=
r>
eltoo.=C2=A0 If Bitcoin Core can rewrite the blind CPFP fee bump transactio=
n<br>
to refer to any prevout, that implies anyone else can do the same.<br>
Miners who were aware of two or more states from an eltoo channel would<br>
be incentivized to rewrite to the oldest state, giving them fee revenue<br>
now and ensuring fee revenue in the future when a later state update is<br>
broadcast.<br>
<br>
If the attacker using pinning is able to reuse their attack at no cost,<br>
they can re-pin the channel again and force the honest user to pay<br>
another anyprevout bounty to miners.=C2=A0 Repeat this a bunch of times and=
<br>
the honest user has now spent more on fees than their balance from the<br>
closed channel.<br>
<br>
Even if my analysis above is wrong, I would encourage you or Matt or<br>
someone to write up this anyprevout idea in more detail and distribute<br>
it before you promote it much more.<br>
<br>
&gt; package-relay sounds a reasonable, temporary &quot;patch&quot;.<br>
<br>
Even if every protocol based on presigned transactions can magically<br>
allow dynamically adding inputs and modifying outputs for fees, and we<br>
also have a magic perfect transaction replacement protocol, package<br>
relay is still fundamentally useful for CPFP fee bumping very low<br>
feerate transactions received from an external party.=C2=A0 E.g. Alice pays=
<br>
Bob, mempool min feerates increase and Alice&#39;s transaction is dropped,<=
br>
Bob still wants the money, so he submits a package with Alice&#39;s<br>
transaction plus his own high feerate spend of it.<br>
<br>
Package relay is a clear improvement now, and one I expect to be<br>
permanent for as long as we&#39;re using anything like the current protocol=
.<br>
<br>
&gt; # Deployment timeline<br>
&gt; <br>
&gt; So what I believe as a rough deployment timeline.<br>
<br>
I don&#39;t think it&#39;s appropriate to be creating timelines like this t=
hat<br>
depend on the work of a large number of contributors who I don&#39;t believ=
e<br>
you&#39;ve consulted.=C2=A0 For details on this point of view, please see<b=
r>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Jul=
y/014726.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2017-July/014726.html</a><br>
<br>
Stuff will get done when it gets done.<br>
<br>
-Dave<br>
</blockquote></div>

--000000000000888fac05c54240da--