From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B886FC000E; Thu, 24 Jun 2021 13:03:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 88B834040B; Thu, 24 Jun 2021 13:03:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdBNNLtqnFlC; Thu, 24 Jun 2021 13:03:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by smtp2.osuosl.org (Postfix) with ESMTPS id C4CD040159; Thu, 24 Jun 2021 13:03:35 +0000 (UTC) Received: by mail-wm1-x336.google.com with SMTP id o35-20020a05600c5123b02901e6a7a3266cso1184368wms.1; Thu, 24 Jun 2021 06:03:35 -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=aRdpoPhnE5h9zabYFVkSMvwQyGls3HzDQECNKci0H0k=; b=adfMDuVz4lfJrHfqGa830oIjlf4kwB0B89S+0yc0hhmiMWVfmJJhQ2YMtU1VOrd0Hs OMErqvWvKMV/XBS7JqMGX+BgGeC7j1wrFWHcQTitFOVJZXw9QlGB07D9RdMJLonwHkmY L5XeAMdZ4H15Ymzcaru8rlxtcP6n79Bn8EMB1lZeQdWNpEkd6aaKhvi2lRa/86Yu79kJ kn3OEuNP1n5UlDiUQPhVZFtV23dpYD6p9Xyikb9mlaI5/mvBU+3KUQYOqOirtXm3y9Hx h9K/p9AIG+5Cyz4kN7R1nSiZQnC6mH325gqRt0EBRPIQ1SBrDTxFW77ht9JXjizp+lp1 lzpQ== 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=aRdpoPhnE5h9zabYFVkSMvwQyGls3HzDQECNKci0H0k=; b=HNcTrZwrfN4knbZSN30NIEZ4S+GPXn3z0uYccXaDk2Bxc0AwPlRfsU2tJDJyYTTm3h KExRcpZwNGaLswbtb+uMdwUfA9O+X15PvlnwqoPemX5TRknM3FO4yFgPqQ7UhnpHEygm pbOIoba8jsSaVOcaDowOAMz/cB0ObWYHaoW6dcESAifBhLqDEC/nJnFgE5IUUcXZ3XIM wwhWevWUUjg/SSl/RaDy5eX9uu9Am793B6YCeFAcroWRcorLaME7FkJJwzZVqyGuxLgM +FMhc4aSh4P1lj97U0+5xKlf1XAofhDf2SWgw/n0V9eo5NCTjDLJbm8gUsPIhnFsfU70 r7sg== X-Gm-Message-State: AOAM533jhMK7hPeePGeezK+6X+bxxQXIo69B+S0VecdfUYChJ0MrdIMW HFdOiHu1qSWhmndIxIk+S4lpFg8td+8hIjsJLDk= X-Google-Smtp-Source: ABdhPJwqWnYkCIcCyL6xu1kg6l9UEUqR+laOYEdI2xKbXiowR4YSbGahWJG2ady3/RQy+PfTD3yAztUX3ggQyDw++a8= X-Received: by 2002:a1c:21c5:: with SMTP id h188mr4266926wmh.165.1624539813992; Thu, 24 Jun 2021 06:03:33 -0700 (PDT) MIME-Version: 1.0 References: <20210619133653.m2272jgna5geuuki@ganymede> In-Reply-To: From: Antoine Riard Date: Thu, 24 Jun 2021 09:03:21 -0400 Message-ID: To: Michael Folkson Content-Type: multipart/alternative; boundary="000000000000895ce305c582a6b5" X-Mailman-Approved-At: Thu, 24 Jun 2021 20:15:14 +0000 Cc: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 13:03:38 -0000 --000000000000895ce305c582a6b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, > 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 was far more inclined to recall the unsolved problems for Lightning/L2s (pre-signed feerate/tx-pinnings) than calling out strong solutions to them. I believe problem spaces are quite something stable in engineering/science, at least until they're formalized differently. But even coming to consensus on the existence of problems and a shared perception of the severity of them can take a long time. In fact, it might even be the hardest step in a decentralized ecosystem like Bitcoin. And I fill in on the low-relevance of roadmaps, real development is a continuous zigzag. If we look in the past and take the transaction malleability issue, I think we can observe it took multiple proposals (bip 62, normalized txid, sighash_noinput, ...), of which we're even implemented in Core, before to finally settle on segwit. Though I would say lessons were drawn about shortcomings of every transient proposal. > 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 :) I recognize it wasn't delicate to put exact version numbers, though note multiple, alternative versions numbers were deliberately proposed for each specific change and timelines given in terms of years, more as an invite to open a discussion on such changes and where/when they could take place, that in anyway a finite, consistent deployment proposal. Further, I still believe it would be cool to have a bit more coordination when Core implements sophisticated mechanisms designed for downstream support, in the sense of feedback exchanged across projects all along their release schedules. For e.g, with package-relay, as a Lightning team it's likely you will have to rework your tx-broadcast module which might take a few good weeks of review and test. Though, coming to this best practice (imho) across the different Bitcoin layers might take years and that's perfectly fine, we'll see what emerges :) > 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 > 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. Well I strongly believe that the Core review process is open to anyone :) ? If some upper layers contributors are generously offering their time to share back their experiences, especially during the design phase of software features, I hope we might be on path to deliver better stuff. Further, that's a more personal note, I'm worried long-term about layer-monoculture cropping up in the ecosystem, a concern echoing the history of Internet development [0]. > 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. Yes, as answers to my post are showing, I might have lacked patience in this case :/ Sometimes, it's hard to gauge your own cognitive dissonance on topics. Cheers, Antoine [0] See "Interactions between Layers" in "General Architectural and Policy Considerations", RFC 3426 Le lun. 21 juin 2021 =C3=A0 06:20, Michael Folkson a =C3=A9crit : > 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 > technical knowledge doesn't scale when you have multiple second-layers > specifications > > 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 > wrote: > > > > 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 wou= ld > > > be incentivized to rewrite to the oldest state, giving them fee reven= ue > > > 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 cos= t, > > > 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-bump= ed > 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 o= n > 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 advocate= d > for community consensus and those things take time, should just take a fe= w > 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 fro= m magic.=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 po= st > 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 pay= s > > > 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 no= w > 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 hav= e > 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 fo= r > 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/0026= 64.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 tha= t > > depend on the work of a large number of contributors who I don't believ= e > > > > 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 factor= s, > 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 you= r > belief ? I'm curious if you're aware of any contributors who feel entitle= d > 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 Bitco= in > 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 th= e > 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 lik= e > 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/00= 2448.html > > > > [1] https://github.com/bitcoin/bitcoin/issues/14895 > > > > [2] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/0= 02569.html > > > > Le sam. 19 juin 2021 =C3=A0 09:38, David A. Harding 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 > able 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 he= re > >> - 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 transactio= n > >> 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 woul= d > >> be incentivized to rewrite to the oldest state, giving them fee revenu= e > >> now and ensuring fee revenue in the future when a later state update i= s > >> 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 protoco= l. > >> > >> > # 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 belie= ve > >> 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 > > > > -- > Michael Folkson > Email: michaelfolkson@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > --000000000000895ce305c582a6b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

