MIME-Version: 1.0
References: <CALZpt+FF_TT_K3wjWhhaDE6Ue=RAsM2JWO7-mYjm5LtHqJvNmg@mail.gmail.com>
 <20210619133653.m2272jgna5geuuki@ganymede>
 <CALZpt+E0AbLBj+eQTffuW+W02OeguU+59Ak09UQ-y=vJXNJ0Ew@mail.gmail.com>
In-Reply-To: <CALZpt+E0AbLBj+eQTffuW+W02OeguU+59Ak09UQ-y=vJXNJ0Ew@mail.gmail.com>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Mon, 21 Jun 2021 11:20:40 +0100
Message-ID: <CAFvNmHTq=5E-+ON1zGfnKPmFMd7=qG9d+MTrnObJiziF6qsOrQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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
Precedence: list

I don't want to divert from the topic of this thread ("Waiting
SIGHASH_ANYPREVOUT and Packing Packages"), we can set up a separate
thread if we want to discuss this further. But just a couple of
things.

> 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 ?

That is Greg's point. If Linux doesn't look further than the current
version and the next version with a BDFL (Linus) a decentralized
project like Bitcoin Core is going to struggle even more with longer
term roadmaps.

I think it is important to discuss what order changes should be
attempted but I agree with David that putting specific future version
numbers on changes is speculative at best and misleading at worst. The
record of previous predictions of what will be included in particular
future versions is not strong :)

> What was making sense when you had like ~20 Bitcoin dev with 90% of the t=
echnical knowledge doesn't scale when you have multiple second-layers speci=
fications

It is great that we have a larger set of contributors in the ecosystem
today than back in say pre 2017. But today that set of contributors is
spread widely across a number of different projects that didn't exist
pre 2017. Changes to Core are (generally) likely to be implemented and
reviewed by current Core contributors as Lightning implementation
developers (generally) seem to have their hands full with their own
implementations.

I think we can get the balance right by making progress on this
(important) discussion whilst also maintaining humility that we don't
know exact timelines and that getting things merged into Core relies
on a number of people who have varying levels of interest and
understanding of L2 protocols.

On Mon, Jun 21, 2021 at 9:13 AM Antoine Riard <antoine.riard@gmail.com> wro=
te:
>
> 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 late=
r proposal in date [0], signing the update transaction with SIGHGASH_ANYPRE=
VOUT lets you attach non-interactively a single-party controlled input at b=
roadcast-time. Providing the input amount is high enough to bump the transa=
ction feerate over network mempools, it should allow the tx to propagate ac=
ross 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 av=
oid 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 bett=
er knowledge of network mempools, can always re-broadcast a CPFP-bumped mal=
icious 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 pinnin=
g scenario you're thinking of or if it's new under SIGHASH_ANYPREVOUT, desc=
ribe 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 atta=
ck against LN nodes, a concern that Gleb and I expressed more than a year a=
go 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-bu=
mping 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 w=
hy
>  the transaction doesn't confirm and if it's responsible for the
>  fee-bumping, it might do multiple rounds of feerate increase through CPF=
P,
>  in vain. As the fee-bumping algorithm is assumed to be known if the vict=
im
>  client is open source code, the attacker can predict when the fee-bumpin=
g
>  logic reaches its upper bound."
>
> Though thanks for the recall! I should log dynamic-balances in RL's `Chan=
nelMonitorUpdate` for our ongoing implementation of anchor, updating my TOD=
O :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 privat=
e discussion with Matt. Though as SIGHASH_ANYPREVOUT isn't advocated for co=
mmunity 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 =
magic.=E2=80=9D Arthur C. Clarke
>
> Wit apart, that might be the outcome with careful bitcoin protocol develo=
pment, where technical issues are laid out in a best effort (of mine!) and =
spread to the Bitcoin community on the most public bitcoin communication ch=
annel ?
>
> And humbly, on all those L2 issues I did change my opinion, as I've writt=
en so much explicitly in this thread post by pointing to an older post of m=
ine ("Advances in Bitcoin Contracting : Uniform Policy and Package Relay").=
 This reversal, partially motivated by a lot of discussion with folks, incl=
uding yourself, initiated since at least mid last year.
>
> > package relay is still fundamentally useful for CPFP fee bumping very l=
ow
> > 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 feera=
te ? 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 wor=
kshop, 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 hal=
f" of package-relay and deprecate only the higher part of it as we have mor=
e feerate-efficient fee-bumping primitive available. If  it sounds too much=
 of a release engineering effort to synchronize on the scale of an ecosyste=
m, 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 p=
ointed 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 po=
ssible), e.g. things like https://lists.linuxfoundation.org/pipermail/light=
ning-dev/2020-April/002664.html"
>
> Arguing for package-relay "permanence" moves in the contrary decision IMH=
O ?
>
> > 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 partic=
ipant of this mailing list make an opinion on its own, following their priv=
ate judgement. It might be based from a lot of different factors, e.g "trus=
ting the experts" or gathering diverse in-field authorities' opinions or re=
asoning 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 th=
at would have been a lot of open source projects teams to reach out : LND, =
c-ligtning, Eclair, coin-teleport, revault, sapio, btcsuite, bcoin, libbitc=
oin, 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 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't scale when you have multiple=
 second-layers specifications of which you have multiple implementations te=
ams, some of them  decentralized and spread through different countries/tim=
ezones, IMHO.
>
> Though, Dave if you strongly hold your opinion on my behavior, I would in=
vite 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-b=
ugs 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 seriousne=
ss has been underscored by a lot of contributors in the past, especially fo=
r 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 st=
art 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 f=
olks around to catch them :)
>
> And yes I really care about Lightning, and all those cute new L2 protocol=
s 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 us=
e, 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-Januar=
y/002448.html
>
> [1] https://github.com/bitcoin/bitcoin/issues/14895
>
> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-Februa=
ry/002569.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 ab=
le to
>> > solve the pre-signed feerate issue [3]
>> >
>> > [...]
>> >
>> > [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOU=
T
>> > 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
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3