> 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 projec= ts ?

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

I was far more inclined to= recall the unsolved problems for Lightning/L2s (pre-signed feerate/tx-pinn= ings) than calling out strong solutions to them. I believe problem spaces a= re quite something stable in engineering/science, at least until they'r= e formalized differently. But even coming to consensus on=C2=A0 the existen= ce of problems and a shared perception of the severity of them can take a l= ong time. In fact, it might even be the hardest step in a decentralized eco= system like Bitcoin.

And I fill in on the low-relevance of roadmaps,= real development is a continuous zigzag. If we look in the past and take t= he transaction malleability issue, I think we can observe it took multiple = proposals (bip 62, normalized txid, =C2=A0sighash_noinput, ...), =C2=A0of w= hich we're even implemented in Core, before to finally settle on segwit= . Though I would say lessons were drawn about shortcomings of every transie= nt proposal.

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

I r= ecognize it wasn't delicate to put exact version numbers, though note m= ultiple, alternative versions numbers were deliberately proposed for each s= pecific change and timelines given in terms of years,=C2=A0 more as an invi= te to open a discussion on such changes and where/when they could take plac= e, that in anyway a finite, consistent deployment proposal.

Further,= I still believe it would be cool to have a bit more coordination when Core= implements sophisticated mechanisms designed for downstream support, in th= e sense of feedback exchanged across projects all along their release sched= ules. For e.g, with package-relay, as a Lightning team it's likely you = will have to rework your tx-broadcast module which might take a few good we= eks of review and test. Though, coming to this best practice (imho) across = the different Bitcoin layers might take years and that's perfectly fine= , we'll see what emerges :)

> What was making sense when you = had like ~20 Bitcoin dev with 90% of the technical knowledge doesn't sc= ale when you have multiple second-layers specifications

> It is g= reat that we have a larger set of contributors in the ecosystem
> tod= ay 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<= br>> pre 2017. Changes to Core are (generally) likely to be implemented = and
> reviewed by current Core contributors as Lightning implementati= on
> developers (generally) seem to have their hands full with their = own
> implementations.

Well I strongly believe that the Core r= eview process is open to anyone :) ? If some upper layers contributors are = generously offering their time to share back their experiences, especially = during the design phase of software features, I hope we might be on path to= deliver better stuff.

Further, that's a more personal note, I&#= 39;m worried long-term about layer-monoculture cropping up in the ecosystem= , a concern echoing the history of Internet development [0].
=C2=A0
&= gt; I think we can get the balance right by making progress on this
>= (important) discussion whilst also maintaining humility that we don't<= br>> know exact timelines and that getting things merged into Core relie= s
> on a number of people who have varying levels of interest and
= > understanding of L2 protocols.

Yes, as answers to my post are s= howing, I might have lacked patience in this case :/ Sometimes, it's ha= rd to gauge your own cognitive dissonance on topics.

Cheers,
Anto= ine

[0] See "Interactions between Layers" in "G= eneral Architectural and Policy Considerations", RFC 3426
Le=C2=A0l= un. 21 juin 2021 =C3=A0=C2=A006:20, Michael Folkson <michaelfolkson@gmail.com> a =C3=A9crit=C2= =A0:
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 b= ased on FOSS experience from Linux/Juniper, which to the best of my knowled= ge are centralized software projects ?

That is Greg's point. If Linux doesn't look further than the curren= t
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 th= e technical knowledge doesn't scale when you have multiple second-layer= s specifications

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> wrote:<= br> >
> Hi Dave,
>
> > That might work for current LN-penalty, but I'm not sure it w= orks for
> eltoo.
>
> Well, we have not settled yet on the eltoo design but if we take the l= ater proposal in date [0], signing the update transaction with SIGHGASH_ANY= PREVOUT lets you attach non-interactively a single-party controlled input a= t broadcast-time. Providing the input amount is high enough to bump the tra= nsaction 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 ?
>
> >=C2=A0 If Bitcoin Core can rewrite the blind CPFP fee bump transac= tion
> > 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 r= evenue
> > now and ensuring fee revenue in the future when a later state upd= ate 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 pa= y
> > another anyprevout bounty to miners.
>
> This is also true with package-relay where your counterparty, with a b= etter knowledge of network mempools, can always re-broadcast a CPFP-bumped = malicious package ? Under this assumption, I think you should always be rea= dy to bump our honest package.
>
> Further, for the clarity of the discussion, can you point to which pin= ning scenario you're thinking of or if it's new under SIGHASH_ANYPR= EVOUT, describe it ?
>
> > Repeat this a bunch of times and the honest user has now spent mo= re on fees than their balance from the
> closed channel.
>
> And sadly, as this concern also exists in case of a miner-harvesting a= ttack against LN nodes, a concern that Gleb and I expressed more than a yea= r 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=C2=A0 in "On Mempool Fun= ny 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
>=C2=A0 the transaction doesn't confirm and if it's responsible = for the
>=C2=A0 fee-bumping, it might do multiple rounds of feerate increase thr= ough CPFP,
>=C2=A0 in vain. As the fee-bumping algorithm is assumed to be known if = the victim
>=C2=A0 client is open source code, the attacker can predict when the fe= e-bumping
>=C2=A0 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 advoc= ated 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 magica= lly
> 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 indistinguishab= le from magic.=E2=80=9D Arthur C. Clarke
>
> Wit apart, that might be the outcome with careful bitcoin protocol dev= elopment, where technical issues are laid out in a best effort (of mine!) a= nd 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'v= e written so much explicitly in this thread post by pointing to an older po= st of mine ("Advances in Bitcoin Contracting : Uniform Policy and Pack= age 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.=C2=A0 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 n= ow making the sender responsible for the receiver quality of its mempool fe= erate ? This question has never been clear up during the years-long discuss= ion of package-relay design [1].
>
> Though referring to the thread post and last week's transaction-re= lay workshop, I did point out that package-relay might serve in the long-te= rm as a mempool-sync mechanism to prevent potential malicious mempool parti= tions [2].
>
> > Package relay is a clear improvement now, and one I expect to be<= br> > permanent for as long as we're using anything like the current pro= tocol
>
> Again, reading my post, I did point out that we might keep the "l= ower half" of package-relay and deprecate only the higher part of it a= s we have more feerate-efficient fee-bumping primitive available. If=C2=A0 = it sounds too much of a release engineering effort to synchronize on the sc= ale of an ecosystem, think about the ongoing deprecation of Tor V2.
>
> Further, you did express a far less assertive opinion during last Tues= day transaction-relay workshops, to which a lot of folks attended, where yo= u pointed it might not be a good idea for L2s to make more assumptions on n= on-normative:
>
> "harding> I do think we should be using miners profit incentiv= e 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 l= ike this that
> depend on the work of a large number of contributors who I don't b= elieve
>
> 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 the= ir private judgement. It might be based from a lot of different factors, e.= g "trusting the experts" or gathering diverse in-field authoritie= s' opinions or reasoning from scratch based on raw, public facts.
>
> Though might I ask you on which information sources are you finding yo= ur belief ? I'm curious if you're aware of any contributors who fee= l 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 : LN= D, c-ligtning, Eclair, coin-teleport, revault, sapio, btcsuite, bcoin, libb= itcoin, 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 h= is opinion on how the expressed framework applies to my post, the Bitcoin d= ev stage has grown a lot since then. What was making sense when you had lik= e ~20 Bitcoin dev with 90% of the technical knowledge doesn't scale whe= n you have multiple second-layers specifications of which you have multiple= implementations teams, some of them=C2=A0 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 b= ased on FOSS experience from Linux/Juniper, which to the best of my knowled= ge 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 pol= icy changes slipping in the codebase. Let's minimize CVE-2020-26895 sty= le-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 seriou= sness 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 st= age.
>
> So better to patch them before they do manifest in the wild, and folks= start to bleed coins.=C2=A0 What you learn from practicing security resear= ch, 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 th= e skilled folks around to catch them :)
>
> And yes I really care about Lightning, and all those cute new L2 proto= cols 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 fre= e 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 toda= y 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://l= ists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
>
> [1] https://github.com/bitcoin/bitcoin/issues/14= 895
>
> [2] https://= lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/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<= br> >> > SIGHASH_ANYPREVOUT
>> >
>> > For Lightning, either package-relay or SIGHASH_ANYPREVOUT sho= uld be able to
>> > solve the pre-signed feerate issue [3]
>> >
>> > [...]
>> >
>> > [3] I don't think there is a clear discussion on how SIGH= ASH_ANYPREVOUT
>> > solves pinnings beyond those LN meetings logs:
>> > https://gnusha.org/lightning-dev/2020-0= 6-08.log
>>
>> For anyone else looking, the most relevant line seems to be:
>>
>>=C2=A0 =C2=A013:50 < BlueMatt> (sidenote: sighash_no_input is= *really* elegant here
>>=C2=A0 =C2=A0- assuming a lot of complicated logic in core to do so= , you could
>>=C2=A0 =C2=A0imagine blind-cpfp-bumping *any* commitment tx without= knowing its
>>=C2=A0 =C2=A0there or which one it is all with one tx.......in theo= ry)
>>
>> That might work for current LN-penalty, but I'm not sure it wo= rks for
>> eltoo.=C2=A0 If Bitcoin Core can rewrite the blind CPFP fee bump t= ransaction
>> 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 re= venue
>> now and ensuring fee revenue in the future when a later state upda= te 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.=C2=A0 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 distri= bute
>> it before you promote it much more.
>>
>> > package-relay sounds a reasonable, temporary "patch"= ;.
>>
>> Even if every protocol based on presigned transactions can magical= ly
>> allow dynamically adding inputs and modifying outputs for fees, an= d we
>> also have a magic perfect transaction replacement protocol, packag= e
>> relay is still fundamentally useful for CPFP fee bumping very low<= br> >> feerate transactions received from an external party.=C2=A0 E.g. A= lice 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 li= ke this that
>> depend on the work of a large number of contributors who I don'= ;t believe
>> you've consulted.=C2=A0 For details on this point of view, ple= ase 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.o= rg/mailman/listinfo/lightning-dev



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