Michael Folkson [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-08-01 to 2023-05-23
💬 Posted a total of 136 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev, Mempool spam
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpam

Profile Code

nprofile1qqs8cjvp7rfutmkfwccaufemykmyxhc0x0s05mxwyuxa60ems7tay6sh0mcgy

Author Public Key

npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpam

Show more details

Last Notes

2023-06-19 17:42:23

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: Reputation data can assist in making probabilistic judgments about future behavior, but it cannot guarantee security. It is not a protocol or P2P gossiping issue, and there may be competing reputation data providers and services.
📝 Original message:
>From my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing.
Now where it sits on the software stack assuming a user opts into such a reputation "service" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the "core" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service.
So yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a "core" of a Lightning node issue.
Thanks
Michael
[0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 12:57, Christian Decker <decker.christian at gmail.com> wrote:
> Hi Antoine,
>
> this is an intrinsic issue with reputation systems, and the main
> reason I'm sceptical w.r.t. their usefulness in lightning.
> Fundamentally any reputation system bases their expectations for the
> future on experiences they made in the past, and they are thus always
> susceptible to sudden behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
> This gets compounded as soon as we start gossiping about reputations,
> since now our decisions are no longer based just on information we can
> witness ourselves, or at least verify its correctness, and as such an
> attacker can most likely "earn" a positive reputation in some other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
> I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
> Cheers,
> Christian
>
> On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.riard at gmail.com wrote:
>
> > Hi *,
> >
> > > Our suggestion is to start simple with a binary endorsement field. As
> > > we learn more, we will be better equipped to understand whether a
> > > more expressive value is required.
> >
> > I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation.
> >
> > I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement.
> >
> > Opened an issue on the repository to converge on a threat model:
> > https://github.com/ClaraShk/LNJamming/pull/13
> >
> > I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces.
> >
> > Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming.
> >
> > Best,
> > Antoine
> >
> > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
> >
> > Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen kirkcohenc at gmail.com a écrit :
> >
> > > Hi list,
> > >
> > > Some updates on channel jamming!
> > >
> > > # Next Call
> > > - Monday 01 May @ 15:00 UTC
> > > - https://meet.jit.si/UnjammingLN
> > > - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
> > >
> > > # Data Gathering
> > > During these weekly calls, we've come to agreement that we would like
> > > to gather data about the use of HTLC endorsement and local reputation
> > > tracking for jamming mitigation. A reminder of the full scheme is
> > > included at the end of this email, and covered more verbosely in [1].
> > >
> > > We have a few goals in mind:
> > > - Observe the effect of endorsement in the steady state with
> > > logging-only implementation.
> > > - Gather real-world data for use in future simulation work.
> > > - Experiment with different algorithms for tracking local reputation.
> > >
> > > The minimal changes required to add HTLC endorsement are outlined in [2].
> > > Our suggestion is to start simple with a binary endorsement field. As
> > > we learn more, we will be better equipped to understand whether a
> > > more expressive value is required.
> > >
> > > With this infrastructure in place, we can start to experiment with
> > > various local reputation schemes and data gathering, possibly even
> > > externally to LN implementations in projects like circuitbreaker [3].
> > > We'd be interested to hear whether there's any appetite to deploy using
> > > an experimental TLV value?
> > >
> > > # Reputation Scheme
> > > - Each node locally tracks the reputation of its direct neighbors.
> > > - Each node allocates, per its risk tolerance:
> > > - A number of slots reserved for endorsed HTLCs from high reputation
> > > peers.
> > > - A portion of liquidity reserved for endorsed HTLCs from high
> > > reputation peers.
> > > - Forwarding of HTLCs:
> > > - If a HTLC is endorsed by a high reputation peer, it is forwarded
> > > as usual with endorsed = 1.
> > > - Otherwise, it is forwarded with endorsed = 0 if there are slots and
> > > liquidity available for unknown HTLCs.
> > >
> > > Endorsement and reputation are proposed as the first step in a two part
> > > scheme for mitigating channel jamming:
> > > - Reputation for slow jams which are easily detected as misbehavior.
> > > - Unconditional fees for quick jams that are difficult to detect, as
> > > they can always fall under a target threshold.
> > >
> > > Looking forward to discussing further in the upcoming call!
> > >
> > > Best,
> > > Carla and Clara
> > >
> > > [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
> > > [2] https://github.com/lightning/bolts/pull/1071
> > > [3] https://github.com/lightningequipment/circuitbreaker
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-19 17:42:05

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Michael Folkson suggests adding more moderators to the lightning-dev mailing list due to the increasing number of emails and intertwined discussions.
📝 Original message:
Perhaps we need another moderator or two for the lightning-dev mailing list? There are already a lot of emails on the bitcoin-dev mailing list and so despite my views on the trend of Bitcoin and Lightning discussion becoming increasingly intertwined it probably makes sense to keep both bitcoin-dev and lightning-dev lists and just bump the number of moderators on lightning-dev.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Monday, May 8th, 2023 at 22:07, Vincenzo Palazzo <vincenzopalazzodev at gmail.com> wrote:
> > Is there a better place to have public communication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week.
> >
> > Would hate to see this list die but wondering if there's a better place for discussions?
>
>
> I think currently the list is the most accessible way that we have.
>
> I am not aware of any other tools that are as accessible as the list archive
> to search for some history, and also to allow people in 10 years from now to
> implement some of the ideas proposed these days.
>
> But I would agree to change communication tools if we do not lose these
> two properties.
>
> Cheers.
>
> Vincent.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:13:18

- reply

2023-06-09 13:13:08

- reply

2023-06-09 13:13:04

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Default policy changes for Lightning are scattered and not formalized, making it difficult to follow. Integrating Lightning into Bitcoin Core could have benefits but requires strong incentives and significant effort. Separating consensus logic may be a more practical goal.
📝 Original message:
Hi Kostas
> Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing.
It is hard to follow because most of the discussions aren't on public channels, a number of the devs working on these proposed default policy changes aren't taking the BIP process seriously and no one is willing to discuss the criteria for merging default policy changes (and consensus changes for that matter) into bitcoin-inquisition (default signet). In addition the work (to the extent that it is public) is scattered all over the place. So yeah it seems like a mess to me from the perspective of someone is seeking to follow, review and monitor it.
This Bitcoin StackExchange post [0] is my first attempt to do what you're looking for and these Bitcoin Core PR review clubs [1], [2] were really good from Gloria. But yeah the BIP process (as I've said a thousand times and been ignored) is the place to hammer out specifications for complex things like default policy proposals and when people don't care about formalizing specifications it becomes very hard for people like you and me to follow.
> Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument.
>> I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX?
As I say in the original email having two separate P2P networks and two separate P2P protocols (perhaps) doesn't make much sense if all (or most of the nodes) are both full nodes and Lightning nodes. A testing framework that integrates both base layer and Lightning tests could potentially be easier to track edge cases which fall in the grey area between base layer and Lightning but are critically important for Lightning. A Core wallet that doesn't support Lightning doesn't make much sense in a world where transaction fees are really high and you have to use Lightning unless you are transferring huge amounts. I agree with you that these arguments have to be strong to counter the separation of concerns angle and maybe it is too early to consider it. But if moving in the direction of more widely used consensus compatible forks of Core then having Lightning integrated could make it an attractive option.
> PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)?
libbitcoinkernel can achieve smaller (and still important) goals but I'm skeptical that the more ambitious goal of having lots of different implementations in different languages with libbitcoinkernel at its core and not having to worry about consensus bugs will be reached in the medium term. As we saw with the recent btcd/lnd bugs [3] consensus bugs can crop up in places you might not expect. In that case it was a wire parsing library that you wouldn't expect to be part of a libbitcoinkernel. So if you're still going to encounter consensus bugs outside of libbitcoinkernel there isn't much point (in my view) in using it for alternative implementations.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy
[1]: https://bitcoincore.reviews/25038
[2]: https://bitcoincore.reviews/25038-2
[3]: https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 10:05, Kostas Karasavvas <kkarasavvas at gmail.com> wrote:
> Hi Michael,
>
> On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not
>
> Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing.
>
>> exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense.
>
> Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument.
>
> I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX?
>
>> Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.
>
>> The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.
>
> Personally, I have great difficulty seeing lightning as something other than an L2 build on top of Bitcoin. There will be other L2s.
>
> Regards,
> Kostas
>
> PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)?
>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:
>>
>>> I tweeted this [0] back in November 2022.
>>>
>>> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>>>
>>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>>>
>>> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>>>
>>> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>>>
>>> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>>>
>>> Thanks
>>> Michael
>>>
>>> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>>> Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230419/43c5b5f7/attachment-0001.html>

2023-06-09 13:13:03

- reply

📅 Original date posted:2023-04-18
🗒️ Summary of this message: The dysfunction in the Bitcoin Core project has led to the idea of a Knots style Bitcoin implementation integrated with Core Lightning, as a tighter coupling between the full node and the Lightning node could eventually make sense.
📝 Original message:
Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense. Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.
The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>
> Thanks
> Michael
>
> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230418/a61cc0c7/attachment-0001.html>

2023-06-09 13:12:31

- reply

📅 Original date posted:2023-01-14
🗒️ Summary of this message: Michael Folkson suggests that a bare bones Knots style Bitcoin implementation integrated with Core Lightning may be the future due to dysfunction in Bitcoin Core's management.
📝 Original message:
I tweeted this [0] back in November 2022.
"With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
Thanks
Michael
[0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230114/306cd5ac/attachment.html>

2023-06-09 13:12:31

- reply

📅 Original date posted:2023-01-14
🗒️ Summary of this message: The author suggests that a Knots-style fork of Core in C++ integrated with Core Lightning in C is a better option for serious production use cases.
📝 Original message:
I saw it was announced, yes. The author is brilliant, he has now managed two alternative implementations of Core in two different languages :)
The problem though and why I and many others think the Knots style fork of Core is the better option is because you avoid reimplementing consensus code in a different language. If you're ultra conservative about consensus code you either want to run Core in parallel with your alternative implementation to check they don't go out of consensus or you want to run the same consensus code as Core in a Knots like fork. Hence a Knots like fork of Core in C++ integrated with Core Lightning in C seems like the better option to me for serious running in production like use cases.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, January 14th, 2023 at 20:34, Fabian <fjahr at protonmail.com> wrote:
> Hi Michael,
>
> have you seen Mako? It might at least be a good start for what you would like to achieve: https://github.com/chjj/mako
>
> Best,
> Fabian
> ------- Original Message -------
> On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> I tweeted this [0] back in November 2022.
>>
>> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>>
>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>>
>> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>>
>> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>>
>> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>>
>> Thanks
>> Michael
>>
>> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230114/f701a6df/attachment.html>

2023-06-09 13:08:48

- reply

📅 Original date posted:2023-05-10
📝 Original message:
>From my perspective it really comes down to whether you want security *guarantees* or data to assist you in making probabilistic judgments about future behavior. Reputation data or reputation systems will never give you guarantees for the reasons Christian explains. But reputation data is better than nothing and depending on the quality and granularity of the data could be considerably better than nothing. In the most basic case of deciding on a potential channel counterparty I would much rather choose a counterparty who has demonstrated competence and reliability over a number of years than a channel counterparty who has just joined the network and who I know nothing about. Similarly a Lightning node that hasn't carried a jamming attack for multiple years despite having the opportunity to is a much better bet than a Lightning node of which I know nothing.
Now where it sits on the software stack assuming a user opts into such a reputation "service" (plugin maybe or more likely an API) is I think what in essence this discussion is about. As I've already stated previously and which I agree with Christian on is that it isn't/shouldn't be a protocol or a P2P gossiping issue. In the same way as we have multiple Lightning explorers (1ML, Amboss etc) that aren't part of the Lightning protocol or part of the "core" of a Lightning node you can expect there would be competing reputation data providers and services. Also many users for privacy and/or other reasons won't be interested in using or participating in (to the extent they can opt out if the data is public) a reputation service.
So yeah I think I'm somewhere in between Christian's and Antoine's perspectives here. I do think there are interesting projects, services or even businesses in this area of reputation but it isn't a protocol/P2P gossiping issue or a "core" of a Lightning node issue.
Thanks
Michael
[0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003766.html
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 12:57, Christian Decker <decker.christian at gmail.com> wrote:
> Hi Antoine,
>
> this is an intrinsic issue with reputation systems, and the main
> reason I'm sceptical w.r.t. their usefulness in lightning.
> Fundamentally any reputation system bases their expectations for the
> future on experiences they made in the past, and they are thus always
> susceptible to sudden behavioral changes (going rogue from a prior
> clean record) and whitewashing attacks (switching identity, abusing
> any builtin bootstrapping method for new users to gain a good or
> neutral reputation before turning rogue repeatedly).
>
> This gets compounded as soon as we start gossiping about reputations,
> since now our decisions are no longer based just on information we can
> witness ourselves, or at least verify its correctness, and as such an
> attacker can most likely "earn" a positive reputation in some other
> part of the world, and then turn around and attack the nodes that
> trusted the reputation shared from those other parts.
>
> I'd be very interested in how many repeat interactions nodes get from
> individual senders, since that also tells us how much use we can get
> out of local-only reputation based systems, and I wouldn't be
> surprised if, for large routing nodes, we have sufficient data for
> them to make an informed decision, while the edges may be more
> vulnerable, but they'd also be used by way fewer senders, and the
> impact of an attack would also be proportionally smaller.
>
> Cheers,
> Christian
>
> On Mon, May 8, 2023 at 10:26 PM Antoine Riard antoine.riard at gmail.com wrote:
>
> > Hi *,
> >
> > > Our suggestion is to start simple with a binary endorsement field. As
> > > we learn more, we will be better equipped to understand whether a
> > > more expressive value is required.
> >
> > I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation.
> >
> > I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement.
> >
> > Opened an issue on the repository to converge on a threat model:
> > https://github.com/ClaraShk/LNJamming/pull/13
> >
> > I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces.
> >
> > Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming.
> >
> > Best,
> > Antoine
> >
> > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html
> >
> > Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen kirkcohenc at gmail.com a écrit :
> >
> > > Hi list,
> > >
> > > Some updates on channel jamming!
> > >
> > > # Next Call
> > > - Monday 01 May @ 15:00 UTC
> > > - https://meet.jit.si/UnjammingLN
> > > - Agenda: https://github.com/ClaraShk/LNJamming/issues/12
> > >
> > > # Data Gathering
> > > During these weekly calls, we've come to agreement that we would like
> > > to gather data about the use of HTLC endorsement and local reputation
> > > tracking for jamming mitigation. A reminder of the full scheme is
> > > included at the end of this email, and covered more verbosely in [1].
> > >
> > > We have a few goals in mind:
> > > - Observe the effect of endorsement in the steady state with
> > > logging-only implementation.
> > > - Gather real-world data for use in future simulation work.
> > > - Experiment with different algorithms for tracking local reputation.
> > >
> > > The minimal changes required to add HTLC endorsement are outlined in [2].
> > > Our suggestion is to start simple with a binary endorsement field. As
> > > we learn more, we will be better equipped to understand whether a
> > > more expressive value is required.
> > >
> > > With this infrastructure in place, we can start to experiment with
> > > various local reputation schemes and data gathering, possibly even
> > > externally to LN implementations in projects like circuitbreaker [3].
> > > We'd be interested to hear whether there's any appetite to deploy using
> > > an experimental TLV value?
> > >
> > > # Reputation Scheme
> > > - Each node locally tracks the reputation of its direct neighbors.
> > > - Each node allocates, per its risk tolerance:
> > > - A number of slots reserved for endorsed HTLCs from high reputation
> > > peers.
> > > - A portion of liquidity reserved for endorsed HTLCs from high
> > > reputation peers.
> > > - Forwarding of HTLCs:
> > > - If a HTLC is endorsed by a high reputation peer, it is forwarded
> > > as usual with endorsed = 1.
> > > - Otherwise, it is forwarded with endorsed = 0 if there are slots and
> > > liquidity available for unknown HTLCs.
> > >
> > > Endorsement and reputation are proposed as the first step in a two part
> > > scheme for mitigating channel jamming:
> > > - Reputation for slow jams which are easily detected as misbehavior.
> > > - Unconditional fees for quick jams that are difficult to detect, as
> > > they can always fall under a target threshold.
> > >
> > > Looking forward to discussing further in the upcoming call!
> > >
> > > Best,
> > > Carla and Clara
> > >
> > > [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343
> > > [2] https://github.com/lightning/bolts/pull/1071
> > > [3] https://github.com/lightningequipment/circuitbreaker
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:08:38

- reply

📅 Original date posted:2023-05-08
📝 Original message:
Perhaps we need another moderator or two for the lightning-dev mailing list? There are already a lot of emails on the bitcoin-dev mailing list and so despite my views on the trend of Bitcoin and Lightning discussion becoming increasingly intertwined it probably makes sense to keep both bitcoin-dev and lightning-dev lists and just bump the number of moderators on lightning-dev.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Monday, May 8th, 2023 at 22:07, Vincenzo Palazzo <vincenzopalazzodev at gmail.com> wrote:
> > Is there a better place to have public communication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week.
> >
> > Would hate to see this list die but wondering if there's a better place for discussions?
>
>
> I think currently the list is the most accessible way that we have.
>
> I am not aware of any other tools that are as accessible as the list archive
> to search for some history, and also to allow people in 10 years from now to
> implement some of the ideas proposed these days.
>
> But I would agree to change communication tools if we do not lose these
> two properties.
>
> Cheers.
>
> Vincent.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:08:34

- reply

📅 Original date posted:2023-04-19
📝 Original message:
Hi Kostas
> Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing.
It is hard to follow because most of the discussions aren't on public channels, a number of the devs working on these proposed default policy changes aren't taking the BIP process seriously and no one is willing to discuss the criteria for merging default policy changes (and consensus changes for that matter) into bitcoin-inquisition (default signet). In addition the work (to the extent that it is public) is scattered all over the place. So yeah it seems like a mess to me from the perspective of someone is seeking to follow, review and monitor it.
This Bitcoin StackExchange post [0] is my first attempt to do what you're looking for and these Bitcoin Core PR review clubs [1], [2] were really good from Gloria. But yeah the BIP process (as I've said a thousand times and been ignored) is the place to hammer out specifications for complex things like default policy proposals and when people don't care about formalizing specifications it becomes very hard for people like you and me to follow.
> Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument.
>> I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX?
As I say in the original email having two separate P2P networks and two separate P2P protocols (perhaps) doesn't make much sense if all (or most of the nodes) are both full nodes and Lightning nodes. A testing framework that integrates both base layer and Lightning tests could potentially be easier to track edge cases which fall in the grey area between base layer and Lightning but are critically important for Lightning. A Core wallet that doesn't support Lightning doesn't make much sense in a world where transaction fees are really high and you have to use Lightning unless you are transferring huge amounts. I agree with you that these arguments have to be strong to counter the separation of concerns angle and maybe it is too early to consider it. But if moving in the direction of more widely used consensus compatible forks of Core then having Lightning integrated could make it an attractive option.
> PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)?
libbitcoinkernel can achieve smaller (and still important) goals but I'm skeptical that the more ambitious goal of having lots of different implementations in different languages with libbitcoinkernel at its core and not having to worry about consensus bugs will be reached in the medium term. As we saw with the recent btcd/lnd bugs [3] consensus bugs can crop up in places you might not expect. In that case it was a wire parsing library that you wouldn't expect to be part of a libbitcoinkernel. So if you're still going to encounter consensus bugs outside of libbitcoinkernel there isn't much point (in my view) in using it for alternative implementations.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy
[1]: https://bitcoincore.reviews/25038
[2]: https://bitcoincore.reviews/25038-2
[3]: https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 10:05, Kostas Karasavvas <kkarasavvas at gmail.com> wrote:
> Hi Michael,
>
> On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not
>
> Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing.
>
>> exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense.
>
> Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument.
>
> I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX?
>
>> Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.
>
>> The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.
>
> Personally, I have great difficulty seeing lightning as something other than an L2 build on top of Bitcoin. There will be other L2s.
>
> Regards,
> Kostas
>
> PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)?
>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:
>>
>>> I tweeted this [0] back in November 2022.
>>>
>>> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>>>
>>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>>>
>>> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>>>
>>> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>>>
>>> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>>>
>>> Thanks
>>> Michael
>>>
>>> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>>> Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230419/43c5b5f7/attachment-0001.html>

2023-06-09 13:08:33

- reply

📅 Original date posted:2023-04-18
📝 Original message:
Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense. Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.
The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>
> Thanks
> Michael
>
> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230418/a61cc0c7/attachment-0001.html>

2023-06-09 13:07:55

- reply

📅 Original date posted:2023-01-14
📝 Original message:
I saw it was announced, yes. The author is brilliant, he has now managed two alternative implementations of Core in two different languages :)
The problem though and why I and many others think the Knots style fork of Core is the better option is because you avoid reimplementing consensus code in a different language. If you're ultra conservative about consensus code you either want to run Core in parallel with your alternative implementation to check they don't go out of consensus or you want to run the same consensus code as Core in a Knots like fork. Hence a Knots like fork of Core in C++ integrated with Core Lightning in C seems like the better option to me for serious running in production like use cases.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, January 14th, 2023 at 20:34, Fabian <fjahr at protonmail.com> wrote:
> Hi Michael,
>
> have you seen Mako? It might at least be a good start for what you would like to achieve: https://github.com/chjj/mako
>
> Best,
> Fabian
> ------- Original Message -------
> On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> I tweeted this [0] back in November 2022.
>>
>> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>>
>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>>
>> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>>
>> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>>
>> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>>
>> Thanks
>> Michael
>>
>> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230114/f701a6df/attachment.html>

2023-06-09 13:07:54

- reply

📅 Original date posted:2023-01-14
📝 Original message:
I tweeted this [0] back in November 2022.
"With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
Thanks
Michael
[0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230114/306cd5ac/attachment.html>

2023-06-09 13:07:36

- reply

📅 Original date posted:2022-12-09
📝 Original message:
> I don't think so - today there are at least three different routing goals to maximize - (a) privacy,
> (b) fees, (c) success rate. For "live" payment, you probably want to lean towards optimizing for
> success rate, and many nodes do today by default. But that isn't the full story - many nodes do
> background rebalancing and they prefer to take paths which optimize for fees, trying many paths they
> think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell
> those users/use-cases that they aren't allowed to do that or they're doing something "wrong" - I
> think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and
> ideally make as reliable as possible, without charging extra for it.
Right, the trade-offs here are really tricky to navigate and to whatever extent this is possible the choice of what trade-offs to make should be pushed to the user. For example, not knowing the real time channel balances clearly hurts routing success. If this degraded routing success from 95 percent to say 90 percent the network as a whole would probably be willing to pay that routing success "cost" to ensure better balance privacy. But if it degraded routing success from 95 percent to say 50 percent I expect much of the network wouldn't be willing to put up with that terrible routing success percentage and routing nodes would probably seek to broadcast their channel balances either in gossip or out of band.
Similarly a routing node not knowing the source of the payment and the intermediate nodes on the route is fine (it is clearly *much* better for privacy) assuming jamming attacks occur rarely. But if the network is being paralyzed regularly by jamming attacks a routing node is going to show a lot more interest in which Lightning node it is routing payments for and which other Lightning nodes are also part of the route. You aren't going to want to continue to be subject to jamming attacks by the same Lightning node.
Hence I stick by this from a protocol developer perspective.
"Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others."
A protocol developer (and individual implementation developer I guess) is going to have to wrestle with these trade-offs and to what extent options can be pushed to the user. But protocol reputation tokens that can be sold or transferred to an attacker or worse collected through gaming the system, ouch. The protocol developer has taken a problem (jamming attacks) that already exists and added an additional problem (reputation) which no doubt will be addressed by adding an additional problem on top of that and another on top of that etc etc.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, December 4th, 2022 at 02:03, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>
> On 11/15/22 12:09 PM, Clara Shikhelman wrote:
>
> > Matt – I don't know that I agree with "... upfront payments kinda kill the lightning UX ...". I
> > think that upfront fees are almost essential, even outside the context of jamming. This also helps
> > with probing, general spam, and other aspects. Furthermore, I think that the UX is very explainable,
>
>
> Indeed, it may be explainable, but its still somewhat painful, I think. I do wonder if we can enable
> probing via a non-HTLC message and do immediate pre-send-probing to avoid paying upfront fees on
> paths that will fail.
>
> > and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt
> > better routing strategies.
>
>
> I don't think so - today there are at least three different routing goals to maximize - (a) privacy,
> (b) fees, (c) success rate. For "live" payment, you probably want to lean towards optimizing for
> success rate, and many nodes do today by default. But that isn't the full story - many nodes do
> background rebalancing and they prefer to take paths which optimize for fees, trying many paths they
> think are likely to fail to see if they can rebalance with lower fees. I don't think we should tell
> those users/use-cases that they aren't allowed to do that or they're doing something "wrong" - I
> think choosing to optimize for fees (or, in the future, privacy) is an important thing to allow, and
> ideally make as reliable as possible, without charging extra for it.
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:07:28

- reply

📅 Original date posted:2022-11-29
📝 Original message:
> Therefore, in case of loopholes in the system damages are effectively borne by the routing hops, without throwing the whole system down.
I'm not sure why harming routing nodes is any less of a concern than harming the experience of say edge nodes when introducing game-able systems with uncertainty over the edge cases. Especially when iteration of that system might never lead to a solution we are happy with. A whack-a-mole type thing where plugging one hole creates another hole.
> On the second point, we already have today's reputation systems in Lightning, namely the routing algorithms keeping track of the performance of the routing hops, and their liquidity.
I was under the impression that routing algorithms weren't part of the Lightning protocol spec (BOLTs)? Each Lightning implementation could ship with totally different default routing algorithms (perhaps already do?) and it wouldn't matter. There is no cross implementation compatibility issue with how each Lightning node selects channel counterparties, how it selects routes for payments and tracks which routes did and didn't work.
> On the third point, the protocol defer to the node operators all the decisions on the credential acquisition costs, expiration height, binding with liquidity units, or even allow additional routing policy checks.
I guess we're back into the world of setting defaults and options here that we've just been through with mempoolfullrbf :) If say a LDK user wants to opt into using this reputation system then that's their prerogative assuming it is merged into say a LDK release. Personally I would want to opt out of this reputation system and do my own assessments of reputations of Lightning nodes and risks I was taking. At least until a point when I was comfortable with it which I may never be.
> I hope you'll take time to browse the proposal as detailed more in depth here:https://github.com/lightning/bolts/pull/1043
Sure I'll take a look. But recall I am worried about edge cases and ways for an attacker to game a reputation system which requires me to get to your level of understanding of channel jamming attacks (which will take me a while given you've written a book [0] about them with Gleb). And I suspect even you and Gleb wouldn't be confident saying that you understand all the edge cases of jamming attacks let alone the edge cases of gaming a reputation layer on top.
As I said in my previous post I think this is an interesting area and I can see why you are exploring reputation. Just very skeptical that this is a thing that is ever part of the protocol, is used by all of the major Lightning implementations, is on by default in all those Lightning implementations etc. And even if it was I would want to opt out of it.
Thanks
Michael
[0]: https://jamming-dev.github.io/book/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, November 28th, 2022 at 23:34, Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi Michael,
>
> Thanks for the feedback,
>
> On the first point, I think it should be underscored how much this proposed credential system, while labeled a reputational one, belongs more to a monetary strategy (after the fact should be called "staking" credentials). Indeed, there is a direct link between the credentials and a cost expressed in satoshis. Therefore, in case of loopholes in the system damages are effectively borne by the routing hops, without throwing the whole system down. Note, the default policy should be some 0-risk HTLC forward acceptance.
>
> On the second point, we already have today's reputation systems in Lightning, namely the routing algorithms keeping track of the performance of the routing hops, and their liquidity. That information is used in a continuous fashion to improve payment-path building. And while those algorithms are doing probabilistic estimation of the balance distribution, the proposed credential system is not all relying on past statistics for its effectiveness (as long as the node operators are requiring credentials of worthiness equivalent to routing fees).
>
> On the third point, the protocol defer to the node operators all the decisions on the credential acquisition costs, expiration height, binding with liquidity units, or even allow additional routing policy checks. Flexibility is offered to the node operators, without the protocol developers trying to do any "centralized" decision on the cost of the credentials or whatever.
>
> From my understanding, the critics you're raising, while potentially correct for the reputation systems links you're including, does not bind to any concrete point of my proposal. I hope you'll take time to browse the proposal as detailed more in depth here: https://github.com/lightning/bolts/pull/1043
>
> Best,
> Antoine
>
> Le sam. 26 nov. 2022 à 05:53, Michael Folkson <michaelfolkson at protonmail.com> a écrit :
>
>> Hi Antoine
>>
>> I've got a lot to catch up on re channel jamming but just to say I'm deeply skeptical about attempting to embed a reputation layer or reputation credentials into the Lightning protocol. Admittedly I'm somewhat of a curious amateur in the field of reputation systems but a number of people (me included) have had to look into reputation systems in the past for projects/startups they were working on and centralized reputation systems are absolute minefields to manage effectively though some corporations do manage it. Decentralized reputation systems baked into a protocol is just a step too far. All you need is one edge case where the attacker can ensure an innocent party is blamed and the reputation system falls apart. The protocol developer is in the position of assessing who is telling the truth out of two opposing viewpoints on Reddit etc.
>>
>> I do think reputation systems will play a key part in a future Lightning Network (to some extent they already are with sites like 1ML and Amboss) but they won't be managed by protocol devs, they will be managed by multiple flavors of companies and projects (hopefully open source but most likely closed source too, for profit, non-profit etc) who are free to use whatever metrics and weigh those metrics however they like. The protocol just can't afford to expand into areas where there is case by case judgment and statistical analysis required. It will become bloated, ineffective and put protocol developers in the position of deciding who ultimately receives routing fees rather than just enabling payments can get from A to B. Identity is easier, you either control a private key or you don't. Reputation is much more difficult, there will be some attacks where a probabilistic assessment will need to be made on who the perpetrator of the attack was. You don't add that to the (already long) list of protocol developers' responsibilities.
>>
>> So feel free to continue to explore reputation and reputation systems but a strong warning that this is likely not solved at the protocol level. Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others. I've included some links to some additional reading on reputation systems in case you are interested.
>>
>> Thanks
>> Michael
>>
>> [0]: https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
>> [1]: https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
>> [2]: https://www.bitrated.com/faq
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Monday, November 21st, 2022 at 06:01, Antoine Riard <antoine.riard at gmail.com> wrote:
>>
>>> Hi LN Devs,
>>>
>>> tl;dr A formalization of a reputation-based scheme to solve channel jamming is proposed. The system relies on "credentials" issued by routing hops and requested to be attached to each HTLC forward request. The "credentials" can be used by a reputation algorithm to reward/punish payment senders and allocate channel liquidity resources efficiently. The "credentials" initial distribution can be bootstrapped leveraging one-time upfront fees paid toward the routing hops. Afterwards, the "credentials" subsequent distribution can rely on previous HTLC traffic.
>>>
>>> A protocol description can be found here, with few extensions already to the BOLTs:
>>>
>>> https://github.com/lightning/bolts/pull/1043
>>>
>>> There is also a work-in-progress proof-of-concept in LDK (on top of our coming soon^TM HTLC intercepting API):
>>>
>>> https://github.com/lightningdevkit/rust-lightning/pull/1848
>>>
>>> This work builds on previous reputation-scheme research [0] [1]. It also integrates the more recent proposals of upfront fees as a straightforward mechanism to bootstrap the reputation system. Bootstrapping the system with more economically cost-effective privacy-preserving UTXO ownership proofs not only add another layer of engineering complexity, there is still a proof size vs proof generation/validation trade-off to arbiter between ZKP cryptosystems.
>>>
>>> Rather to seek for a game-theory equilibrium defined as a breakeven point as in the latest unconditional fee research [2], this proposal aims to use reputation credentials to allow HTLC traffic-shaping. This not only should protect against jamming situations (either malicious
>>> or spontaneous) but also allow active HTLC traffic-shaping, where a routing hop can allow extended channel liquidity lockups based on accumulated reputation (e.g for hold-invoices). This is also a reduced overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC forward behavior can be qualified as "whitewashing" from the routing hop viewpoint.
>>>
>>> It should be noted, this current reputation-credential architectural framework assumes credentials distribution at the endpoint of the network. However, the framework should be flexible enough for the credentials to be harvested by the LSPs, and then distributed in a secondary fashion to their spokes, when they need it, or even attached transparently thanks to trampoline. So one design intuition, there is no strong attachment of the reputation to the endpoint HTLC sender, even if the protocol is described in a "flat" view for now.
>>>
>>> Let's evaluate quickly this mitigation proposal against a few criterias emerged from recent research.
>>>
>>> The mitigation is effective, in the sense a routing hop can apply a proportional relationship between the acquisition of the reputation and the amount of liquidity resources credited in function of said reputation. In a period of steady state, the reputation acquisition cost can be downgraded to 0. In periods of channel congestion, the reputation credentials to liquidity units translation can be severed, in the limit of routing hop acceptable competitiveness.
>>>
>>> The mitigation is incentive-compatible, if the credentials are not honored by their issuers, the HTLC senders can evict them from the routing network view for a while. The successful usage of credentials can lead to more credentials allocated for longer and more capacity-intensive channel lockups. In case of HTLC failure, the failure source could be forgiven by routing hops to maintain the worthiness of the sender credentials.
>>>
>>> The mitigation can be made transparent from the user, as the credentials harvesting can be done automatically from a pre-allocated budget, similar to the fee-bumping reserves requirement introduced by anchor output. At the end of today, if we take modern browsers as an example, the average user doesn't check manually the TLS certificates (for what they're worth...).
>>>
>>> The mitigation can conserve high-level privacy, as the usage of blinded signature (or another equivalent cryptosystem breaking signature/message linking) should allow the credentials issued during a preliminary phase to be undistinguishable during the redeem/usage phase. New CPU/memory DoS vectors due to the credentials processing should be watched out.
>>>
>>> About the ease of implementation, there are few protocol messages to modify, a HTLC intercepting API is assumed as supported by the implementation, onion messages support is also implied, landing EC blinded signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms adaptations might be more serious but still reasonable. The "credentials-to-liquidity" allocation algorithms are likely the new real beast, though I don't think any reputation scheme can spare them.
>>>
>>> There could be a concern about the centralization inertia introduced by a reputation system. Intuitively, the argument can be made that any historical tracking (such as routing buckets) favor established LN incumbents at the gain of efficiency. A counter-argument can be made, a new routing hop can lower the acquisition cost of its issued credentials to attract more HTLC traffic (accepting higher jamming risk).
>>>
>>> On the ecosystem impacts, it should be studied that this proposal would impact things like inbound channel routing fees [3], ratecard [4] or flow-control valve [5] and the whole liquidity toolchain. Hopefully, we don't significantly restrain the design space for future LN protocol upgrades.
>>>
>>> On the proposal modularity and flexibility, each routing node has oversight on its routing policy, acquisition methods, credentials to liquidity rate. New acquisition methods can be experimented or deployed when ready, e.g stakes certificates with only e2e upgrade. The credentials themselves could have "innate" expiration time if we use things like short-lived ZKP [6]. The credentials framework can be extended beyond solving jamming, as a generalized risk-management framework for Bitcoin decentralized financial network, e.g transaction signature exchange ordering in multi-party transactions [7] or finding reliable Coinjoin counterparties.
>>>
>>> Feedback welcome.
>>>
>>> Cheers,
>>> Antoine
>>>
>>> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
>>> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
>>> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
>>> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
>>> [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
>>> [5] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
>>> [6] https://eprint.iacr.org/2022/190.pdf
>>> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221129/31453b05/attachment-0001.html>

2023-06-09 13:07:27

- reply

📅 Original date posted:2022-11-26
📝 Original message:
Hi Antoine
I've got a lot to catch up on re channel jamming but just to say I'm deeply skeptical about attempting to embed a reputation layer or reputation credentials into the Lightning protocol. Admittedly I'm somewhat of a curious amateur in the field of reputation systems but a number of people (me included) have had to look into reputation systems in the past for projects/startups they were working on and centralized reputation systems are absolute minefields to manage effectively though some corporations do manage it. Decentralized reputation systems baked into a protocol is just a step too far. All you need is one edge case where the attacker can ensure an innocent party is blamed and the reputation system falls apart. The protocol developer is in the position of assessing who is telling the truth out of two opposing viewpoints on Reddit etc.
I do think reputation systems will play a key part in a future Lightning Network (to some extent they already are with sites like 1ML and Amboss) but they won't be managed by protocol devs, they will be managed by multiple flavors of companies and projects (hopefully open source but most likely closed source too, for profit, non-profit etc) who are free to use whatever metrics and weigh those metrics however they like. The protocol just can't afford to expand into areas where there is case by case judgment and statistical analysis required. It will become bloated, ineffective and put protocol developers in the position of deciding who ultimately receives routing fees rather than just enabling payments can get from A to B. Identity is easier, you either control a private key or you don't. Reputation is much more difficult, there will be some attacks where a probabilistic assessment will need to be made on who the perpetrator of the attack was. You don't add that to the (already long) list of protocol developers' responsibilities.
So feel free to continue to explore reputation and reputation systems but a strong warning that this is likely not solved at the protocol level. Decisions protocol developers make will impact what data can be collected and how easy that data is to collect (there are already some tricky trade-offs with regards to privacy, routing success and transparency for when things go wrong) but beyond that protocol developers should leave it to others. I've included some links to some additional reading on reputation systems in case you are interested.
Thanks
Michael
[0]: https://www.amazon.com/Building-Reputation-Systems-Randy-Farmer/dp/059615979X/
[1]: https://medium.com/openbazaarproject/decentralized-reputation-in-openbazaar-1a577fac5175
[2]: https://www.bitrated.com/faq
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, November 21st, 2022 at 06:01, Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi LN Devs,
>
> tl;dr A formalization of a reputation-based scheme to solve channel jamming is proposed. The system relies on "credentials" issued by routing hops and requested to be attached to each HTLC forward request. The "credentials" can be used by a reputation algorithm to reward/punish payment senders and allocate channel liquidity resources efficiently. The "credentials" initial distribution can be bootstrapped leveraging one-time upfront fees paid toward the routing hops. Afterwards, the "credentials" subsequent distribution can rely on previous HTLC traffic.
>
> A protocol description can be found here, with few extensions already to the BOLTs:
>
> https://github.com/lightning/bolts/pull/1043
>
> There is also a work-in-progress proof-of-concept in LDK (on top of our coming soon^TM HTLC intercepting API):
>
> https://github.com/lightningdevkit/rust-lightning/pull/1848
>
> This work builds on previous reputation-scheme research [0] [1]. It also integrates the more recent proposals of upfront fees as a straightforward mechanism to bootstrap the reputation system. Bootstrapping the system with more economically cost-effective privacy-preserving UTXO ownership proofs not only add another layer of engineering complexity, there is still a proof size vs proof generation/validation trade-off to arbiter between ZKP cryptosystems.
>
> Rather to seek for a game-theory equilibrium defined as a breakeven point as in the latest unconditional fee research [2], this proposal aims to use reputation credentials to allow HTLC traffic-shaping. This not only should protect against jamming situations (either malicious
> or spontaneous) but also allow active HTLC traffic-shaping, where a routing hop can allow extended channel liquidity lockups based on accumulated reputation (e.g for hold-invoices). This is also a reduced overhead cost, as upfront fees are only paid at bootstrap, or when the HTLC forward behavior can be qualified as "whitewashing" from the routing hop viewpoint.
>
> It should be noted, this current reputation-credential architectural framework assumes credentials distribution at the endpoint of the network. However, the framework should be flexible enough for the credentials to be harvested by the LSPs, and then distributed in a secondary fashion to their spokes, when they need it, or even attached transparently thanks to trampoline. So one design intuition, there is no strong attachment of the reputation to the endpoint HTLC sender, even if the protocol is described in a "flat" view for now.
>
> Let's evaluate quickly this mitigation proposal against a few criterias emerged from recent research.
>
> The mitigation is effective, in the sense a routing hop can apply a proportional relationship between the acquisition of the reputation and the amount of liquidity resources credited in function of said reputation. In a period of steady state, the reputation acquisition cost can be downgraded to 0. In periods of channel congestion, the reputation credentials to liquidity units translation can be severed, in the limit of routing hop acceptable competitiveness.
>
> The mitigation is incentive-compatible, if the credentials are not honored by their issuers, the HTLC senders can evict them from the routing network view for a while. The successful usage of credentials can lead to more credentials allocated for longer and more capacity-intensive channel lockups. In case of HTLC failure, the failure source could be forgiven by routing hops to maintain the worthiness of the sender credentials.
>
> The mitigation can be made transparent from the user, as the credentials harvesting can be done automatically from a pre-allocated budget, similar to the fee-bumping reserves requirement introduced by anchor output. At the end of today, if we take modern browsers as an example, the average user doesn't check manually the TLS certificates (for what they're worth...).
>
> The mitigation can conserve high-level privacy, as the usage of blinded signature (or another equivalent cryptosystem breaking signature/message linking) should allow the credentials issued during a preliminary phase to be undistinguishable during the redeem/usage phase. New CPU/memory DoS vectors due to the credentials processing should be watched out.
>
> About the ease of implementation, there are few protocol messages to modify, a HTLC intercepting API is assumed as supported by the implementation, onion messages support is also implied, landing EC blinded signature in libsecp256k1-zkp shouldn't be a big deal, routing algorithms adaptations might be more serious but still reasonable. The "credentials-to-liquidity" allocation algorithms are likely the new real beast, though I don't think any reputation scheme can spare them.
>
> There could be a concern about the centralization inertia introduced by a reputation system. Intuitively, the argument can be made that any historical tracking (such as routing buckets) favor established LN incumbents at the gain of efficiency. A counter-argument can be made, a new routing hop can lower the acquisition cost of its issued credentials to attract more HTLC traffic (accepting higher jamming risk).
>
> On the ecosystem impacts, it should be studied that this proposal would impact things like inbound channel routing fees [3], ratecard [4] or flow-control valve [5] and the whole liquidity toolchain. Hopefully, we don't significantly restrain the design space for future LN protocol upgrades.
>
> On the proposal modularity and flexibility, each routing node has oversight on its routing policy, acquisition methods, credentials to liquidity rate. New acquisition methods can be experimented or deployed when ready, e.g stakes certificates with only e2e upgrade. The credentials themselves could have "innate" expiration time if we use things like short-lived ZKP [6]. The credentials framework can be extended beyond solving jamming, as a generalized risk-management framework for Bitcoin decentralized financial network, e.g transaction signature exchange ordering in multi-party transactions [7] or finding reliable Coinjoin counterparties.
>
> Feedback welcome.
>
> Cheers,
> Antoine
>
> [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html
> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
> [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003685.html
> [5] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-September/003686.html
> [6] https://eprint.iacr.org/2022/190.pdf
> [7] https://github.com/lightning/bolts/pull/851#issuecomment-1290727242
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221126/0a8f484f/attachment-0001.html>

2023-06-09 13:06:30

- reply

📅 Original date posted:2022-06-30
📝 Original message:
Awesome, thanks Alex. Just one follow up.
> Running the numbers, I currently see 15,761 public nodes on the network and 148,295 half channels. Those each need refreshed gossip every two weeks. By default that would result in 90% channel updates.
And the rationale for each channel needing refreshed gossip every 2 weeks is to inform the network that the channel is still active (i.e. not disabled) and its parameters haven't changed?
(I did look it up in BOLT 7 [0] but it wasn't clear to me that a channel would be assumed to be inactive/disabled if there wasn't a channel_update for 2 weeks.)
That seems a lot of gossip to me if the recommended behavior of routing nodes is to maintain ~100 percent uptime and only when absolutely necessary change the parameters of the channel. I guess the alternative of significantly less gossip messages and a potential uptick in failed routes would be worse though.
[0]: https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#rationale-4
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, June 29th, 2022 at 7:07 PM, Alex Myers <alex at endothermic.dev> wrote:
> Hi Michael,
>
> Thanks for the transcript and the questions, especially those you asked in Gleb's original Erlay presentation.
>
> I tried to cover a lot of ground in only 30 minutes and the finer points may have suffered. The most significant difference in concern between bitcoin transaction relay and lightning gossip may be one of privacy: Source nodes of Bitcoin transactions have an interest in privacy (avoid trivially triangulating the source.) Lightning gossip is already signed by and linked to a node ID - the source is completely transparent by nature. The lack of a timing concern would allow for a global sketch where it would have been infeasible for Erlay (among other reasons such as DoS.)
>
>> Why are hash collisions a concern for Lightning gossip and not for Erlay? Is it not a DoS vector for both?
>
> If lightning gossip were encoded for minisketch entries with the short_channel_id, it would create a unique fingerprint by default thanks to referencing the unique funding transaction on chain - no hashing required. This was Rusty's original concept and what I had been proceeding with. However, given the ongoing privacy discussion and desire to eventually decouple lightning channels from their layer one funding transaction (gossip v2), I think we should prepare for a future in which channels are not explicitly linked to a SCID. That means hashing just as in Erlay and the same DoS vector would be present. Salting with a per-peer shared secret works here, but the solution is driven back toward inventory sets.
>
>> It seems you are leaning towards per-peer sketches with inventory sets (like Erlay) rather than global sketches.
>
>
> Yes. There are pros and cons to each method, but most critically, this would be compatible with eventual removal of the SCID.
>
>> Erlay falls back to flooding if the set reconciliation algorithm doesn't work which I'm assuming you'll do with Lightning gossip.
>
> Fallback will take some consideration (Erlay's bisect is an elegant feature), but yes, flooding is still the ultimate fallback.
>
>> I was also surprised to hear that channel_update made up 97 percent of gossip messages. Isn't it recommended that you don't make too changes to your channel as it is likely to result in failed routed payments and being dropped as a routing node for future payments? It seems that this advice isn't being followed if there are so many channel_update messages being sent around. I almost wonder if Lightning implementations should include user prompts like "Are you sure you want to update your channel given this may affect your routing success?" :)
>
> Running the numbers, I currently see 15,761 public nodes on the network and 148,295 half channels. Those each need refreshed gossip every two weeks. By default that would result in 90% channel updates. That we're seeing roughly three times as many channel updates vs node announcements compared to what's strictly required is maybe not that surprising. I agree, there would be a benefit to nodes taking a more active role in tracking calls to broadcast gossip.
>
> Thanks,
> Alex
>
> ------- Original Message -------
> On Wednesday, June 29th, 2022 at 6:09 AM, Michael Folkson <michaelfolkson at protonmail.com> wrote:
>
>> Thanks for this Alex.
>>
>> Here's a transcript of your recent presentation at Bitcoin++ on Minisketch and Lightning gossip:
>>
>> https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/
>>
>> Having followed Gleb's work on using Minisketch for Erlay in Bitcoin Core [0] for a while now I was especially interested in how the challenges of using Minisketch for Lightning gossip (node_announcement, channel_announcement, channel_update messages) would differ to the challenges of using Minisketch for transaction relay on the base layer.
>>
>> I guess one of the major differences is full nodes are trying to verify a block every 10 minutes (on average) and so there is a sense of urgency to get the transactions of the next block to be mined. With Lightning gossip unless you are planning to send a payment (or route a payment) across a certain route you are less concerned about learning about the current state of the network urgently. If a new channel pops up you might choose not to route through it regardless given its "newness" and its lack of track record of successfully routing payments. There are parts of the network you care less about (if they can't help you get to your regular destinations say) whereas with transaction relay you have to care about all transactions (paying a sufficient fee rate).
>>
>> "The problem that Bitcoin faced with transaction relay was pretty similar but there are a few differences.For one, any time you introduce that short hash function that produces a 64 bit fingerprint you have to be concerned with collisions between hash functions. Someone could potentially take advantage of that and grind out a hash that would resolve to the same fingerprint."
>>
>> Could you elaborate on this? Why are hash collisions a concern for Lightning gossip and not for Erlay? Is it not a DoS vector for both?
>>
>> It seems you are leaning towards per-peer sketches with inventory sets (like Erlay) rather than global sketches. This makes sense to me and seems to be moving in a direction where your peer connections are more stable as you are storing data on what your peer's understanding of the network is. There could even be centralized APIs which allow you to compare your current understanding of the network to the centralized service's understanding. (Of course we don't want to have to rely on centralized services or bake them into the protocol if you don't want to use them.) Erlay falls back to flooding if the set reconciliation algorithm doesn't work which I'm assuming you'll do with Lightning gossip.
>>
>> I was also surprised to hear that channel_update made up 97 percent of gossip messages. Isn't it recommended that you don't make too changes to your channel as it is likely to result in failed routed payments and being dropped as a routing node for future payments? It seems that this advice isn't being followed if there are so many channel_update messages being sent around. I almost wonder if Lightning implementations should include user prompts like "Are you sure you want to update your channel given this may affect your routing success?" :)
>>
>> Thanks
>> Michael
>>
>> P.S. Are we referring to "routing nodes" as "forwarding nodes" now? I've noticed "forwarding nodes" being used more recently on this list.
>>
>> [0]: https://github.com/bitcoin/bitcoin/pull/21515
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Thursday, April 14th, 2022 at 22:00, Alex Myers <alex at endothermic.dev> wrote:
>>
>>> Hello lightning developers,
>>>
>>> I’ve been investigating set reconciliation as a means to reduce bandwidth and redundancy of gossip message propagation. This builds on some earlier work from Rusty using the minisketch library [1]. The idea is that each node will build a sketch representing it’s own gossip set. Alice’s node will encode and transmit this sketch to Bob’s node, where it will be merged with his own sketch, and the differences produced. These differences should ideally be exactly the latest missing gossip of both nodes. Due to size constraints, the set differences will necessarily be encoded, but Bob’s node will be able to identify which gossip Alice is missing, and may then transmit exactly those messages.
>>>
>>> This process is relatively straightforward, with the caveat that the sets must otherwise match very closely (each sketch has a maximum capacity for differences.) The difficulty here is that each node and lightning implementation may have its own rules for gossip acceptance and propagation. Depending on their gossip partners, not all gossip may propagate to the entire network.
>>>
>>> Core-lightning implements rate limiting for incoming channel updates and node announcements. The default rate limit is 1 per day, with a burst of 4. I analyzed my node’s gossip over a 14 day period, and found that, of all publicly broadcasting half-channels, 18% of them fell afoul of our spam-limiting rules at least once. [2]
>>>
>>> Picking several offending channel ids, and digging further, the majority of these appear to be flapping due to Tor or otherwise intermittent connections. Well connected nodes may be more susceptible to this due to more frequent routing attempts, and failures resulting in a returned channel update (which otherwise might not have been broadcast.)A slight relaxation of the rate limit resolves the majority of these cases.
>>>
>>> A smaller subset of channels broadcast frequent channel updates with minor adjustments to htlc_maximum_msat and fee_proportional_millionths parameters. These nodes appear to be power users, with many channels and large balances. I assume this is automated channel management at work.
>>>
>>> Core-Lightning has updated rate-limiting in the upcoming release to achieve a higher acceptance of incoming gossip, however, it seems that a broader discussion of rate limits may now be worthwhile. A few immediate ideas:
>>>
>>> - A common listing of current default rate limits across lightning network implementations.
>>>
>>> - Internal checks of RPC input to limit or warn of network propagation issues if certain rates are exceeded.
>>>
>>> - A commonly adopted rate-limit standard.
>>>
>>> My aim is a set reconciliation gossip type, which will use a common, simple heuristic to accept or reject a gossip message. (Think one channel update per block, or perhaps one per block_height << 5.) See my github for my current draft. [3] This solution allows tighter consensus, yet suffers from the same problem as original anti-spam measures – it remains somewhat arbitrary. I would like to start a conversation regarding gossip propagation, channel_update and node_announcement usage, and perhaps even bandwidth goals for syncing gossip in the future (how about a million channels?) This would aid in the development of gossip set reconciliation, but could also benefit current node connection and routing reliability more generally.
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>> [1] https://github.com/sipa/minisketch
>>>
>>> [2] https://github.com/endothermicdev/lnspammityspam/blob/main/sampleoutput.txt
>>>
>>> [3] https://github.com/endothermicdev/lightning-rfc/blob/gossip-minisketch/07-routing-gossip.md#set-reconciliation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220630/2603e096/attachment-0001.html>

2023-06-09 13:06:29

- reply

📅 Original date posted:2022-06-29
📝 Original message:
Thanks for this Alex.
Here's a transcript of your recent presentation at Bitcoin++ on Minisketch and Lightning gossip:
https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/
Having followed Gleb's work on using Minisketch for Erlay in Bitcoin Core [0] for a while now I was especially interested in how the challenges of using Minisketch for Lightning gossip (node_announcement, channel_announcement, channel_update messages) would differ to the challenges of using Minisketch for transaction relay on the base layer.
I guess one of the major differences is full nodes are trying to verify a block every 10 minutes (on average) and so there is a sense of urgency to get the transactions of the next block to be mined. With Lightning gossip unless you are planning to send a payment (or route a payment) across a certain route you are less concerned about learning about the current state of the network urgently. If a new channel pops up you might choose not to route through it regardless given its "newness" and its lack of track record of successfully routing payments. There are parts of the network you care less about (if they can't help you get to your regular destinations say) whereas with transaction relay you have to care about all transactions (paying a sufficient fee rate).
"The problem that Bitcoin faced with transaction relay was pretty similar but there are a few differences.For one, any time you introduce that short hash function that produces a 64 bit fingerprint you have to be concerned with collisions between hash functions. Someone could potentially take advantage of that and grind out a hash that would resolve to the same fingerprint."
Could you elaborate on this? Why are hash collisions a concern for Lightning gossip and not for Erlay? Is it not a DoS vector for both?
It seems you are leaning towards per-peer sketches with inventory sets (like Erlay) rather than global sketches. This makes sense to me and seems to be moving in a direction where your peer connections are more stable as you are storing data on what your peer's understanding of the network is. There could even be centralized APIs which allow you to compare your current understanding of the network to the centralized service's understanding. (Of course we don't want to have to rely on centralized services or bake them into the protocol if you don't want to use them.) Erlay falls back to flooding if the set reconciliation algorithm doesn't work which I'm assuming you'll do with Lightning gossip.
I was also surprised to hear that channel_update made up 97 percent of gossip messages. Isn't it recommended that you don't make too changes to your channel as it is likely to result in failed routed payments and being dropped as a routing node for future payments? It seems that this advice isn't being followed if there are so many channel_update messages being sent around. I almost wonder if Lightning implementations should include user prompts like "Are you sure you want to update your channel given this may affect your routing success?" :)
Thanks
Michael
P.S. Are we referring to "routing nodes" as "forwarding nodes" now? I've noticed "forwarding nodes" being used more recently on this list.
[0]: https://github.com/bitcoin/bitcoin/pull/21515
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Thursday, April 14th, 2022 at 22:00, Alex Myers <alex at endothermic.dev> wrote:
> Hello lightning developers,
>
> I’ve been investigating set reconciliation as a means to reduce bandwidth and redundancy of gossip message propagation. This builds on some earlier work from Rusty using the minisketch library [1]. The idea is that each node will build a sketch representing it’s own gossip set. Alice’s node will encode and transmit this sketch to Bob’s node, where it will be merged with his own sketch, and the differences produced. These differences should ideally be exactly the latest missing gossip of both nodes. Due to size constraints, the set differences will necessarily be encoded, but Bob’s node will be able to identify which gossip Alice is missing, and may then transmit exactly those messages.
>
> This process is relatively straightforward, with the caveat that the sets must otherwise match very closely (each sketch has a maximum capacity for differences.) The difficulty here is that each node and lightning implementation may have its own rules for gossip acceptance and propagation. Depending on their gossip partners, not all gossip may propagate to the entire network.
>
> Core-lightning implements rate limiting for incoming channel updates and node announcements. The default rate limit is 1 per day, with a burst of 4. I analyzed my node’s gossip over a 14 day period, and found that, of all publicly broadcasting half-channels, 18% of them fell afoul of our spam-limiting rules at least once. [2]
>
> Picking several offending channel ids, and digging further, the majority of these appear to be flapping due to Tor or otherwise intermittent connections. Well connected nodes may be more susceptible to this due to more frequent routing attempts, and failures resulting in a returned channel update (which otherwise might not have been broadcast.)A slight relaxation of the rate limit resolves the majority of these cases.
>
> A smaller subset of channels broadcast frequent channel updates with minor adjustments to htlc_maximum_msat and fee_proportional_millionths parameters. These nodes appear to be power users, with many channels and large balances. I assume this is automated channel management at work.
>
> Core-Lightning has updated rate-limiting in the upcoming release to achieve a higher acceptance of incoming gossip, however, it seems that a broader discussion of rate limits may now be worthwhile. A few immediate ideas:
>
> - A common listing of current default rate limits across lightning network implementations.
>
> - Internal checks of RPC input to limit or warn of network propagation issues if certain rates are exceeded.
>
> - A commonly adopted rate-limit standard.
>
> My aim is a set reconciliation gossip type, which will use a common, simple heuristic to accept or reject a gossip message. (Think one channel update per block, or perhaps one per block_height << 5.) See my github for my current draft. [3] This solution allows tighter consensus, yet suffers from the same problem as original anti-spam measures – it remains somewhat arbitrary. I would like to start a conversation regarding gossip propagation, channel_update and node_announcement usage, and perhaps even bandwidth goals for syncing gossip in the future (how about a million channels?) This would aid in the development of gossip set reconciliation, but could also benefit current node connection and routing reliability more generally.
>
> Thanks,
>
> Alex
>
> [1] https://github.com/sipa/minisketch
>
> [2] https://github.com/endothermicdev/lnspammityspam/blob/main/sampleoutput.txt
>
> [3] https://github.com/endothermicdev/lightning-rfc/blob/gossip-minisketch/07-routing-gossip.md#set-reconciliation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/bbffa050/attachment-0001.html>

2023-06-09 13:06:24

- reply

📅 Original date posted:2022-06-28
📝 Original message:
Hey ZmnSCPxj
It is an interesting topic. Alex Bosworth did a presentation at the Lightning Hack Day last year with a similar attempt at categorizing the different strategies for a routing/forwarding node (Ping Pong, Liquidity Battery, Inbound Sourcing, Liquidity Trader, Last Mile, Swap etc)
https://btctranscripts.com/lightning-hack-day/2021-03-27-alex-bosworth-lightning-routing/
It seems like your attempt is a little more granular and unstructured (based on individual responses) but perhaps it fits into the broad categories Alex suggested maybe with some additional ones?
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Tuesday, June 28th, 2022 at 03:34, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> This is a short (relative to my typical crap) writeup on some strategies that Lightning forwarding nodes might utilize.
>
> I have been thinking of various strategies that actual node operators (as I understood from discussing with a few of them) use:
>
> * Passive rebalance / feerate by balance
> * Set feerates according to balance: increase feerates when our side has low balance, reduce feerates when our side has high balance.
> * "passive rebalance" because we are basically encouraging payments via our channel if the balance is in our favor, and discouraging payments if the balance is against us, thus typical payments will "normally" rebalance our node naturally without us spending anything.
> * Low fee
> * Just fix the fee to a low fee, e.g. base 1 proportional 1 or even the @zerofeerouting guy of base 0 proportional 0.
> * Ridiculously simple, no active management, no scripts, no nothing.
> * Wall
> * Set to a constant (or mostly constant) high feerate.
> * Actively rebalance, targeting low-fee routes (i.e. less than our earnings), and constantly probe the network for the rare low-fee routes that we can use to rebalance.
> * Basically, buy cheap liquidity and resell it at higher prices.
>
>
> The interesting thing is how the three interact.
>
> Suppose we have a mixed network composed ONLY of passive rebalancers and walls.
> In that case, the passive rebalancers might occasionally set channels to low fees, in which case the walls buy up their liquidity, but eventually the liquidity of the passive rebalancer is purchased and the passive rebalancer raises their price point.
> The network then settles with every forwarding node having roughly equal balance on their channels, but note that it was the walls who paid to the passive rebalancers to get the channels into a nice balance.
> In particular, if there were only a single wall node, it can stop rebalancing once the price to rebalance costs more than 49% of its earnings, so it paid 49% of its earnings to the passive rebalancers and keeps 51% of its earnings, thus earning more than the passive rebalancers earn.
> However, once multiple wall nodes exist, they will start bidding for the available liquidity from the passive rebalancers and the may find it difficult to compete once the passive rebalancers set their feerates to more than 50% of the wall feerate, at which point the passive rebalancers now end up earning more than the wall nodes (because the wall nodes now pay more to the passive rebalancers than what they keep).
>
> Thus, it seems to me that passive rebalancers would outcompete wall strategies, if they were the only strategies on the network.
>
> However, the network as-is contains a LOT of tiny nodes with low feerates.
>
> In such an environment, walls can pick up liquidity for really, really cheap, leaving the low-feerate nodes with no liquidity in the correct direction.
> And thus, it seems plausible that they can resell the liquidity later at much higher feerates, possibly outcompeting the passive rebalancers.
>
> Unfortunately:
>
> * Low feerate nodes are notoriously unreliable for payments; their channels are usually saturated in one side or another. since walls keep taking their liquidity.
> * Because of this known unreliability, some payer strategies filter them out via some heuristics (e.g. payment unreliability information).
> Thus, even in the rare case where payment flows change on the network, they are not used by payers --- instead, walls exploit them since walls do not care if rebalancing fails, they will always just retry later.
> * One argument FOR using low-feerate nodes is that it "supports the network".
> * However, it seems to me that the low-feerate nodes are actually being exploited by the wall nodes instead, and the low-feerate nodes have too little payment reliability to actually support payers instead of large-scale forwarders.
> * Both low-feerates and walls do not leak their channel balances, whereas passive rebalancers do leak their channel balance.
>
> The above is just some thinking of mine --- actual experimentation on models or on actual network nodes might be better than my speculation.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 13:06:14

- reply

📅 Original date posted:2022-06-21
📝 Original message:
Thanks for the summary Laolu, very informative.
> One other cool topic that came up is the concept of leveraging recursive musig2 (so musig2 within musig2) to make channels even _more_ multi-sigy.
A minor point but terminology can get frustratingly sticky if it isn't agreed on early. Can we refer to it as nested MuSig2 going forward rather than recursive MuSig2? It is a more accurate description in my opinion and going through some old transcripts the MuSig2 authors [0] also refer it to nested MuSig2 (as far as I can make out).
Rene Pickhardt brought up the issue of latency with regards to nested/recursive MuSig2 (or nested FROST for threshold) on Bitcoin StackExchange [1]. Was this discussed at the LN Summit? I don't know how all the Lightning implementations treat latency currently (how long a channel counterparty has to provide a needed signature before moving to a unhappy path) but Rene's concern is delays in the regular completions of a nested MuSig2 or FROST scheme could make them unviable for the Lightning channel use case depending on the exact setup and physical location of signers etc.
MuSig2 obviously generates an aggregated Schnorr signature and so even nested MuSig2 require the Lightning protocol to recognize and verify Schnorr signatures which it currently doesn't right? So is the current thinking that Schnorr signatures will be supported first with a Schnorr 2-of-2 on the funding output (using OP_CHECKSIGADD and enabling the nested schemes) before potentially supporting non-nested MuSig2 between the channel counterparties on the funding output later? Or is this still in the process of being discussed?
[0]: https://btctranscripts.com/london-bitcoin-devs/2020-06-17-tim-ruffing-schnorr-multisig/
[1]: https://bitcoin.stackexchange.com/questions/114159/how-do-the-various-lightning-implementations-treat-latency-how-long-do-they-wai
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, June 8th, 2022 at 03:38, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
> Hi y'all,
>
> Last week nearly 30 (!) Lightning developers and researchers gathered in
> Oakland, California for three day to discuss a number of matters related to
> the current state and evolution of the protocol. This time around, we had
> much better representation for all the major Lightning Node implementations
> compared to the last LN Dev Summit (Zurich, Oct 2021).
>
> Similar to the prior LN Dev Summit, notes were kept throughout the day that
> attempted on a best effort basis to capture the relevant discussions,
> decisions, and new relevant research or follow up areas to circle back on.
> Last time around, I sent out an email that summarized some key takeaways
> (from my PoV) of the last multi-day dev summit [1]. What follows in this
> email is a similar summary/recap of the three day summit. Just like last
> time: if you attended and felt I missed out on a key point, or inadvertently
> misrepresented a statement/idea, please feel free to reply, correcting or
> adding additional detail.
>
> The meeting notes in full can be found here:
> https://docs.google.com/document/d/1KHocBjlvg-XOFH5oG_HwWdvNBIvQgxwAok3ZQ6bnCW0/edit?usp=sharing
>
> # Simple Taproot Channels
>
> During the last summit, Taproot was a major discussion topic as though the
> soft fork had been deployed, we we're all still watching the 🟩 's stack up
> on the road to ultimately activation. Fast forward several months later and
> Taproot has now been fully activated, with ecosystem starting to
> progressively deploy more and more advanced systems/applications that take
> advantage of the new features.
>
> One key deployment model that came out of the last LN Dev summit was the
> concept of an iterative roadmap that progressively revamped the system to
> use more taprooty features, instead of a "big bang" approach that would
> attempt to package up as many things as possible into one larger update. At
> a high level the iterative roadmap proposed that we unroll an existing
> larger proposal [2] into more bite sized pieces that can be incrementally
> reviewed, implemented, and ultimately deployed (see my post on the LN Dev
> Summit 2021 for more details).
>
> ## Extension BOLTs
>
> Riiight before we started on the first day, I wrote up a minimal proposal
> that attempted to tackle the first two items of the Taproot iterative
> deployment schedule (musig2 funding outputs and simple tapscript mapping)
> [3]. I called the proposal "Simple Taproot Channels" as it set out to do a
> mechanical mapping of the current commitment and script structure to a more
> taprooty domain. Rather than edit 4 or 5 different BOLTs with a series of
> "if this feature bit applies" nested clauses, I instead opted to create a
> new standalone "extension bolt" that defines _new_ behavior on top of the
> existing BOLTs, referring to the BOLTs when necessary. The style of the
> document was inspired by the "proposals" proposal (very meta), which was
> popularized by cdecker and adopted by t-bast with his documents on
> Trampoline and Blinded Paths.
>
> If the concept catches on, extension BOLTs provide us with a new way to
> extend the spec: rather than insert everything in-line, we could instead
> create new standalone documents for larger features. Having a single self
> contained document makes the proposal easier to review, and also gives the
> author more room to provide any background knowledge, primaries, and also
> rationale. Overtime, as the new extensions become widespread (eg: taproot is
> the default channel type), we can fold in the extensions back to the main
> set of "core" BOLTs (or make new ones as relevant).
>
> Smaller changes to the spec like deprecating an old field or tightening up
> some language will likely still follow the old approach of mutating the
> existing BOLTs, but larger overhauls like the planned PTLC update may find
> the extension BOLTs to be a better tool.
>
> ## Tapscript, Musig2, and Lightning
>
> As mentioned above the Simple Taproot Channels proposal does two main
> things:
> 1. Move the existing 2-of-2 p2wsh segwit v0 funding output to a _single
> key_ p2tr output, with the single key actually being an aggregated musig2
> key.
>
> 2. Map all our existing scripts to the tapscript domain, using the
> internal key (keyspend path) for things like revocations, which an
> potentially allow nodes to store less state for HTLCs.
>
> Of the two components #1 is by far the trickiest. Musig2 is a very elegant
> protocol (not to mention the spec which y'all should totally check out) but
> as the signatures aren't deterministic (like RFC 6979 [5]), both signers
> need to "protect themselves at all times" to ensure they don't ever re-use
> nonces, which can lead to a private key leak (!!).
>
> Rather than try to create some sort of psuedo-deterministic nonces scheme
> (which maaybe works until the Blockstream Research team squints vaguely in
> its direction), I opted to just make all nonces 100% ephemeral and tied to
> the lifetime of a connection. Musig2 defines something called a public
> nonces, which is actually two individual 33-byte nonces. This value needs to
> be exchanged before signing can begin (but can be sent before sides know
> they're aggregated keys). One important thing to note is that given that the
> channels today have _asymmetric_ state, we actually need a _pair_ of public
> nonces: one that I'll use to sign my commitment, and one I'll use to sign
> yours. Lightning channels w/ symmetric state like eltoo can get by w/ only
> exchange a single set of nonces, as there's only one message per state.
>
> Nonce exchange takes place in a few places:
>
> * During initial funding: I send my public nonce in the open_channel
> message, you send yours in the accept_channel message. After this
> exchange we can both generate signatures for the refund commitment
> transactions.
>
> * After the channel is "ready" we send another set of nonces, so we can
> sign the next state. This is similar to the existing revocation key
> exchange: I need your next nonce/key before I can sign a new state.
>
> * Upon channel re-establishment a _new_ set of nonces is sent, as they're
> 100% ephemeral. The current draft also requires that if you were
> re-transmitting a sig, then you use the _new_ nonces to sign again, as
> it's possible you went to retransmit but left off an expired/trimmed
> HLTC (could lead to nonce re-use and also needing to remember nonces).
>
> * Each time I revoke my channel, I send to you a single nonce, my "local
> nonce" (naming needs some work here), which lets you sign for a new
> state.
>
> * Each time I send a new sig, I also send you another nonce, my "remote"
> nonce", which
>
> * When I send a shutdown (co-op close) I send a single public nonce so we
> can sign the next co-opc close offer.
>
> * When I send a closing_signed I send another nonce so once you send your
> offer, we sign another set.
>
> The final flows aren't 100% yet finalized, as we'll need some
> implementations drafted to make sure the nonce handling and script mapping
> works out properly.
>
> ### Lightning Channels & Recursive Musig2
>
> One other cool topic that came up is the concept of leveraging recursive
> musig2 (so musig2 within musig2) to make channels even _more_ multi-sigy.
> The benefit here is that Bob & Carol can each have their individual keys
> (which might actually be aggregated keys themselves) and make a channel w/
> Alice, who only knows of them as Barol, and doesn't know there're actually
> another pair of keys at play. This is _really_ cool as it allows node
> operators, wallets, and lightning platforms to experiment with various
> key/signing trees that may add more security, redundancy, or flexibility.
>
> When this first came up, someone brought up the fact that while the scheme
> is "known" the initial paper as they weren't sure how to actually write a
> proof for it. During the session, someone emailed one of the musig2 authors
> asking for more details, and if it's safe to implement and roll out.
> Thankfully they quickly replied and explained that the proof recursive musig
> (pls someone correct me again here if I'm wrong) wasn't left out due to
> impossibility, but that a proof in the existing Random Oracle Model (which
> was used to derive a bound for the number of nonces needed) would lead to a
> blow up in the number of nonces required. Attempting to write the proof in
> some other model would likely lead to better results (proved w/ two nonces
> as base musig2), but would end up being pretty complicated, so hard to read
> and even review for correctness.
>
> Assuming everything checks out, then a useful mental model explained by the
> musig2 BIP author is a sort of tree structure. Assuming I'm a signer, and we
> assemble the other signer as a sibling leaf in a binary tree, then I just
> need to wait for the sibling nonce/key, before I can aggregate that into
> the final value. So if there're 3 signers, I wait for the regular public
> nonce, but the other signers sum their respective nonces into a single
> nonce, then send that to me. A similar operation is carried out for key
> aggregation, with the rest of the protocol being mostly the same.
>
> Ultimately, even if wallets/nodes aren't ready to roll something like this
> out today, we at least want to make sure the proposed flow is compatible
> with Simple Taproot Channels, and ideally we'd have a toy implementation to
> verify out understanding and show it's possible/sound. I volunteered to hack
> up a simple recursive musig2 demo, as there doesn't seem to be any code in
> the wild that implements it.
>
> ## Lightning Gossip
>
> # Gossip V2: Now Or Later?
>
> Another big topic related to Taproot was the question of how we should
> update the gossip network: the gossip protocol today has all channels
> validated by node, which requires that the nodes understand how to
> reconstruct the funding output based on the set of advertised keys. The
> protocol today assumes a segwit v0 p2wsh multi-sig is used. Assuming we had
> everything implemented today, a node wouldn't be able to advertise its new
> taproot channels to the rest of the public graph as they wouldn't understand
> how to validate it.
>
> This presents a new opportunity: we already need to rework gossip for
> taproot, so should we go ahead and re-design the entire thing with an eye
> for better privacy and future extensibility?
>
> A proposal for the "re-design the entire thing" was floated in the past by
> Rusty [6]. It does away with the strict coupling of channels to channel
> announcements, and instead moves them to the _node_ level. Each node would
> then advertise the set of "outputs" they have control of, which would then
> be mapped to the total capacity of a node, without requiring that these
> outputs self identify themselves on-chain as Lightning Channels. This also
> opens up the door to different, potentially more privacy preserving
> proofs-of-channel-ownership (something something zkp).
>
> On the other hand, we could just follow the path of Simple Taproot Channels
> and map musig2+schnorr onto the existing gossip network. This is less
> changes in total, with the main benefit being the ability to only send 1 sig
> (aggregated musig2 sig of keys) instead of 4 individual sigs. I made a very
> lofty proposal in this direction here [7].
>
> Ultimately we decided to take the "just musig2 aspects" from gossip v1.5
> (not the real name), and the "let's refresh all the messages w/ TLV
> goodness" from the gossip v2 proposal. This gives us a smaller package to
> implement, and lets us potentially rejigger the messages to be more
> extensible and remove cruft like the node color that almost nothing uses,
> but we all validate/store.
>
> The follow up work in this area is a more concrete proposal that updates the
> relevant gossip messages to be taproot aware and TLV'd and also update the
> set of requirements w.r.t _how_ to validate the channels in the first place
> (so given two keys verify that applying the keyagg method of musig2 lead to
> what' in the funding output).
>
> Gossip v2 will likely happen "eventually", but the rather large design space
> needs to be explored a bit more so we can properly analyze exactly what
> privacy and extensibility properties we'll get out of it.
>
> # Applying Mini Sketch to LN Gossip
>
> One issue we have today, is that other than the initial scid query mechanism
> added to the protocol, there isn't a great way to ensure you have all the
> latest updates your peer has. These days, many nodes pretty aggressively
> rate limit other nodes, so you might even have trouble sending out your
> update in the first place. A recent paper (that I haven't actually fully
> read yet) [8] analyzes the gossip network today to work out things like:
> exactly how long it takes things to propagate, total bandwidth usage, etc.
>
> Minisketch [9] (the grandchild of IBLTs ;)), is an efficient set
> reconciliation protocol that was designed for Bitcoin p2p mempool syncing,
> but can be applied to other protocols. An attendee has been working on
> brushing off some older work to try to see how we could apply it to the LN
> protocol to give nodes a more bandwidth efficient way to sync channel
> updates, and also achieve better update propagation. This supplements some
> existing investigative work done by Alex Meyers [10], with more concrete
> designs w.r.t: what goes into the sketch, and the various size parameters
> that need to be chosen.
>
> # Channel Jamming
>
> An attendee gave a talk on the various proposed solutions to channel
> jamming, evaluating them on several axis including: punishment/monetary,
> local vs global reputation, feasibility of mechanism design, UX
> implications, and implementation complexity. The presenter didn't present a
> new concrete proposal, but instead went through the various trade-offs,
> ultimately concluding that they factor monetary penalties wherein the funds
> are distributed across the route, rather than being provably burnt to
> miners. However they alluded to some future upcoming work that attempts a
> more rigorous analysis of the proposed solutions, their tradeoffs, and
> potential ways we can parametrize solutions to be more effective (how much
> should they pay, etc).
>
> For those looking to brush up on the latest state of research/mitigations in
> this area, I recommend this blog post by Bitmex research [11].
>
> # Onion Messages & DoS
>
> The topic of DoS concerns related to onion messages (in isolation, so not
> necessarily related to things like bolt12 that take advantage of them came
> up. During a white boarding session some argued that DoS isn't actually
> much of an issue, as nodes can leverage "back propagation congestion
> control" to inform the source (who may not actually be the sender) that
> they'll start to drop or limit their packets, with each node doing this
> iteratively until the actual source of the spam has been clamped. A few
> lofty designs were thrown around, but more work needs to be done to
> concretely specify something so it can be properly analyzed.
>
> On the other side of the spectrum, rather than attempt to rate limit at the
> node level (which each node having their own policy), nodes could opt
> instead to forward _anything_ as long as the sender pays them enough. I
> proposed a lofty approach that combined AMP and Onion Messages earlier this
> year [12]. At a high level I make an AMP payment, which pushes extra coins
> to all nodes on a route, and also drops off a special identifier to them.
> When I send an onion message I include this identifier, with each node
> performing their own account w.r.t the amount of bandwidth an ID has
> remaining.
>
> Ultimately a few implementations are pretty close to deploying their
> implementation of onion messages, so no matter the intended use case, it
> would be good to have code deployed along side to either rate limit or price
> resource consumption accordingly. Otherwise, we might end up in a scenario
> where DoS concerns were brushed aside, but end up being a huge issue later.
>
> # Blinded Paths, QR Codes & Invoices
>
> Blinded paths [13] is a new-er proposal to solve the "last mile" privacy
> issue when receiving payments on LN. Today invoices to unadvertised channels
> contain a set of hop hints, which are anchored at public nodes in the graph,
> and also leak the scid of the unadvertised channel (points on-chain to the
> channel receiving payments). A solution for the on-chain leak, SCID channel
> aliases [15] are in the process of being widely rolled out. Channel aliases
> instead use a random value in the invoice, allowing receiving nodes to break
> that on-chain link and even rotate out the value periodically. With the
> on-chain leak addressed, it's still the case that you give away your
> "position" in the network, since as a sender I know that you're connected to
> node N with a private channel.
>
> Blinded paths address this node-level last mile privacy leak by replacing
> hop hints with a new cryptographically blinded path. At a high level, the
> receiver can construct a "hop hint" of length greater than 1, gather the
> public keys of each of the nodes, then blinded them such that: the sender
> can use them for path finding, but doesn't actually now exactly _which_
> nodes they actually are.
>
> There're two type of blinded paths: those in onion messages and those used
> for actual payments. The latter variant was only formalized earlier this
> year, as before people were mainly interested in using them to fetch BOLT 12
> invoice via onion messages. One issue that pops up when attempting to use
> blinded paths for normal payments is: the size of the resulting invoice. As
> blinded paths are actually fragments of publicly known paths, as a receiver,
> you want to stuff as many of them into the invoice as possible, since they
> MUST be taken in order to route towards you. Invoices are typically
> communicated via QR codes, which have a hard limit w.r.t the amount of
> information that can be packed in. On the other hand for invoice fetching,
> all that matters is that a path exists, so you can get by with stuffing less
> of then in a QR code.
>
> As a result, blinded paths aren't necessarily compatible with the widely
> deployed BOLT 11 based QR codes. Instead a way to fetch invoice on demand is
> required. Both BOLT-12 and LN-URL provide standardized ways for nodes to
> fetch invoices, though their transport/signalling medium of choice differs.
> Blinded routes are technically compatible with BOLT 11 invoices, but may be
> hampered by the fact that you can only include so many routes.
>
> Another consideration is that unlike hop hints, blinded paths require more
> maintain once, as since they traverse public route, policy changes like a
> fee update may invalidate an entire set set of routes. One proposed solution
> is that forwarding nodes should observe their older policy for a period of
> time (so a grace period), and also that blinded paths should have an
> explicit expiry (similar to the existing invoice expiry).
>
> One other implication is that the set of routes the receiver includes matters
> more: if they don't send enough or select them poorly, the sender may never be
> able to reach them even though a path exists in theory. More hands on
> experience is needed so the spec authors can better guide implementations and
> wallets w.r.t best practices.
>
> # Friend-of-a-friend Balance Sharing & Probing
>
> A presentation was given on friend-of-a-friend balance sharing [16]. The
> high level idea is that if we share _some_ information within a local
> radius, then this gives the sender more information to choose a path that's
> potentially more reliable. The tradeoff here ofc is that nodes will be
> giving away more information that can potentially be used to ascertain
> payment flows. In an attempt to minimize the amount of information shared,
> the presenter proposed that just 2 bits of information be shared. Some
> initial simulations showed that sharing local information actually performed
> better than sharing global information (?). Some were puzzled w.r.t how
> that's possible, but assuming the slides+methods are published others can
> dig further into the model/parameter used to signal the inclusion.
>
> Arguably, information like this is already available via probing, so one
> line of thinking is something like: "why not just share _some_ of it" that
> may actually lead to less internal failures? This is related to a sort of
> tension between probing as a tool to increase payment reliability and also
> as a tool to degrade privacy in the network. On the other hand, others
> argued that probing provides natural cover traffic, since they actually
> _are_ payments, though they may not be intended to succeed.
>
> On the topic of channel probing, a sort of makeshift protocol was devised to
> make it harder in practice, sacrificing too much on the axis of payment
> reliability. At a high level it proposes that:
>
> * nodes more diligently set both their max_htlc amount, as well as the
> max_htlc_value_in_flight amount
>
> * a 50ms (or select other value) timer should be used when sending out
> commitment signatures, independent of HTLC arrival
>
> * nodes leverage the max_htlc value to set a false ceiling on the max in
> flight parameter
>
> * for each HTLC sent/forwarded, select 2 other channels at random and
> reduce the "fake" in-flight ceiling for a period of time
>
> Some more details still need to be worked out, but some felt that this would
> kick start more research into this area, and also make balance mapping
> _slightly_ more difficult. From afar, it may be the case that achieving
> balance privacy while also achieving acceptable levels of payment
> reliability might be at odds with each other.
>
> # Eltoo & ANYPREVOUT
>
> One of the attendees is currently working on both fully implementing eltoo,
> as well as specifying the exact channel funding+update interaction were it
> to be rolled out align side the existing penalty based channels in the
> protocol. As this version of eltoo is based on Taproot, we were able to
> compare notes a bit to find the overlapping set of changes (nonce handling,
> etc), which permits cross review of the proposals. This type of work is
> cool, as only by fully implementing something end to end can you reaaally
> work out all the edge cases and nuances.
>
> ANYPREVOUT as hasn't changed significantly as of late. An attendee shared
> plans to create a sort of mega all-future-feasible-soft-forks fork of
> bitcoind, that would package up various unmerged (from bitcoind's) proposal
> soft fork packages into an easy to run+install binary/project attached to a
> signet. The hop is that by giving developers an easy way to interact with
> proposed soft fork proposals (vs debasing some ancient pull request), wider
> participation in testing/implementation/review can be facilitated.
>
> # Trampoline Routing
>
> There was a presentation on Trampoline routing explaining the motivation,
> history, and current state of the proposal. The two main cases we've
> narrowed down on are:
>
> 1. A mobile user doesn't necessarily want to sync the _entire_ graph, so
> they can use trampoline to maintain a subset and still be able to send
> payments.
>
> 2. A mobile user wants to be able to instate a payment, go offline, and
> return at a later time to learn about the final state of the payment.
>
> Use case #2 seems to be the most promising when combined with other
> proposals for holding HTLCs at an origin node (call it an "LSP") [13].
> Combined together, this would allow a mobile node to send a payment, then go
> offline, with the LSP being able to retry the payment either continuously or
> only when it knows the receiver is online to accept the payment. This may
> potentially dramatically improve the UX for LN on mobile, as things suddenly
> become a lot more asynchronous: I do something go offline, and the LSP node
> can fulfil the payment in the background, then wait for me to come online to
> settle the final. hop.
>
> Trampoline can also be composed well with blinded routes (blinded route from
> last trampoline to receiver) and also MPP (internal nodes can split
> themselves with local information).
>
> One added trade-off is that since the sender doesn't know the entire route,
> they need to sort of overshoot w.r.t fees and CTLVs. This is something
> we've known for a while, but until Trampoline is more widely rolled out, we
> won't have a very good feel w.r.t how much extra senders will need to
> allocate.
>
> # Node Fee Optimization & Fee Rate Cards
>
> Over the past few years, a common thread we've seen across successful
> routing nodes is dynamic fee setting as a way to encourage/discourage
> traffic. A routing nodes can utilize the set of fees of a channel to either
> make it too expensive for other nodes to route through (it's already
> depleted don't try unless you'll give be 10 mil sats, which no one would) or
> very cheap, which'll incentivize flows in the other direction. If all nodes
> are constantly sending out updates of this nature, then it can generate a
> lot of traffic, and also sort of leak more balance information overtime
> (which some nodes are already doing: using fees/max_htlc to communicate
> available balances).
>
> One attendee proposed allowing nodes to express a sort of fee gradient via a
> static curve/bucket/function, instead of dynamically communicating what the
> latest state of the fee+liquidity distribution looks like. A possible
> manifestation could be a series of buckets, each of which with varying fee
> rates. If your payment consumes 50% of channel balance, then you pay this
> rate, otherwise if it's 5% you pay this rate, etc, etc. This might allow for
> nodes to capture the same dynamics as they do with more dynamic fee updates,
> but in a way that leaks less information and also consumes less gossip
> bandwidth.
>
> # The Return of Splicing
>
> Splicing is one of those things that was discussed a long time ago, but was
> never really fully implemented and rolled out. A few attendees have started
> to take a closer look at the problem, building off of the interactive-tx
> scheme that the dual-funding protocol extension uses. The main intricacy
> discussed was if concurrent splices should be allowed or not, and if so, how
> we would handle the various edge cases. As an example, if I propose a splice
> to add more funds via my input, but that turns out to already be spent, then
> the splicing transaction we created is invalid and can never be confirmed.
> However if we allow _another_ splice to take place, and another one, and
> another one, then ideally _one_ of them will confirm and serve as the new
> anchor for the channel.
>
> In a world of concurrent splices, the question of "what is my Lightning
> balance" becomes even more murky. Wallet and implementations will likely
> want to show the most pessimistic value, while also ensuring that the user
> is able to effectively account for where all their funds and what they can
> spend on/off chain.
>
> # LN-URL + BOLT 12
>
> LN-URL and BOLT 12 are both standardized ways that answer the question of:
> how can I fetch an invoice from Bob? LN-URL differs from BOLT 12 in that it
> uses the existing BOLT 11 invoice format, and uses an HTTP based protocol
> for the negotiation process. BOLT 12 on the other hand is a suite of
> protocol additions that includes (amongst other things) a new invoice format
> (yay TLV!) and also a way to use onion messages to fetch an invoice _via_
> the network.
>
> Assuming blinded paths is widely rolled out, then the question of how
> invoices are obtained becomes more important as blinded paths means that you
> can't fit much in the traditional QR encoding. As a result, fetching
> invoices on demand may become a more common place flow, with all its
> trade-offs. There was a group discussion on how we could sort of unifying
> everything either by allowing BOLT 12 to be used over LN-URL or the other
> way around.
>
> One proposal was to add a new query parameter to the normal LN-URL QR code
> contents. This would mean that when a wallet goes to scan an LN-URL QR code,
> if they know of the extra param, and what BOLT 12, they can just use the
> enclosed offer to fetch the invoice.
>
> An alternative proposal was to instead extract the BOLT 12 _invoice_ format
> from the greater BOLT 12 "Offers" proposal. Assuming blinded paths is only
> specified w.r.t BOLT 12 _invoices_, then this would mean an LN-URL extension
> could be rolled out that allowed returning BOLT 12 invoice rather than BOLT
> 11 invoices. This would allow the ecosystem to slowly transition to a shared
> invoice format, even if there may be fundamental disagreements w.r.t _how_
> the invoices should be fetched in the first place.
>
> It's worth noting that both of these proposals can be combined:
>
> * If a wallet knows how to BOLT 12 Offers, they can take the enclosed
> offer and run w/ it.
>
> * If they don't know about Offers, but can send w/ the BOLT _invoice_
> format, then they can fetch that and complete the payment.
>
> This might be a nice middle ground as it would tend all
> wallets/implementations to being able to decode and send w/ a BOLT 12
> _invoice_, and leave the question of _how_ it should be fetched up to the
> application/wallet/service. In the end, if paths never quite intersect, then
> it's still possible to add route blinding to BOLT 11, with LN-URL sticking
> with that invoice format to take advantage of the new privacy enhancements
>
> [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-November/003336.html
> [2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
> [3]: https://github.com/lightning/bolts/pull/995
> [4]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
> [5]: https://datatracker.ietf.org/doc/html/rfc6979
> [6]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003470.html
> [7]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-March/003526.html
> [8]: https://arxiv.org/abs/2205.12737
> [9]: https://bitcoinops.org/en/topics/minisketch/
> [10]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-April/003551.html
> [11]: https://blog.bitmex.com/preventing-channel-jamming/
> [12]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003498.html
> [13]: https://github.com/lightning/bolts/pull/765
> [14]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003307.html
> [15]: https://github.com/lightning/bolts/pull/910
> [16]: https://github.com/lightning/bolts/pull/780
>
> -- Laolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220621/89814a22/attachment-0001.html>

2023-06-09 13:05:35

- reply

📅 Original date posted:2022-03-18
📝 Original message:
Hi
I thought I'd start posting transcripts that may be of interest to this mailing list.
We had a panel discussion on various topics in London before Advancing Bitcoin with Christian Decker (c-lightning), Bastien Teinturier (eclair) and Oliver Gugger (LND).
The transcript is here: https://github.com/bitcointranscripts/bitcointranscripts/blob/master/london-bitcoin-devs/2022-03-01-lightning-panel.md
It will eventually make it onto the btctranscripts.com website and there will be a video up at some point too.
Christian did a demo of and discussed Greenlight (onboarding new Lightning nodes that run on external infrastructure whilst retaining control of keys), we contrasted the different approaches of running a Lightning node with the different Lightning implementations, discussed priorities of the individual implementations in the coming year and covered recent tensions in the spec (BOLT) process.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220318/254c2014/attachment.html>

2023-06-09 13:05:16

- reply

📅 Original date posted:2022-02-14
📝 Original message:
> This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.
Right, not immediately. If and when new policy rules are included in a Bitcoin Core release it would take a while before a significant majority of the network were running those new policy rules (barring some kind of urgency, an attacker exploiting a systemic security flaw etc). That's not an argument not to do it though if you take a longer term perspective on building the strongest possible foundation for Lightning or other Layer 2 projects. The security benefit would just be delayed until a significant majority of Bitcoin Core users upgraded to a version including those new policy rules.
> Bitcoin Core with different versions are used at any point and not sure if this will ever change.
Sure there will always be some stray full nodes running extremely old versions but the general direction of travel is more and more full nodes upgrading to newer versions. A network where *all* full nodes are running the same policy rules is clearly not an option available to us without making policy rules effective consensus rules and forking/kicking those old versions off the network.
> Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.
Definitely agree. It is a really interesting research area and lots of opportunities for simulations and experiments on the default or custom signet networks. Especially if we fill blocks with auto-generated transactions and/or reduce block sizes and create an artificial fee market.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, February 14th, 2022 at 5:18 AM, Prayank <prayank at tutanota.de> wrote:
>> I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical).
>
> 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some are even running lower versions. Different versions in future with defaults might be running RBF v1 and RBF v2.
>
>> But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.
>
> Agree and attackers will want to run the nodes with policy that helps them exploit bitcoin projects. Miners can run nodes with policy that helps them get more fees.
>
>> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used.
>
> Bitcoin Core with different versions are used at any point and not sure if this will ever change.
>
> https://luke.dashjr.org/programs/bitcoin/files/charts/security.html
>
> https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22&facet=product
>
>> I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>
> This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.
>
> Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
> Feb 13, 2022, 21:16 by michaelfolkson at protonmail.com:
>
>> Hi Prayank
>>
>>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>
>> Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
>>
>>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>
>> Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning.
>>
>> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>>
>>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>
>> I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
>>
>>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>
>> The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hello World,
>>>
>>> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>>>
>>> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>>>
>>> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>>>
>>> Based on the things shared by 'aj' in
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>>>
>>> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>>>
>>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>>
>>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>>
>>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>>
>>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220214/c2938382/attachment-0001.html>

2023-06-09 13:05:15

- reply

📅 Original date posted:2022-02-13
📝 Original message:
Hi Prayank
> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning. I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical). But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.
As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Hello World,
>
> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>
> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>
> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>
> Based on the things shared by 'aj' in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>
> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>
> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>
> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>
> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>
> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220213/45f656e7/attachment.html>

2023-06-09 13:03:22

- reply

📅 Original date posted:2021-08-12
📝 Original message:
Just a joke. Previous release names have been "Federal Qualitative
Strengthening", "(Still) Scaling the Ethereum Blockchain", "Blockchain
Good, Orange Coin Bad", "Bitcoin's Proof of Stake" etc
https://github.com/ElementsProject/lightning/releases
I can assure you the c-lightning team isn't planning to introduce
proof of stake to Bitcoin or change its monetary policy. Though I'm
sure they're open to new name suggestions for the next release if you
can think of one.
On Thu, Aug 12, 2021 at 4:15 AM Prayank via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Hi Lisa,
>
> > lisa neigut Mon, 09 Aug 2021 18:04:51 -0700
>
> > We're pleased to announce the 0.10.1 release of c-lightning
> > <https://github.com/ElementsProject/lightning/releases/tag/v0.10.1>, named
> > by @nalinbhardwaj.
>
> I am confused about the subject of this email. Is this an Ethereum project? What exactly is Ethereum layer and how is it related to this release?
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-09 13:03:12

- reply

📅 Original date posted:2021-07-29
📝 Original message:
There was some additional discussion on L2 onchain support at the
recent online Sydney Socratic Seminar. It wasn't recorded but a
transcript is below.
Transcript: https://btctranscripts.com/sydney-bitcoin-meetup/2021-07-06-socratic-seminar/
The discussion focused partly on the rules [1] of BIP 125 RBF and the
rationale for these rules (which isn't clear from the BIP). Proposed
ideas such as SIGHASH_IOMAP, fee sponsorship and transaction mutation
were also discussed that weren't covered during the IRC workshops.
[1] https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details
On Tue, Jun 29, 2021 at 10:44 AM Michael Folkson
<michaelfolkson at gmail.com> wrote:
>
> A summary of the first workshop is here:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
>
> The focus for this second workshop was fee bumping and package relay.
> For more details on package relay see:
> https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md
>
> The conversation log for the second workshop is here:
> https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
>
> Package relay background
>
> Package relay is potentially useful for L2 protocols to address the
> inherent unpredictability of future fees. CPFP (child-pays-for-parent)
> seeks to ensure say a justice transaction, in Lightning’s case, with a
> lower fee, gets confirmed in a more timely manner because miners are
> incentivized to include the child transaction in a block. To do so
> they must include the parent transaction in that block or a preceding
> block. By “packaging” the parent and the child the initiator of the
> transaction(s) can ensure the miner’s mempool doesn’t initially reject
> the parent transaction for having a too low fee.
>
> There has been prior work done in previous years on package relay,
> mainly by Suhas Daftuar.
>
> Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
>
> Package relay design questions: https://github.com/bitcoin/bitcoin/issues/14895
>
> Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
> https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
>
> Package relay implementation
>
> Attendees seemed in agreement that enabling 2 transaction packages
> would be sufficient (at least for now) for Lightning and DLCs. A L2
> protocol should always be able to design a two step process where the
> first transaction has an effective zero fee rate and the second
> transaction sets the fee. Restricting the size of the package to 2 may
> have the cost of slightly longer confirmation times and/or slightly
> higher fees (t-bast) but it compares well to the increased
> implementation complexity of larger package sizes. Two generation:
> multi parent, single child shouldn’t introduce material implementation
> complexity over two generation: single parent, single child (glozow).
>
> Package RBF (replace-by-fee) is possible where there are two competing
> packages with competing Lightning commitment transactions in them and
> the second package is given a higher fee to attempt to get it
> confirmed before the first package. However, supporting RBF within a
> package (ie replacing a transaction in a package with a higher fee
> transaction) increases implementation complexity and makes it harder
> to reason about (glozow).
>
> rgrant raised the possibility of using two packages {A,B} and {B,C} if
> three transaction packages e.g. {A,B,C} weren’t supported but it was
> suggested it is perhaps better to just broadcast a high fee CPFP
> transaction for the {A,B} package rather than creating two packages.
> If the first package has been evicted from the mempool the {B,C}
> package wouldn’t propagate because it would be an orphan package
> (t-bast).
>
> glozow suggested that only hints (wtxids of transactions you think
> should be package validated) could be communicated rather than
> relaying the transaction themselves but there were concerns from
> others on whether these hints would successfully propagate across the
> network. Instead fee rate hints could be sent to inform a peer’s
> decision on whether it makes sense to fetch the rest of the package
> (t-bast).
>
> darosior suggested the idea of a package based CBlockPolicyEstimator
> in Bitcoin Core if CPFP is going to be increasingly used on the
> network.
>
> Witness replacement and Taproot
>
> Tapscripts can be unlimited in size so with current Taproot rules you
> could in theory go from a 100,000 vbyte witness to an empty witness.
> L2 protocols may have a UTXO shared by two parties where Alice’s
> witness for her branch is say 1,000 vbytes and Bob’s witness is only
> say 250 vbytes. Replacing Alice’s larger witness with Bob’s smaller
> witness could reduce transaction fees. For Lightning the best case is
> a Taproot key path spend (16 vbyte witness) and the worst case is
> going to be a 150 vbyte witness. Miniscript can tell you your worst
> case transaction size and this can be used to assess the transaction
> pinning risk of a bloated witness (all harding).
>
> A future soft fork could give meaning to the annex in Taproot
> (darosior) which could be used for inflating the fee rate of a
> witness. Then you could have a same-txid-different-wtxid coming after
> with a lower fee rate but higher vbytes size to override package
> limits (ariard). But fee rate is purely a policy concept and the annex
> operates at the consensus level. In addition the annex can only
> increase the weight of a transaction, it cannot decrease it (harding).
>
> Wrap up and initial goals
>
> With regards to the goals of the workshops that were initially
> announced here:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html
>
> 1) 2 transactions packages sounds enough to support currently deployed
> L2 protocols
> 2) There are ongoing discussions in the ecosystem regarding
> deprecation of opt in RBF and implementation of full RBF:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
> 3) Generally status quo and ad hoc security incident response policy
> in the case of cross-layer security issues
> 4) Generally status quo on L2 security philosophy design. L2 protocol
> designers should seek to minimize assumptions on the base layer.
>
> --
> Michael Folkson
> Email: michaelfolkson at gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-09 13:02:53

- reply

📅 Original date posted:2021-07-02
📝 Original message:
> The other thing bLIPs do is do away with the whole "human picks the number of documents", and "don't assign your own number, you must wait".
So TL;DR BIPs and BOLTs sometimes require waiting for things (like
review and consensus) and there should be a new acronym and process
("bLIPs") to avoid us having to wait for things. I just think "bLIPs"
adds confusion e.g. should something be a bLIP or a BOLT? Does a bLIP
eventually become a BOLT when it is mature enough? This tendency to
fragment and introduce new acronyms and new processes should be
resisted imo. If a new process is introduced every time there is a
disagreement or perceived friction it just erodes the value of
existing processes and means they all get bypassed. Strengthen and
improve existing processes and only introduce a new one as an absolute
last resort.
Other than the minor frictions described above I don't see why "bLIPs"
can't just be draft BOLTs.
> Adding a third BIP editor more involved with Lightning sounds like a good idea.
Or alternatively if BOLTs were subsumed into BIPs I think Bastien
would be a great additional BIP editor to cover Lightning related BIPs
:) I think BOLTs being subsumed into BIPs would be nice but I'm
pessimistic it will happen. Like legislation and regulation in the
legacy financial system alphabet soups only expand they never get
simplified. Let's at least resist alphabet soup expansion here.
On Fri, Jul 2, 2021 at 9:01 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
>>
>> Will it actually add any more fragmentation that already exists? Due to all
>> the extensibility we've added in the protocol, it's already possible for any
>> implementation to start to work on their own sub-protocols. This just gives
>> them a new venue to at least _describe_ what they're using.
>
>
> It's only my 2 cents, but I'm afraid it will indeed add more fragmentation, because
> the fact that there exists a bLIP for feature XXX will likely act as a green light to
> deploy it faster instead of spending more time talking about it with the community
> and thinking about potential issues, forward-compatibility, etc.
>
> But I agree with you that it also gives more freedom to experiment in the real world,
> which helps find issues and correct them, paving the way for better features for
> end users.
>
>> It's also likely the case that already implementations, or typically forks
>> of implementations are already using "undocumented" TLVs or feature bits in
>> the wild today.
>
>
> But today we're usually very careful when we do that, and use numbers in high ranges
> for these use-cases. In our case for example we use message type 35007 for our
> swap-in and we expect that to change once standardized, so we did extra work to
> ensure we wouldn't paint ourselves into a corner when switching to a standard version.
>
> I think that if we have a centralized bLIP repo, we can take this opportunity to safely
> assign "final" values for types and feature bits that are used by each bLIP, and stronger
> guarantees that they will not conflict with another bLIP or BOLT. Of course that doesn't
> stop anyone from deploying a conflict, but their use of the same bits won't be documented
> so it shouldn't be widely deployed, and browsing the BOLTs and bLIPs should let anyone
> see what the "correct" meaning of those bits should be.
>
> Cheers,
> Bastien
>
>
> Le jeu. 1 juil. 2021 à 22:43, Olaoluwa Osuntokun <laolu32 at gmail.com> a écrit :
>>
>> > But they don't address the first point at all, they instead work around
>> > it. To be fair, I don't think we can completely address that first point:
>> > properly reviewing spec proposals takes a lot of effort and accepting
>> > complex changes to the BOLTs shouldn't be done lightly.
>>
>> I think this is a fair characterization that I agree with. I also agree that
>> there isn't really a way to fundamentally address it. The issue of scarce
>> review resources is something just about any large open source project needs
>> to deal with: everyone wants to make a PR, but no one wants to review the
>> PRs of others, unless it scratches some tangential itch they may have. IMO
>> it's also the case that the problem/solution space of LN is so large, that
>> it's hard to expect every developer to review each new proposal that comes
>> in, as they themselves have their own set of priorities (product,
>> businesses, protocol, personal, etc).
>>
>> In the end though, I think when there've been critical items that affect all
>> implementations and/or the existence of the protocol itself, developers
>> typically band together to commit resources to help a proposal move forward.
>> One upcoming example of this will be the "base" taproot channel type (the
>> design space is pretty large in that it even permits a new type of symmetric
>> state revocation-based channel).
>>
>> > it will add fragmentation to the network, it will add maintenance costs
>> > and backwards-compatibility issues
>>
>> Will it actually add any more fragmentation that already exists? Due to all
>> the extensibility we've added in the protocol, it's already possible for any
>> implementation to start to work on their own sub-protocols. This just gives
>> them a new venue to at least _describe_ what they're using. As usual, it's
>> up to other implementations if they want to adopt it or not, or advise
>> against its use.
>>
>> > many bLIPs will be sub-optimal solutions to the problem they try to solve
>> > and some bLIPs will be simply insecure and may put users' funds at risk
>> > (L2 protocols are hard and have subtle issues that can be easily missed)
>>
>> This may be the case, but I guess at times it's hard to know if something is
>> objectively sub-optimal without further exploration of the design space,
>> which usually means either more people involved, or more time examining the
>> problem. Ultimately, different wallets/implementations may also be willing
>> to make different usability/security trade-offs. One example here is zero
>> conf channels: they assume a greater degree of trust with the party you're
>> _accepting_ the channel from, as if you receive funds over the channel, they
>> can be double spent away. However it's undeniable that they improve the UX
>> by reducing the amount of time a user needs to wait around before they can
>> actually jump in and use LN.
>>
>> In the end though, there's no grand global committee that prevents people
>> from deploying software they think is interesting or useful. In the long
>> run, I guess one simply needs to hope that bad ideas die out, or speak out
>> against them to the public. As LN sits a layer above the base protocol,
>> widespread global consensus isn't really required to make certain classes of
>> changes, and you can't stop people from experimenting on their own.
>>
>> > We can't have collisions on any of these three things.
>>
>> Yeah, collisions are def possible. IMO, this is where the interplay with
>> BOLTs comes in: BOLTs are the global feature bit/tlv/message namespace. A
>> bLIP might come with the amendment of BOLT 9 to define feature bits they
>> used. Of course, this should be done on a best effort basis, as even if you
>> assign a bit for your idea, someone can just go ahead and deploy something
>> else w/ that same bit, and they may never really intersect depending on the
>> nature or how widespread the new feature is.
>>
>> It's also likely the case that already implementations, or typically forks
>> of implementations are already using "undocumented" TLVs or feature bits in
>> the wild today. I don't know exactly which TLV type things like applications
>> that tunnel messages over the network use, but afaik so far there haven't
>> been any disastrous collisions in the wild.
>>
>> -- Laolu
>>
>> On Thu, Jul 1, 2021 at 2:19 AM Bastien TEINTURIER <bastien at acinq.fr> wrote:
>>>
>>> Thanks for starting that discussion.
>>>
>>> In my opinion, what we're really trying to address here are the two following
>>> points (at least from the point of view of someone who works on the spec and
>>> an implementation):
>>>
>>> - Implementers get frustrated when they've worked on something that they think
>>> is useful and they can't get it into the BOLTs (the spec PR isn't reviewed,
>>> it progresses too slowly or there isn't enough agreement to merge it)
>>> - Implementers expect other implementers to specify the optional features they
>>> ship: we don't want to have to reverse-engineer a sub-protocol when users
>>> want our implementation to provide support for feature XXX
>>>
>>> Note that these are two very different concerns.
>>>
>>> bLIPs/SPARKS/BIPs clearly address the second point, which is good.
>>> But they don't address the first point at all, they instead work around it.
>>> To be fair, I don't think we can completely address that first point: properly
>>> reviewing spec proposals takes a lot of effort and accepting complex changes
>>> to the BOLTs shouldn't be done lightly.
>>>
>>> I am mostly in favor of this solution, but I want to highlight that it isn't
>>> only rainbows and unicorns: it will add fragmentation to the network, it will
>>> add maintenance costs and backwards-compatibility issues, many bLIPs will be
>>> sub-optimal solutions to the problem they try to solve and some bLIPs will be
>>> simply insecure and may put users' funds at risk (L2 protocols are hard and have
>>> subtle issues that can be easily missed). On the other hand, it allows for real
>>> world experimentation and iteration, and it's easier to amend a bLIP than the
>>> BOLTs.
>>>
>>> On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully bazaar
>>> style of evolution. Most of them will need:
>>>
>>> - to assign feature bit(s)
>>> - to insert new tlv fields in existing messages
>>> - to create new messages
>>>
>>> We can't have collisions on any of these three things. bLIP XXX cannot use the
>>> same tlv types as bLIP YYY otherwise we're creating network incompatibilities.
>>> So they really need to be centralized, and we need a process to assign these
>>> and ensure they don't collide. It's not a hard problem, but we need to be clear
>>> about the process around those.
>>>
>>> Regarding the details of where they live, I don't have a strong opinion, but I
>>> think they must be easy to find and browse, and I think it's easier for readers
>>> if they're inside the spec repository. We already have PRs that use a dedicated
>>> "proposals" folder (e.g. [1], [2]).
>>>
>>> Cheers,
>>> Bastien
>>>
>>> [1] https://github.com/lightningnetwork/lightning-rfc/pull/829
>>> [2] https://github.com/lightningnetwork/lightning-rfc/pull/854
>>>
>>> Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces <arielluaces at gmail.com> a écrit :
>>>>
>>>> BIPs are already the Bazaar style of evolution that simultaneously
>>>> allows flexibility and coordination/interoperability (since anyone can
>>>> create a BIP and they create an environment of discussion).
>>>>
>>>> BOLTs are essentially one big BIP in the sense that they started as a
>>>> place for discussion but are now more rigid. BOLTs must be followed
>>>> strictly to ensure a node is interoperable with the network. And BOLTs
>>>> should be rigid, as rigid as any widely used BIP like 32 for example.
>>>> Even though BOLTs were flexible when being drafted their purpose has
>>>> changed from descriptive to prescriptive.
>>>> Any alternatives, or optional features should be extracted out of
>>>> BOLTs, written as BIPs. The BIP should then reference the BOLT and the
>>>> required flags set, messages sent, or alterations made to signal that
>>>> the BIP's feature is enabled.
>>>>
>>>> A BOLT may at some point organically change to reference a BIP. For
>>>> example if a BIP was drafted as an optional feature but then becomes
>>>> more widespread and then turns out to be crucial for the proper
>>>> operation of the network then a BOLT can be changed to just reference
>>>> the BIP as mandatory. There isn't anything wrong with this.
>>>>
>>>> All of the above would work exactly the same if there was a bLIP
>>>> repository instead. I don't see the value in having both bLIPs and
>>>> BIPs since AFAICT they seem to be functionally equivalent and BIPs are
>>>> not restricted to exclude lightning, and never have been.
>>>>
>>>> I believe the reason this move to BIPs hasn't happened organically is
>>>> because many still perceive the BOLTs available for editing, so
>>>> changes continue to be made. If instead BOLTs were perceived as more
>>>> "consensus critical", not subject to change, and more people were
>>>> strongly encouraged to write specs for new lightning features
>>>> elsewhere (like the BIP repo) then you would see this issue of growing
>>>> BOLTs resolved.
>>>>
>>>> Cheers
>>>> Ariel Lorenzo-Luaces
>>>>
>>>> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>>>> >
>>>> > > That being said I think all the points that are addressed in Ryan's mail
>>>> > > could very well be formalized into BOLTs but maybe we just need to rethink
>>>> > > the current process of the BOLTs to make it more accessible for new ideas
>>>> > > to find their way into the BOLTs?
>>>> >
>>>> > I think part of what bLIPs are trying to solve here is promoting more loosely
>>>> > coupled evolution of the network. I think the BOLTs do a good job currently of
>>>> > specifying what _base_ functionality is required for a routing node in a
>>>> > prescriptive manner (you must forward an HTLC like this, etc). However there's
>>>> > a rather large gap in describing functionality that has emerged over time due
>>>> > to progressive evolution, and aren't absolutely necessary, but enhance
>>>> > node/wallet operation.
>>>> >
>>>> > Examples of include things like: path finding heuristics (BOLTs just say you
>>>> > should get from Alice to Bob, but provides no recommendations w.r.t _how_ to do
>>>> > so), fee bumping heuristics, breach retribution handling, channel management,
>>>> > rebalancing, custom records usage (like the podcast index meta-data, messaging,
>>>> > etc), JIT channel opening, hosted channels, randomized channel IDs, fee
>>>> > optimization, initial channel boostrapping, etc.
>>>> >
>>>> > All these examples are effectively optional as they aren't required for base
>>>> > node operation, but they've organically evolved over time as node
>>>> > implementations and wallet seek to solve UX and operational problems for
>>>> > their users. bLIPs can be a _descriptive_ (this is how things can be done)
>>>> > home for these types of standards, while BOLTs can be reserved for
>>>> > _prescriptive_ measures (an HTLC looks like this, etc).
>>>> >
>>>> > The protocol as implemented today has a number of extensions (TLVs, message
>>>> > types, feature bits, etc) that allow implementations to spin out their own
>>>> > sub-protocols, many of which won't be considered absolutely necessary for node
>>>> > operation. IMO we should embrace more of a "bazaar" style of evolution, and
>>>> > acknowledge that loosely coupled evolution allows participants to more broadly
>>>> > explore the design space, without the constraints of "it isn't a thing until N
>>>> > of us start to do it".
>>>> >
>>>> > Historically, BOLTs have also had a rather monolithic structure. We've used
>>>> > the same 11 or so documents for the past few years with the size of the
>>>> > documents swelling over time with new exceptions, features, requirements,
>>>> > etc. If you were hired to work on a new codebase and saw that everything is
>>>> > defined in 11 "functions" that have been growing linearly over time, you'd
>>>> > probably declare the codebase as being unmaintainable. By having distinct
>>>> > documents for proposals/standards, bLIPs (author documents really), each new
>>>> > standard/proposal is able to be more effectively explained, motivated, versionsed,
>>>> > etc.
>>>> >
>>>> > -- Laolu
>>>> >
>>>> >
>>>> > On Wed, Jun 30, 2021 at 7:35 AM René Pickhardt via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>>> >>
>>>> >> Hey everyone,
>>>> >>
>>>> >> just for reference when I was new here (and did not understand the processes well enough) I proposed a similar idea (called LIP) in 2018 c.f.: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
>>>> >>
>>>> >> I wonder what exactly has changed in the reasoning by roasbeef which I will repeat here:
>>>> >>
>>>> >> > We already have the equiv of improvement proposals: BOLTs. Historically
>>>> >>
>>>> >> > new standardization documents are proposed initially as issues or PR's when
>>>> >>
>>>> >> > ultimately accepted. Why do we need another repo?
>>>> >>
>>>> >>
>>>> >> As far as I can tell there was always some form of (invisible?) barrier to participate in the BOLTs but there are also new BOLTs being offered:
>>>> >> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
>>>> >> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
>>>> >> and topics to be included like:
>>>> >> * dual funding
>>>> >> * splicing
>>>> >> * the examples given by Ryan
>>>> >>
>>>> >> I don't see how a new repo would reduce that barrier - Actually I think it would even create more confusion as I for example would not know where something belongs. That being said I think all the points that are addressed in Ryan's mail could very well be formalized into BOLTs but maybe we just need to rethink the current process of the BOLTs to make it more accessible for new ideas to find their way into the BOLTs? One thing that I can say from answering lightning-network questions on stackexchange is that it would certainly help if the BOLTs where referenced on lightning.network web page and in the whitepaper as the place to be if one wants to learn about the Lightning Network
>>>> >>
>>>> >> with kind regards Rene
>>>> >>
>>>> >> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>>> >>>
>>>> >>> Hi all,
>>>> >>>
>>>> >>>
>>>> >>> The recent thread around zero-conf channels [1] provides an opportunity to discuss how the BOLT process handles features and best practices that arise in the wild vs. originating within the process itself. Zero-conf channels are one of many LN innovations on the app layer that have struggled to make their way into the spec. John Carvalho and Bitrefill launched Turbo channels in April 2019 [2], Breez posted their solution to the mailing list for feedback in August 2020 [3], and we know at least ACINQ and Muun (amongst others) have their own implementations. In an ideal world there would be a descriptive design document that the app layer implementers had collaborated on over the years that the spec group could then pick up and merge into the BOLTs now that the feature is deemed spec-worthy.
>>>> >>>
>>>> >>>
>>>> >>> Over the last couple of months, we have discussed the idea of adding a BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various members of the community, and have received positive feedback from both app layer and protocol devs. This would not affect the existing BOLT process at all, but simply add a place for app layer best practices to be succinctly described and organized, especially those that require coordination. These features are being built outside of the BOLT process today anyways, so ideally a bLIP process would bring them into the fold instead of leaving them buried in old ML posts or not documented at all.
>>>> >>>
>>>> >>>
>>>> >>> Some potential bLIP ideas that people have mentioned include: each lnurl variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment metadata, p2p messaging formats, new pathfinding heuristics, remote node connection standards, etc.
>>>> >>>
>>>> >>>
>>>> >>> If the community is interested in moving forward, we've started a branch [5] describing such a process. It's based on BIP-0002, so not trying to reinvent any wheels. It would be great to have developers from various implementations and from the broader app layer ecosystem volunteer to be listed as editors (basically the same role as in the BIPs).
>>>> >>>
>>>> >>>
>>>> >>> Looking forward to hearing your thoughts!
>>>> >>>
>>>> >>>
>>>> >>> Best,
>>>> >>> Ryan
>>>> >>>
>>>> >>>
>>>> >>> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>>>> >>>
>>>> >>> [2] https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>>>> >>>
>>>> >>> [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>>>> >>>
>>>> >>> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>>>> >>>
>>>> >>> [5] https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Lightning-dev mailing list
>>>> >>> Lightning-dev at lists.linuxfoundation.org
>>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> https://www.rene-pickhardt.de
>>>> >> _______________________________________________
>>>> >> Lightning-dev mailing list
>>>> >> Lightning-dev at lists.linuxfoundation.org
>>>> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>> >
>>>> > _______________________________________________
>>>> > Lightning-dev mailing list
>>>> > Lightning-dev at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-09 13:02:47

- reply

📅 Original date posted:2021-06-29
📝 Original message:
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-and-friends.md
The conversation log for the second workshop is here:
https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
Package relay background
Package relay is potentially useful for L2 protocols to address the
inherent unpredictability of future fees. CPFP (child-pays-for-parent)
seeks to ensure say a justice transaction, in Lightning’s case, with a
lower fee, gets confirmed in a more timely manner because miners are
incentivized to include the child transaction in a block. To do so
they must include the parent transaction in that block or a preceding
block. By “packaging” the parent and the child the initiator of the
transaction(s) can ensure the miner’s mempool doesn’t initially reject
the parent transaction for having a too low fee.
There has been prior work done in previous years on package relay,
mainly by Suhas Daftuar.
Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66a
Package relay design questions: https://github.com/bitcoin/bitcoin/issues/14895
Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
Package relay implementation
Attendees seemed in agreement that enabling 2 transaction packages
would be sufficient (at least for now) for Lightning and DLCs. A L2
protocol should always be able to design a two step process where the
first transaction has an effective zero fee rate and the second
transaction sets the fee. Restricting the size of the package to 2 may
have the cost of slightly longer confirmation times and/or slightly
higher fees (t-bast) but it compares well to the increased
implementation complexity of larger package sizes. Two generation:
multi parent, single child shouldn’t introduce material implementation
complexity over two generation: single parent, single child (glozow).
Package RBF (replace-by-fee) is possible where there are two competing
packages with competing Lightning commitment transactions in them and
the second package is given a higher fee to attempt to get it
confirmed before the first package. However, supporting RBF within a
package (ie replacing a transaction in a package with a higher fee
transaction) increases implementation complexity and makes it harder
to reason about (glozow).
rgrant raised the possibility of using two packages {A,B} and {B,C} if
three transaction packages e.g. {A,B,C} weren’t supported but it was
suggested it is perhaps better to just broadcast a high fee CPFP
transaction for the {A,B} package rather than creating two packages.
If the first package has been evicted from the mempool the {B,C}
package wouldn’t propagate because it would be an orphan package
(t-bast).
glozow suggested that only hints (wtxids of transactions you think
should be package validated) could be communicated rather than
relaying the transaction themselves but there were concerns from
others on whether these hints would successfully propagate across the
network. Instead fee rate hints could be sent to inform a peer’s
decision on whether it makes sense to fetch the rest of the package
(t-bast).
darosior suggested the idea of a package based CBlockPolicyEstimator
in Bitcoin Core if CPFP is going to be increasingly used on the
network.
Witness replacement and Taproot
Tapscripts can be unlimited in size so with current Taproot rules you
could in theory go from a 100,000 vbyte witness to an empty witness.
L2 protocols may have a UTXO shared by two parties where Alice’s
witness for her branch is say 1,000 vbytes and Bob’s witness is only
say 250 vbytes. Replacing Alice’s larger witness with Bob’s smaller
witness could reduce transaction fees. For Lightning the best case is
a Taproot key path spend (16 vbyte witness) and the worst case is
going to be a 150 vbyte witness. Miniscript can tell you your worst
case transaction size and this can be used to assess the transaction
pinning risk of a bloated witness (all harding).
A future soft fork could give meaning to the annex in Taproot
(darosior) which could be used for inflating the fee rate of a
witness. Then you could have a same-txid-different-wtxid coming after
with a lower fee rate but higher vbytes size to override package
limits (ariard). But fee rate is purely a policy concept and the annex
operates at the consensus level. In addition the annex can only
increase the weight of a transaction, it cannot decrease it (harding).
Wrap up and initial goals
With regards to the goals of the workshops that were initially
announced here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html
1) 2 transactions packages sounds enough to support currently deployed
L2 protocols
2) There are ongoing discussions in the ecosystem regarding
deprecation of opt in RBF and implementation of full RBF:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
3) Generally status quo and ad hoc security incident response policy
in the case of cross-layer security issues
4) Generally status quo on L2 security philosophy design. L2 protocol
designers should seek to minimize assumptions on the base layer.
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-09 13:02:37

- reply

📅 Original date posted:2021-06-21
📝 Original message:
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 <antoine.riard at gmail.com> 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 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,
>
> "“Any sufficiently advanced technology is indistinguishable from magic.” 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/002448.html
>
> [1] https://github.com/bitcoin/bitcoin/issues/14895
>
> [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
>
> Le sam. 19 juin 2021 à 09:38, David A. Harding <dave at dtrt.org> a écrit :
>>
>> 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 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-09 13:02:34

- reply

📅 Original date posted:2021-06-17
📝 Original message:
The workshop was previously announced by ariard on the bitcoin-dev
mailing list here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018841.html
A reminder was posted to the bitcoin-dev mailing list here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019068.html
The conversation log for the workshop is here:
https://gist.github.com/ariard/5f28dffe82ddad763b346a2344092ba4
I’ll summarize what was discussed during the meeting but please refer
to the L2 zoology repo ariard has set up for background context and
additional notes: https://github.com/ariard/L2-zoology
General considerations
I think it is worth first reiterating the obvious that there will
never be perfect security guarantees on network transaction fee rates
or transaction relay. Network fee rates can in theory go up to
anything (upper limit of infinity) and will always to some degree be
inherently unpredictable. In addition transaction acceptance can never
be guaranteed even if you attempt a direct connection to a miner. At
the same time L2 protocols (e.g. Lightning and DLCs) elevate
transaction propagation and inclusion in a time sensitive mined block
to a security assumption from what used to just be a usability
assumption (BlueMatt). Within those confines these workshops are
attempting to strengthen that security assumption knowing that
guaranteeing it is out of reach.
There are considerations that blocked transaction propagation isn’t
necessarily a problem for the victim if it is also blocked for the
attacker. In addition some successful attacks present an opportunity
for the victim to divert their funds to miner fees (e.g. scorched
earth) ensuring the attacker doesn’t financially benefit from the
attack (harding). Personally I would argue neither of these present
much assurance to the victim. Out of conservatism one should assume
that the attacker has greater resources than the victim (e.g. a direct
line to a miner) and knowing a victim’s lost funds went to the miner
instead of the attacker isn’t of much comfort to the victim (other
than potentially presenting a disincentive for the attack in the first
place). This is obviously further complicated if the miner is the
attacker. In addition any incentive for miners to not mine
transactions to wait for a potential pay-all-to-fee are troubling
(t-bast).
New(ish) ideas
RubenSomsen brought up the idea of fee sensitive timelocks, they would
need a soft fork. ariard briefly discussed the idea of a transaction
relay overlay network. harding stated his opinion that we should be
leaning more on miners’ profit incentive rather than attempting to
normalize mempool policy (e.g.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html).
t-bast raised the prospect of mining pools exposing public APIs to
push them transactions directly.
The impact of changes to Bitcoin Core on L2 protocols
Some changes to Core (e.g. some privacy improvements) can conflict
with the goal of minimizing transaction propagation times.
Chris_Stewart_5 raised the idea of a nightly bitcoind build to give L2
developers a way to write regression tests against the latest builds
of bitcoind. He added that L2 devs should write automated regression
test suites against bitcoind exposed RPC commands. t-bast would like a
bitcoind “evicttx” RPC to remove a transaction from the mempool on
regtest.
Full RBF
In advance of the workshop ariard posted to the mailing list a
proposal for full RBF in a future version of Bitcoin Core:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
Progress in this direction has been attempted in the past (e.g.
https://github.com/bitcoin/bitcoin/pull/10823) BlueMatt pointed out
that even with full RBF it is trivial to create mempool partitions. As
long as RBF has a fee rate increase minimum an attacker can trivially
split the mempool by broadcasting two conflicting transactions with
the same fee.
ariard plans to contact businesses (e.g. Lightning onboarding services
relying on zero confirmations) to check that this possible eventual
move to full RBF doesn’t present a problem for them. There could well
be engineering work required in advance of the possible change being
made.
Next week’s meeting
Next week’s meeting (Tuesday 22nd June, 19:00 UTC,
#l2-onchain-support, Libera) will be on fee bumping and package relay
that glozow has recently been working to advance in Bitcoin Core.
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-09 12:51:17

- reply

📅 Original date posted:2018-08-01
📝 Original message:
Thanks for this ZmnSCPxj, very interesting.
A couple of follow ups please:
1) Poon-Dryja (LN penalty), Decker-Wattenhofer and Decker-Osuntokun-Russell
(eltoo) just refer to the process for claiming funds when an old state is
broadcast? Poon-Dryja doesn't require a soft fork but
Decker-Osuntokun-Russell does?
2) How does Decker-Wattenhofer claim funds when an old state is broadcast?
On Wed, Aug 1, 2018 at 11:36 AM, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> Recently, somebody on the IRC channel, asked regarding smart contracts
> being transported via LN.
>
> Indeed, this is theoretically possible, provided the "smart contract" is
> implementable as a Bitcoin SCRIPT.
>
> Afterwards, I opined that, for transportation of *arbitrary* contracts,
> Poon-Dryja is superior to either Decker-Wattenhofer or
> Decker-Osuntokun-Russell.
>
> So, first, my other opinions:
>
> 1. The only smart contract you really want to transport is HTLC (or
> equivalent in scriptless script). There really is no point in transporting
> any other contract on LN. HTLCs can even be used to implement
> (nontransferable) swap options, and can be composed (at the cost of
> increasing CLTV limits on backoff) to create multi-step swaps.
>
> 2. Decker-Osuntokun-Russell "eltoo" is far superior to Poon-Dryja
> "LN-penalty" in everything else, except transportation of *arbitrary*
> contracts.
>
> Now, ultimately any Bitcoin SCRIPT may be expressed as a Boolean
> computation whether or not the contract has been fulfilled by the
> transaction that attempts to claim it.
>
> So I introduce, an arbitrary contract C, ostensibly to be transported over
> LN.
>
> And I introduce our transactions, as so: [scriptSig, redeemScript] ->
> redeeming transaction
>
> To transport C over a channel between nodes A and B, under Poon-Dryja, we
> first have a channel anchoring transaction onchain:
>
> [/*arbitrary*/, A && B] ->
>
> Now suppose the entire output is to be put into a contract C. Under
> Poon-Dryja, we create the below symmetrical series of transactions, with
> only the anchoring transaction existing onchain:
>
> [/*arbitrary*/, A && B] -> [signA signB, (revoke) || (A && B && C)] ->
> [signA signB witnessCbyA, revoke || (A && CSV)] /* held by A */
>
> [/*arbitrary*/, A && B] -> [signA signB, (revoke) || (A && B && C)] ->
> [signA signB witnessCbyB, revoke || (B && CSV)] /* held by B */
>
> Where (revoke) is the revocation key, whose derivation requires both A and
> B, and whose half is kept secret by the A (resp. B) until they both agree
> to revoke the old state.
>
> Of note is that the only additional condition added to C is (A && B),
> which makes sense since the contract is between nodes A and B (and which
> would be implicitly required by the funding transaction anyway). The
> (revoke) || does not affect the enforcement of C if the revocation key is
> not yet revealed; once the revocation key is revealed, that revokes the
> entire sequence of transactions (which is why (revoke) || appears in both
> the second and third transactions above). In particular, the
> CSV-encumberance does not affect claiming of C; it encumbers the claiming
> of the money, but does not interact with C itself. Thus, any CLTV
> conditions in C will not be interefered with by the CSV-encumberance on the
> *next* transaction.
>
> Note also that only signA and signB for the final transaction needs to be
> shared; the witnessC can presumably be fulfilled by each side themselves
> automatically.
>
> On the other hand, under Decker-Osuntokun-Russell eltoo, the transaction
> series is:
>
> [/*arbitrary*/, A && B] -> [signA signB, (CSV && A && B) || (CLTV && A &&
> B)] -> [nSequence signA signB, C]
>
> Now the above is massively simpler with no additional SCRIPT that needs to
> be written, around the transported contract C --- but the CSV in the second
> transaction, is now potentially interfering with the operation of the
> contract C, as the final transaction cannot be enforced onchain until the
> CSV has been satisfied. This is in contrast with the Poon-Dryja case,
> where the contract C appears immediately on the second transaction in the
> sequence, and can be enforced, as soon as it appears onchain.
>
> (In eltoo, the (CTLV && A && B) branch of the intermediate contract is the
> "update" path, and the CLTV required is always a past Unix Epoch time, so
> this CLTV cannot interfere with the contract C).
>
> The above consideration, is why I suppose that, *for arbitrary contracts*,
> Poon-Dryja is superior.
>
> Simply, the conclusion is that Decker-Osuntokun-Russell channels require a
> CSV that may interfere with the contract C if C is time-sensitive (i.e. has
> a CLTV or CSV itself), whereas Poon-Dryja requires CSV only for
> revocability, and the CSV cannot prevent the enforcement of time-sensitive
> C.
>
> Indeed, as I pointed out, even when transporting HTLCs,
> Decker-Osuntokun-Russell will require consideration of the CSV on top of
> the CLTV-deltas imposed by intermediary nodes, with weights complicated by
> the fact that CLTV-deltas are summed together but the highest CSV is added
> to the CLTV total, which does not mix well with typical route-finding
> algorithms (most of which assume a simple summing of costs, which
> CLTV-deltas use but CSVs on Decker-Osuntokun-Russell do not since highest
> is used).
>
> In almost all other ways, Poon-Dryja is inferior:
>
> 1. Does not use nLockTime in a sufficiently clever way.
> 2. Dangerous "toxic waste" (old revoked transactions) which (1) you
> should not recover from your backups and (2) you should not let your worst
> enemy find, because they can publish those onchain and make you LOSE MONEY.
> 3. Symmetrical chains of transactions, different for both parties,
> instead of a single chain.
>
> In addition, arbitrary contracts are not really particularly useful.
> HTLCs seem to me an important building block for digital value transfers,
> and they (and their equivalents under scriptless) are sufficient for most
> practical transfers. Thus, moving forward, Decker-Osuntokun-Russell
> remains a superior technology over Poon-Dryja.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
--
Michael Folkson
Email: michaelfolkson at gmail.com
Keybase: michaelfolkson
PGP: 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180801/47c76b51/attachment-0001.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2023-05-23
🗒️ Summary of this message: Michael questions if a CVE ID was requested properly for Bitcoin Core. He suggests better documentation and guidance for vulnerability reporting.
📝 Original message:Hi alicexbt
> It has been assigned CVE-2023-33297
Did you personally request the CVE ID? Say via here [0]? Did you confirm with someone listed on the vulnerability reporting process [1] for Bitcoin Core that it made sense to do that at this time? I'm not sure whether completely bypassing that list and requesting CVE IDs for the project as an individual is the way to go. If you have already contacted one of them and they've given you the go ahead to start the CVE process then fine. You weren't particularly clear with what has occurred.
Thanks
Michael
[0]: https://cve.mitre.org/cve/request_id.html
[1]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Monday, May 22nd, 2023 at 13:56, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Michael,
>
> > Now that's not to say you may not have a point about better documentation and guidance on what should go through the vulnerability reporting process and what shouldn't.
>
>
> Yes, this can be improved.
>
> > Or even that this particular issue could ultimately end up being classed a CVE.
>
>
> It has been assigned CVE-2023-33297
>
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, May 17th, 2023 at 6:14 PM, Michael Folkson michaelfolkson at protonmail.com wrote:
>
>
>
> > Hi alicexbt
> >
> > "Open source" has the word "open" in it. Pushing everything into closed, private channels of communication and select groups of individuals is what I've been trying to push back upon. As I said in my initial response "it doesn't scale for all bug reports and investigations to go through this tiny funnel" though "there are clearly examples where the process is critically needed".
> >
> > Now that's not to say you may not have a point about better documentation and guidance on what should go through the vulnerability reporting process and what shouldn't. Or even that this particular issue could ultimately end up being classed a CVE. But rather than merely complaining and putting "open source" into quote marks perhaps suggest what class of bug reports should go through the tiny funnel and what shouldn't. Unless you think everything should go through the funnel in which case you are advocating for less openness whilst simultaneously complaining it isn't "open source". Square that circle.
> >
> > Thanks
> > Michael
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> >
> > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> >
> > ------- Original Message -------
> > On Tuesday, May 16th, 2023 at 23:39, alicexbt alicexbt at protonmail.com wrote:
> >
> > > Hi Michael,
> > >
> > > A disagreement and some thoughts already shared in an email although its not clear to some "open source" devs:
> > >
> > > Impact of this vulnerability:
> > >
> > > - Denial of Service
> > > - Stale blocks affecting mining pool revenue
> > >
> > > Why it should have been reported privately to security at bitcoincore.org, even if initially found affecting only debug build?
> > >
> > > Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129
> > >
> > > CVE is a different process and I am aware of it. It would be good for certain developers in the core team to reflect on their own approach to security, regardless of whether their work receives CVE recognition or not.
> > >
> > > /dev/fd0
> > > floppy disk guy
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > ------- Original Message -------
> > > On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson michaelfolkson at protonmail.com wrote:
> > >
> > > > Hi alicexbt
> > > >
> > > > The vulnerability reporting process requires communication and resolution via a small group of individuals 0 rather than through open collaboration between any contributors on the repo. There are clearly examples where the process is critically needed, the most obvious past example being the 2018 inflation bug 1. However, it doesn't scale for all bug reports and investigations to go through this tiny funnel. For an issue that isn't going to result in loss of onchain funds and doesn't seem to present a systemic issue (e.g. network DoS attack, inflation bug) I'm of the view that opening a public issue was appropriate in this case especially as the issue initially assumed it was only impacting nodes running in debug mode (not a mode a node in production is likely to be running in).
> > > >
> > > > An interesting question though and I'm certainly happy to be corrected by those who have been investigating the issue. Some delicate trade-offs involved including understanding and resolving the issue faster through wider collaboration versus keeping knowledge of the issue within a smaller group.
> > > >
> > > > Thanks
> > > > Michael
> > > >
> > > > --
> > > > Michael Folkson
> > > > Email: michaelfolkson at protonmail.com
> > > > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> > > >
> > > > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
> > > >
> > > > ------- Original Message -------
> > > > On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> > > >
> > > > > Hi Bitcoin Developers,
> > > > >
> > > > > There is an open issue in bitcoin core repository which was created last week: https://github.com/bitcoin/bitcoin/issues/27586
> > > > >
> > > > > I think this should have been reported privately as vulnerability instead of creating a GitHub issue even if it worked only in debug mode. Some users in the comments have also experienced similar issues without debug build used for bitcoind. I have not noticed any decline in the number of listening nodes on bitnodes.io in last 24 hours so I am assuming this is not an issue with majority of bitcoin core nodes. However, things could have been worse and there is nothing wrong in reporting something privately if there is even 1% possibility of it being a vulnerability. I had recently reported something to LND security team based on a closed issue on GitHub which eventually was not considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449
> > > > >
> > > > > In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or try other things shared in the issue by everyone.
> > > > >
> > > > > This isn't the first time either when vulnerability was reported publicly: https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even exploited on mainnet which affected some projects.
> > > > >
> > > > > This email is just a request to consider the impact of any vulnerability if gets exploited could affect lot of things. Even the projects with no financial activity involved follow better practices.
> > > > >
> > > > > /dev/fd0
> > > > > floppy disk guy
> > > > >
> > > > > Sent with Proton Mail secure email.

2023-06-07 23:21:43

- reply

📅 Original date posted:2023-05-17
🗒️ Summary of this message: A discussion on the vulnerability reporting process in open source development, with a focus on the balance between open collaboration and the need for critical security issues to go through a small group of individuals.
📝 Original message:Hi alicexbt
"Open source" has the word "open" in it. Pushing everything into closed, private channels of communication and select groups of individuals is what I've been trying to push back upon. As I said in my initial response "it doesn't scale for all bug reports and investigations to go through this tiny funnel" though "there are clearly examples where the process is critically needed".
Now that's not to say you may not have a point about better documentation and guidance on what should go through the vulnerability reporting process and what shouldn't. Or even that this particular issue could ultimately end up being classed a CVE. But rather than merely complaining and putting "open source" into quote marks perhaps suggest what class of bug reports should go through the tiny funnel and what shouldn't. Unless you think everything should go through the funnel in which case you are advocating for less openness whilst simultaneously complaining it isn't "open source". Square that circle.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Tuesday, May 16th, 2023 at 23:39, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Michael,
>
> A disagreement and some thoughts already shared in an email although its not clear to some "open source" devs:
>
> Impact of this vulnerability:
>
> - Denial of Service
> - Stale blocks affecting mining pool revenue
> Why it should have been reported privately to security at bitcoincore.org, even if initially found affecting only debug build?
>
> Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129
>
> CVE is a different process and I am aware of it. It would be good for certain developers in the core team to reflect on their own approach to security, regardless of whether their work receives CVE recognition or not.
>
> /dev/fd0
> floppy disk guy
>
> Sent with [Proton Mail](https://proton.me/) secure email.
>
> ------- Original Message -------
> On Friday, May 12th, 2023 at 1:14 AM, Michael Folkson <michaelfolkson at protonmail.com> wrote:
>
>> Hi alicexbt
>>
>> The vulnerability reporting process requires communication and resolution via a small group of individuals [0] rather than through open collaboration between any contributors on the repo. There are clearly examples where the process is critically needed, the most obvious past example being the 2018 inflation bug [1]. However, it doesn't scale for all bug reports and investigations to go through this tiny funnel. For an issue that isn't going to result in loss of onchain funds and doesn't seem to present a systemic issue (e.g. network DoS attack, inflation bug) I'm of the view that opening a public issue was appropriate in this case especially as the issue initially assumed it was only impacting nodes running in debug mode (not a mode a node in production is likely to be running in).
>>
>> An interesting question though and I'm certainly happy to be corrected by those who have been investigating the issue. Some delicate trade-offs involved including understanding and resolving the issue faster through wider collaboration versus keeping knowledge of the issue within a smaller group.
>>
>> Thanks
>> Michael
>>
>> [0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
>> [1]: https://bitcoincore.org/en/2018/09/20/notice/
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Bitcoin Developers,
>>>
>>> There is an open issue in bitcoin core repository which was created last week: https://github.com/bitcoin/bitcoin/issues/27586
>>>
>>> I think this should have been reported privately as vulnerability instead of creating a GitHub issue even if it worked only in debug mode. Some users in the comments have also experienced similar issues without debug build used for bitcoind. I have not noticed any decline in the number of listening nodes on bitnodes.io in last 24 hours so I am assuming this is not an issue with majority of bitcoin core nodes. However, things could have been worse and there is nothing wrong in reporting something privately if there is even 1% possibility of it being a vulnerability. I had recently reported something to LND security team based on a closed issue on GitHub which eventually was not considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449
>>>
>>> In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or try other things shared in the issue by everyone.
>>>
>>> This isn't the first time either when vulnerability was reported publicly: https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even exploited on mainnet which affected some projects.
>>>
>>> This email is just a request to consider the impact of any vulnerability if gets exploited could affect lot of things. Even the projects with no financial activity involved follow better practices.
>>>
>>> /dev/fd0
>>> floppy disk guy
>>>
>>> Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230517/519f60b6/attachment-0001.html>

2023-06-07 23:21:42

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: The process of reporting vulnerabilities in Bitcoin Core through a small group of individuals may not be scalable for all bug reports, and public reporting may be appropriate in some cases. Delicate trade-offs exist between wider collaboration and keeping knowledge of the issue within a smaller group.
📝 Original message:Hi alicexbt
The vulnerability reporting process requires communication and resolution via a small group of individuals [0] rather than through open collaboration between any contributors on the repo. There are clearly examples where the process is critically needed, the most obvious past example being the 2018 inflation bug [1]. However, it doesn't scale for all bug reports and investigations to go through this tiny funnel. For an issue that isn't going to result in loss of onchain funds and doesn't seem to present a systemic issue (e.g. network DoS attack, inflation bug) I'm of the view that opening a public issue was appropriate in this case especially as the issue initially assumed it was only impacting nodes running in debug mode (not a mode a node in production is likely to be running in).
An interesting question though and I'm certainly happy to be corrected by those who have been investigating the issue. Some delicate trade-offs involved including understanding and resolving the issue faster through wider collaboration versus keeping knowledge of the issue within a smaller group.
Thanks
Michael
[0]: https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
[1]: https://bitcoincore.org/en/2018/09/20/notice/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Tuesday, May 9th, 2023 at 03:47, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,
>
> There is an open issue in bitcoin core repository which was created last week: https://github.com/bitcoin/bitcoin/issues/27586
>
> I think this should have been reported privately as vulnerability instead of creating a GitHub issue even if it worked only in debug mode. Some users in the comments have also experienced similar issues without debug build used for bitcoind. I have not noticed any decline in the number of listening nodes on bitnodes.io in last 24 hours so I am assuming this is not an issue with majority of bitcoin core nodes. However, things could have been worse and there is nothing wrong in reporting something privately if there is even 1% possibility of it being a vulnerability. I had recently reported something to LND security team based on a closed issue on GitHub which eventually was not considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449
>
> In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or try other things shared in the issue by everyone.
>
> This isn't the first time either when vulnerability was reported publicly: https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even exploited on mainnet which affected some projects.
>
> This email is just a request to consider the impact of any vulnerability if gets exploited could affect lot of things. Even the projects with no financial activity involved follow better practices.
>
> /dev/fd0
> floppy disk guy
>
> Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230511/021610dd/attachment.html>

2023-06-07 23:21:28

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: During high fee spikes, it may be beneficial to close Lightning channels and move value on-chain, even if the fee is higher than the amount received. This is not recommended but could be allowed in consensus rules.
📝 Original message:> im unclear as to the purposepaying an onchain transaction fee greater than the amount receiving could possibly serve.
If you expect fees to continue to rise and be sustained at abnormally high levels for a long period of time you might seek to close your Lightning channel(s) and move whatever value you can from these Lightning channel(s) onchain even if it means paying a higher fee than the amount you are receiving.
I don't necessarily recommend doing this (it would depend on a number of factors, both personal and external) but there is no reason to prevent someone in say the consensus rules from doing this if they wish.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Monday, May 8th, 2023 at 20:47, Erik Aronesty <erik at q32.com> wrote:
> im unclear as to the purpose paying an onchain transaction fee greater than the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <michaelfolkson at protonmail.com> wrote:
>
>>> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>>
>> And prevent perfectly reasonable transfers of value and attempted Lightning channel closes during fee spikes? If I want to close my Lightning channel during a protracted fee spike where I have to pay an onchain transaction fee greater than the amount I am receiving you want to stop me doing that? You are impinging on a valid use case as well as requiring a consensus rule change.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>>>
>>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I think everyone on this list knows what has happened to the Bitcoin mempool during the past 96 hours. Due to side projects such as BRC-20 having such a high volume, real bitcoin transactions are being priced out and that is what is causing the massive congestion that has arguable not been seen since December 2017. I do not count the March 2021 congestion because that was only with 1-5sat/vbyte.
>>>>
>>>> Such justifiably worthless ("worthless" is not even my word - that's how its creator described them[1]) tokens threaten the smooth and normal use of the Bitcoin network as a peer-to-pear digital currency, as it was intended to be used as.
>>>>
>>>> If the volume does not die down over the next few weeks, should we take an action? The bitcoin network is a triumvirate of developers, miners, and users. Considering that miners are largely the entities at fault for allowing the system to be abused like this, the harmony of Bitcoin transactions is being disrupted right now. Although this community has a strong history of not putting its fingers into pies unless absolutely necessary - an example being during the block size wars and Segwit - should similar action be taken now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?
>>>>
>>>> An alternative would be to enforce this "censorship" at the node level and introduce a run-time option to instantly prune all non-standard Taproot transactions. This will be easier to implement, but won't hit the road until minimum next release.
>>>>
>>>> I know that some people will have their criticisms about this, absolutists/libertarians/maximum-freedom advocates, which is fine, but we need to find a solution for this that fits everyone's common ground. We indirectly allowed this to happen, which previously wasn't possible before. So we also have a responsibility to do something to ensure that this kind of congestion can never happen again using Taproot.
>>>>
>>>> -Ali
>>>>
>>>> ---
>>>>
>>>> [1]: [https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/41755b0a/attachment-0001.html>

2023-06-07 23:21:26

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Rejecting transactions with fees higher than the sum of outputs may prevent valid use cases and Lightning channel closures during fee spikes.
📝 Original message:> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
And prevent perfectly reasonable transfers of value and attempted Lightning channel closes during fee spikes? If I want to close my Lightning channel during a protracted fee spike where I have to pay an onchain transaction fee greater than the amount I am receiving you want to stop me doing that? You are impinging on a valid use case as well as requiring a consensus rule change.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> probably easier just to reject any transaction where the fee is higher than the sum of the outputs
>
> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi guys,
>>
>> I think everyone on this list knows what has happened to the Bitcoin mempool during the past 96 hours. Due to side projects such as BRC-20 having such a high volume, real bitcoin transactions are being priced out and that is what is causing the massive congestion that has arguable not been seen since December 2017. I do not count the March 2021 congestion because that was only with 1-5sat/vbyte.
>>
>> Such justifiably worthless ("worthless" is not even my word - that's how its creator described them[1]) tokens threaten the smooth and normal use of the Bitcoin network as a peer-to-pear digital currency, as it was intended to be used as.
>>
>> If the volume does not die down over the next few weeks, should we take an action? The bitcoin network is a triumvirate of developers, miners, and users. Considering that miners are largely the entities at fault for allowing the system to be abused like this, the harmony of Bitcoin transactions is being disrupted right now. Although this community has a strong history of not putting its fingers into pies unless absolutely necessary - an example being during the block size wars and Segwit - should similar action be taken now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?
>>
>> An alternative would be to enforce this "censorship" at the node level and introduce a run-time option to instantly prune all non-standard Taproot transactions. This will be easier to implement, but won't hit the road until minimum next release.
>>
>> I know that some people will have their criticisms about this, absolutists/libertarians/maximum-freedom advocates, which is fine, but we need to find a solution for this that fits everyone's common ground. We indirectly allowed this to happen, which previously wasn't possible before. So we also have a responsibility to do something to ensure that this kind of congestion can never happen again using Taproot.
>>
>> -Ali
>>
>> ---
>>
>> [1]: [https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/c13a41a2/attachment-0001.html>

2023-06-07 23:21:25

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Miners are not at fault for high fees and congestion in Bitcoin transactions; it's a technical issue with limited block space and variable demand. Solutions are difficult and require consensus.
📝 Original message:Hi Ali
I'd point you to Andrew Poelstra's post from January 2023 [0] and a Bitcoin StackExchange answer I recently posted [1].
> Considering that miners are largely the entities at fault for allowing the system to be abused like this, the harmony of Bitcoin transactions is being disrupted right now.
Miners are as far as I understand including high fee rate, consensus compatible transactions in mined blocks as the system has been set up for them to do. As I say in that StackExchange answer if you don't like it:
"There are theoretically two options: a consensus change or a policy change. A consensus change disallowing a certain kind of transaction that is acceptable under current consensus rules would need a soft fork and hence would be extremely difficult to pull off assuming that it was a considered a good idea by the broader community. Embedding arbitrary data in transactions would still be possible after this hypothetical soft fork and so its effectiveness would be limited. A default policy change (or custom policy option) would attempt to prevent a certain kind of transaction from propagating across the network without needing a consensus change. However, it would still be possible to submit these kinds of consensus compatible transactions directly to miners bypassing the P2P network."
> I know that some people will have their criticisms about this, absolutists/libertarians/maximum-freedom advocates, which is fine, but we need to find a solution for this that fits everyone's common ground. We indirectly allowed this to happen, which previously wasn't possible before. So we also have a responsibility to do something to ensure that this kind of congestion can never happen again using Taproot.
It isn't a philosophy or ideology consideration, it is a purely technical one. Congestion can happen using Taproot addresses or pre-Taproot addresses. There is fixed, limited block space and variable demand for that block space. You may not like how that block space is being used but if transactions are consensus compatible and paying fees at the market rate the system is working how it should.
> to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?
There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [0]:
"If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).
But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable."
I personally get the desire to "do something". Fee spikes aren't fun especially for some Lightning use cases and many of us don't like how people are using the limited block space currently. But a game of whack-a-mole with blunt tools such as policy rules and especially consensus rules is ineffective at best and harmful at worst. You may not like this use case but assuming you embark on a game of whack-a-mole what's to stop a group of people popping up in a year declaring their opposition to your use case and trying to prevent your use case? Consensus rules are set and the rest is left to the market.
Thanks
Michael
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html
[1]: https://bitcoin.stackexchange.com/questions/118197/ddos-attack-via-brc-20-ordinals-on-bitcoin
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Sunday, May 7th, 2023 at 18:22, Ali Sherief via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi guys,
>
> I think everyone on this list knows what has happened to the Bitcoin mempool during the past 96 hours. Due to side projects such as BRC-20 having such a high volume, real bitcoin transactions are being priced out and that is what is causing the massive congestion that has arguable not been seen since December 2017. I do not count the March 2021 congestion because that was only with 1-5sat/vbyte.
>
> Such justifiably worthless ("worthless" is not even my word - that's how its creator described them[1]) tokens threaten the smooth and normal use of the Bitcoin network as a peer-to-pear digital currency, as it was intended to be used as.
>
> If the volume does not die down over the next few weeks, should we take an action? The bitcoin network is a triumvirate of developers, miners, and users. Considering that miners are largely the entities at fault for allowing the system to be abused like this, the harmony of Bitcoin transactions is being disrupted right now. Although this community has a strong history of not putting its fingers into pies unless absolutely necessary - an example being during the block size wars and Segwit - should similar action be taken now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?
>
> An alternative would be to enforce this "censorship" at the node level and introduce a run-time option to instantly prune all non-standard Taproot transactions. This will be easier to implement, but won't hit the road until minimum next release.
>
> I know that some people will have their criticisms about this, absolutists/libertarians/maximum-freedom advocates, which is fine, but we need to find a solution for this that fits everyone's common ground. We indirectly allowed this to happen, which previously wasn't possible before. So we also have a responsibility to do something to ensure that this kind of congestion can never happen again using Taproot.
>
> -Ali
>
> ---
>
> [1]: [https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/6643e7e1/attachment-0001.html>

2023-06-07 23:21:21

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Anonymous sources expressed discomfort with Vasil being P2P maintainer, citing his work quality and lack of in-depth reviews compared to ryanofsky. Public discussions invite abuse towards contributors, leading to private settings. The decision to remove Vasil was communicated poorly, but maintainers stand by it.
📝 Original message:Thanks for this Andrew.
> However I later spoke to a few others privately who were more familiar with Vasil's work and they had told me that they were not comfortable with Vasil being P2P maintainer.
Some individuals who will stay anonymous and who were more familiar with Vasil's work than you weren't happy with the standard of his work. Ok I hope they have communicated this to him directly and provided specific examples where he can improve.
> From having received plenty of reviews from ryanofsky, I can certainly say that his reviews are in depth. He has pointed out subtle bugs, asks questions about very low level details, and has well reasoned critiques and discussions about design decisions.
And Vasil didn't provide as in depth reviews when compared to ryanofsky. Again I hope they have communicated this to him directly.
> Many cited your behavior as a primary reason to stop discussing things publicly, with things such as dragging project meta discussions onto the mailing list and twitter. These have invited abuse towards maintainers and contributors, which in turn makes them takes those discussions to more private settings. People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
I have tried over and over again on IRC and on GitHub and I've been ignored. To claim discussions on the bitcoin-dev mailing list invite abuse is just laughable. It is public just like IRC logs and GitHub. If people don't like discussing in public we should give up the pretense and put on the Core README that all important discussions on decision making are done in private and are invite only.
> People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
This is the "rude" and "aggressive" accusation, right. Someone asks questions that maintainers don't want to answer, maintainers accuse them of being "rude" and "aggressive" and then use that as a justification for not answering those questions in the first place. It is a pretty effective strategy. Don't even need to provide examples, just label them and then you can ignore them.
> Since you are intent on discussing and re-litigating the decision about Vasil, I will agree that we (the maintainers) could have done a better job of communicating. However we stand by the decision that was made in the end, and we did have a chat with him about it during CoreDev.
Thanks for at least admitting this on the communication point. If Vasil has been spoken to and is happy with the situation then the situation is much better than I feared. You might think this is re-litigating but the addition, rejection and removal of maintainers is among the most important decisions you can make as a maintainer and perhaps only dwarfed by the merging of consensus changes that can cause chain splits. If anything should be "re-litigated" it should be this.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 22:24, Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>> The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a maintainer has always been made by existing maintainers. When the maintainers feel that there is a need for additional maintainers, they may have an open call for volunteers, or may have a candidate already in mind and suggest that specific person for maintainership. Contributors generally are not consulted in the decision to seek a new maintainer as they would not know whether there are things that are being overlooked or that there is maintainership load that needs to be distributed. Even so, it wouldn't be appropriate to add a maintainer if many contributors disagreed with it, just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this has played out in the past. I think our modern concept of maintainers with nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and Marco Falke were simply announced by Wladimir. There was no public discussion, and some IRC logs refer to private emails between the them and the current maintainers at that time. After that, meshcollider was added as a maintainer after a public "call for maintainers" where a recurring topic for a while was finding a maintainer for the wallet. He had volunteered to do it by contacting Wladimir privately before it was discussed during an IRC meeting and then on Github. Fanquake was added as a maintainer during a CoreDev event in Amsterdam during a discussion initiated and led by the maintainers. This was also "private" insofar as the discussion was limited to those in attendance, although there was some opportunity for public discussion in the PR opened on Github. For myself, it was also initially private as I messaged Wladimir to volunteer for it after meshcollider stepped down. There was some discussion on IRC and on Github, but it was also obvious that many already expected me to be the wallet maintainer after meshcollider. Hebasto was added with basically no fanfare or discussion - the only mention I can find is the PR itself. My understanding is that the maintainers asked him he wanted to do it before the PR was opened. Glozow was nominated to be a maintainer by some of the current maintainers, and her nomination was really the first time that there was significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from the current maintainers, one was volunteering following an actual "call for maintainer", and one was an obvious successor. It's obvious and common sense that the maintainers decide when they need help shouldering the load, and then find somebody to help them. There was and always will be some level of private communication prior to any public announcement of the nomination or volunteering of a maintainer. It doesn't make sense to blindside somebody with a nomination without talking to them beforehand. The fact that most of these were non-controversial speaks to how well the maintainers were considering their nominations before publicly announcing them.
>
> It's also clear that we have been moving towards more open discussion about maintainership and who should be maintainers. The process is fundamentally more public than it was previously. We now have public discussion with contributors about the merits of a person, even if that results in said person not becoming a maintainer. Over time, there's been more public participation in the PRs and on IRC meetings when maintainer nominations are brought up. We have nominations as topics during meetings now when they occur. The PRs to add keys are left open for longer to get more discussion.
>
> Ultimately, if you disagree with how the project operates, then you are free to leave and start your own fork that is run in a way that you think is appropriate. This is open source software, no one is beholden to you, and no one is required to do anything.
>
> ***
>
> Since you are intent on discussing and re-litigating the decision about Vasil, I will agree that we (the maintainers) could have done a better job of communicating. However we stand by the decision that was made in the end, and we did have a chat with him about it during CoreDev.
>
> It really boils down to three things: 1) we did not ask for a P2P maintainer, 2) some of those who have reviewed Vasil's work expressed discomfort with him being a maintainer, and 3) some contributors and maintainers were uncomfortable with his responses about how he would merge things. You repeatedly insist that it's only the current maintainers who blocked Vasil, but that is not the case. There were concerns brought up by other contributors that contributed to the decision to ultimately NACK his nomination.
>
>> One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]:
>
> To be honest, my initial ACK was given without knowing enough information. It was given when he was mostly a name that showed up in my notification emails, and his work had seemed to be fine with me. At that time, I did not think we had a need for a P2P maintainer, but I also did not think that having one would be harmful. However I later spoke to a few others privately who were more familiar with Vasil's work and they had told me that they were not comfortable with Vasil being P2P maintainer.
>
>> “Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).”
>>
>> I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done.
>
> This opinion was formed not from observing his behavior towards ACK'ing, but rather from his responses to questions about reviewing, in addition to thoughts shared by other contributors.
>
> From having received plenty of reviews from ryanofsky, I can certainly say that his reviews are in depth. He has pointed out subtle bugs, asks questions about very low level details, and has well reasoned critiques and discussions about design decisions. His reviews are high quality, and he's not afraid of being the first person to ACK a pr, the last person to ACK it, or the person to prevent one from being merged even when it already has a few ACKs. We also had a separate discussion with ryanofsky about his approaches to reviewing and merging.
>
>> “I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer”
>>
>> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>
> I don't know why you assume the ryanofsky hasn't had this maintainer attitude? Your claim of inconsistency stems from this assumption that ryanofsky doesn't have a maintainer attitude, but I would argue that he does, as I mentioned above. The idea of adding him as a maintainer has been floated around before, although never really seriously proposed until now, AFAIK.
>
>> When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer?
>
> It seems obvious to me that when the current maintainers approach and nominate a contributor to be a maintainer that that person already meets these requirements. I don't know why you would assume bad faith in that someone who isn't qualified would be nominated by the current maintainers. It's quite frustrating that you seem to just jump straight to the negative conclusion rather than considering that there might be actual reasons based on the merits of the person.
>
>> On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project.
>
> Don't take credit for what you didn't do. The group-wide effort to move towards public discussion again is the result of a discussion that was had at CoreDev. Many cited your behavior as a primary reason to stop discussing things publicly, with things such as dragging project meta discussions onto the mailing list and twitter. These have invited abuse towards maintainers and contributors, which in turn makes them takes those discussions to more private settings. People feel like they're getting sealioned by you (and a few others) when they post publicly, and so they have stopped doing so.
>
> Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230511/54ab6d65/attachment-0001.html>

2023-06-07 23:21:19

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: The process for blocking Vasil and approving Russ as maintainers in Bitcoin Core was different, with Vasil's PR being kept open for months with no explanation, while Russ's was approved within two days.
📝 Original message:> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one agrees or disagrees, the same process is being used. Anyone can NACK and give a reason for Russ as well.
With respect Steve the process for Vasil was keeping Vasil's PR open for up to 5 months with zero NACKs and two maintainers refusing to engage on why it wasn't being merged or what it needed for it to be merged. Followed by a later justification for blocking it that they've refused to discuss whether it applies to Russ.
The process for Russ was the maintainers deciding privately there was a need for a maintainer "who understood our interfaces and modularization efforts well" and his PR was merged within 2 days.
If that's the same process to you I don't know what to say. We have different perspectives on what constitutes a decision process.
(I'm sure this is clear but just to reiterate in case it isn't none of this is a criticism of Russ.)
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 17:36, Steve Lee <steven.j.lee at gmail.com> wrote:
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one agrees or disagrees, the same process is being used. Anyone can NACK and give a reason for Russ as well.
>
> On Wed, May 10, 2023 at 8:55 AM Michael Folkson <michaelfolkson at protonmail.com> wrote:
>
>> Hi Steve
>>
>>> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604
>>
>> Nope. The extent to which the rationale for blocking Vasil as a maintainer applies or doesn't apply to ryanofsky (or future potential maintainers) isn't discussed. From now on the precedent is proposed maintainers can be blocked for unknown and/or potentially inconsistent reasons by the existing maintainers.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604
>>>
>>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>>>> Essentially my concern is going forward current maintainers will
>>>>>> decide which proposed new maintainers to add and which to block.
>>>>>
>>>>> This is how a large percentage of organizations are run. The current
>>>>> members of a board or other governance group choose who will become a
>>>>> new board member.
>>>>
>>>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of independent contributors merging different pull requests or patches. The github controls are merely because that is how github works. There is also a secondary issue of people tending to confuse Bitcoin Core with the bitcoin protocol in general:
>>>> https://blog.lopp.net/who-controls-bitcoin-core/
>>>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>>>
>>>> - Bryan
>>>> https://twitter.com/kanzure
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230510/02964e68/attachment-0001.html>

2023-06-07 23:21:19

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: The concern is that the precedent has been set for existing maintainers to block proposed maintainers for unknown and/or potentially inconsistent reasons.
📝 Original message:Hi Steve
> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604
Nope. The extent to which the rationale for blocking Vasil as a maintainer applies or doesn't apply to ryanofsky (or future potential maintainers) isn't discussed. From now on the precedent is proposed maintainers can be blocked for unknown and/or potentially inconsistent reasons by the existing maintainers.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Isn't this as simple as anyone (in particular Core project contributors) can express their view in this PR? https://github.com/bitcoin/bitcoin/pull/27604
>
> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>> Essentially my concern is going forward current maintainers will
>>>> decide which proposed new maintainers to add and which to block.
>>>
>>> This is how a large percentage of organizations are run. The current
>>> members of a board or other governance group choose who will become a
>>> new board member.
>>
>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of independent contributors merging different pull requests or patches. The github controls are merely because that is how github works. There is also a secondary issue of people tending to confuse Bitcoin Core with the bitcoin protocol in general:
>> https://blog.lopp.net/who-controls-bitcoin-core/
>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>
>> - Bryan
>> https://twitter.com/kanzure
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230510/4e8ac883/attachment.html>

2023-06-07 23:21:18

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A contributor expresses concern that maintainers are making decisions without input from long-term contributors, and blocking potential maintainers without explanation. They believe decisions should be discussed in public meetings.
📝 Original message:Hi David
>> Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block.
> This is how a large percentage of organizations are run. The current members of a board or other governance group choose who will become a new board member.
So long term contributors who aren't maintainers don't get input into the decision? It is starting to seem like the maintainer role is moving from a janitorial one to where maintainers make decisions without discussing those decisions with long term contributors and in some cases even bothering to explain the rationale for those decisions to a broader audience that includes long term contributors. This unfortunately makes the decision on who becomes a maintainer even more important.
Decisions have to be made but I was always under the impression that they would be discussed in open, public IRC meetings with at least other long term contributors present and then decisions would be made based on the views expressed in that meeting. An appointed board or governance group ("the maintainers") wasn't how I thought the project was run or should be run.
> Finally, I don't think this matter warranted a post to this mailing list. Discussion about internal project decisions, such as who should have merge access and what maintainers should communicate in PRs, belong in communication channels dedicated to that project.
I have tried. As I said in previous emails in the Vasil maintainer case I asked fanquake, Gloria repeatedly over a period of 5 months why Vasil was being blocked. They refused to comment. I get called "rude" and "aggressive" for asking. So I'd rather post my thoughts and observations here than risk being accused of being "rude" and "aggressive" again for asking questions on this topic on IRC. Especially as I expect they'll be ignored anyway as they were in last week's Core Dev IRC meeting.
Until the Vasil situation I thought that we had a common sense approach of any long term contributor who had demonstrated they could add value to the project and had shown good temperament could become a maintainer. Blocking Vasil as a maintainer was a red flag for me that we no longer have that. And fanquake, Gloria not being willing to discuss why publicly for 5 months was a second red flag. If that is the precedent for merge decisions anything is possible in the future including in the worst case contentious consensus change merges with no justification and no rationale.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Sunday, May 7th, 2023 at 18:35, David A. Harding <dave at dtrt.org> wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
>
> This is how a large percentage of organizations are run. The current
> members of a board or other governance group choose who will become a
> new board member.
>
> One alternative to self-perpetuating governance is membership voting,
> but building and maintaining democratic institutions is hard and not a
> good fit for many types of endeavors---the building of highly technical
> software being one of those cases IMO.
>
> I think the questions we want to ask is whether the current set of
> maintainers is capable of moving Bitcoin Core in the direction we want
> and what we can do about it if we conclude that they are ill-suited (or
> malicious). For the first question, I think that's something everyone
> needs to answer for themselves, as we may each have different visions
> for the future of the project. That said, I note that several
> initiatives championed by the current maintainers in the IRC meeting you
> mention received overwhelmingly positive support from a significant
> number of current contributors, which seems like a healthy sign to me.
>
> For the second question, I think AJ Towns already answered that quite
> well (though he was talking about a different project):
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021578.html
>
> Finally, I don't think this matter warranted a post to this mailing
> list. Discussion about internal project decisions, such as who should
> have merge access and what maintainers should communicate in PRs, belong
> in communication channels dedicated to that project.
>
> -Dave

2023-06-07 23:21:17

- reply

📅 Original date posted:2023-05-07
🗒️ Summary of this message: Bitcoin Core has proposed a new maintainer, ryanofsky, who has received multiple ACKs. Concerns have been raised about the decision-making process for adding new maintainers.
📝 Original message:There has been a proposed new maintainer on Bitcoin Core (ryanofsky). In the Core dev IRC meeting [0] yesterday it received multiple ACKs.
The decision process for adding a new maintainer was according to the IRC meeting that the maintainers decided privately there was a need for a maintainer “who understood our interfaces and modularization efforts well” and that ryanofsky was a “good fit for that”. I don’t know whether this was decided in a private IRC channel or was decided at the recent in person Core Dev meeting. Regardless, many have had no input into the discussion on what kind of maintainer the project needs going forward and it seems the maintainers do not want to discuss that aspect of the decision.
I posted a couple of questions in advance [1] of the meeting (I was unable to attend) that remained unanswered during the meeting. Essentially my concern is going forward current maintainers will decide which proposed new maintainers to add and which to block. If you aren’t anointed by the current maintainers you won’t get added as a maintainer and a half baked rationale will be provided to justify that decision. Longer term this will determine the pull requests that will ultimately get merged and which don't get merged because maintainers merge pull requests.
One of the justifications for blocking Vasil Dimov as a new maintainer despite many initial ACKs from maintainers (including Andrew Chow) and long term contributors was according to Andrew [2]:
“Maintainers inherently need to look at the things that everyone else has already looked at, if only to give it a final once over before merging (but hopefully, an actual review, not just looking it over).”
I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky do this any more than Vasil does. This is not a criticism of ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get pretty annoying if everyone who wasn’t a maintainer posted an ACK once many long term contributors had already ACKed to display supposed “desired maintainer traits”. Especially if you are essentially just ACKing that others have done the work to review the PR and you just want to get your ACK on it to increase your ACK count without doing a fraction of what previous reviewers have done.
“I also want to mention that the people who have become maintainers in the past have had this kind of maintainer attitude towards review prior to becoming a maintainer”
Assuming ryanofsky hasn’t had this maintainer attitude in the past (again not a criticism from me at least) does this mean this was a reason to block Vasil but not a reason to block ryanofsky? That seems inconsistent to me. When you’re anointed you don’t need to meet requirements but when you’re blocked these requirements will be used to block your addition as a new maintainer?
For what it is worth from a personal perspective I don’t see any reason for blocking ryanofsky as a maintainer especially if there is broad agreement amongst maintainers and long term contributors that we need a new maintainer who understands interfaces and modularization on the project. For that framing ryanofsky perfectly meets those requirements. But once again the (public) discussion element on the addition of maintainers is essentially a façade, a framing for what the new maintainer needs to be has been decided in advance (in private) and an anointed individual who just so happens to align with that convenient framing will get added as a new maintainer.
On a more positive note there does seem to be more energy and momentum for collaboration and open communication on the project since I discussed communication in a previous post [3]. Hopefully this will continue. It doesn’t address my concerns on maintainers and ultimately merge decisions but it definitely seems to me to be a step in a positive direction for the project.
[0]: https://gnusha.org/bitcoin-core-dev/2023-05-04.log
[1]: https://gnusha.org/bitcoin-core-dev/2023-05-01.log
[2]: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1382334059
[3]:https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021565.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Tuesday, April 18th, 2023 at 13:40, Michael Folkson <michaelfolkson at protonmail.com> wrote:
> Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>
> A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
>
> Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.
>
> I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
>
> As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
>
> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>
> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>
> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>
> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>
> [4]: https://utxos.org/signals/
>
> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>
> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230507/5230485a/attachment-0001.html>

2023-06-07 23:21:10

- reply

📅 Original date posted:2023-05-01
🗒️ Summary of this message: A proposal to add new opcode functionality to existing scripts with no deeper introspection needed, similar to APO and CTV proposals.
📝 Original message:Hi Salvatore
Can you clarify for me which bucket this proposal sits? We have APO, CTV, OP_VAULT etc that are proposals to add additional functionality to SegWit version 1, Tapleaf version 0 scripts. We have Simplicity that would need a new Tapleaf version (e.g. Tapleaf version 1). And then there are CISA like proposals that would need a new SegWit version (e.g. SegWit version 2). It looks to me like your proposal is in the first bucket (same as APO, CTV etc) as it is just introducing new opcode functionality to existing script with no deeper introspection needed but previous and current discussion of fraud proofs, MATT frameworks etc made me initially think it was going to require more than that.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
------- Original Message -------
On Monday, April 24th, 2023 at 20:37, Salvatore Ingala via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello list,
>
> TL;DR: the core opcodes of MATT can build vaults with a very similar design
> to OP_VAULT. Code example here:
>
> https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
>
> In my previous emails about the MATT proposal for smart contracts in
> bitcoin [1], I mostly focused on proving its generality; that is, it
> allows arbitrary smart contracts thanks to fraud proofs.
>
> While I still find this "completeness" result compelling, I spent more time
> thinking about the framework itself; the construction is not very interesting
> if it turns simple things into complicated ones. Luckily, this is not the case.
> In particular, in this email we will not merkleize anything (other than taptrees).
>
> This post describes some progress into formalizing the semantics of the core
> opcodes, and demonstrates how they could be used to create vaults that seem
> comparable to the ones built with OP_VAULT [2], despite using general purpose
> opcodes.
>
> An implementation and some minimal tests matching the content of this
> e-mail can be found in the link above, using the bitcoin-inquisition as the
> base branch.
>
> Note that the linked code is not well tested and is only intended for
> exploratory and demonstrative purposes; therefore, bugs are likely at this
> stage.
>
> ##########################
> # PART 1: MATT's core
> ##########################
>
> In this section, I will discuss plausible semantics for the core opcodes for MATT.
>
> The two core opcodes are defined below as OP_CHECKINPUTCONTRACTVERIFY and
> OP_CHECKOUTPUTCONTRACTVERIFY.
>
> (the initial posts named them OP_CHECK{INPUT,OUTPUT}COVENANTVERIFY)
>
> They enhance Script with the following capabilities:
> - decide the taptree of the output
> - embed some (dynamically computed) data in the output
> - access the embedded data in the current UTXO (if any)
>
> The opcodes below are incomplete, as they only control the output's Script and
> not the amounts; more on that below.
>
> Other than that, the semantics should be quite close to the "right" one for
> the MATT framework.
>
> ### The opcodes
>
> case OP_CHECKINPUTCONTRACTVERIFY:
> {
> // OP_CHECKINPUTCONTRACTVERIFY is only available in Tapscript
> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> // (x d -- )
> if (stack.size() < 2)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> valtype& x = stacktop(-2);
> valtype& d = stacktop(-1);
> if (x.size() != 32 || d.size() != 32)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> const XOnlyPubKey nakedXOnlyKey{Span<const unsigned char>{x.data(), x.data() + 32}};
> const uint256 data(d);
> if (!execdata.m_internal_key.has_value())
> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
> // Verify that tweak(lift_x(x), d) equals the internal pubkey
> if (!execdata.m_internal_key.value().CheckDoubleTweak(nakedXOnlyKey, &data, nullptr))
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> popstack(stack);
> popstack(stack);
> }
> break;
> case OP_CHECKOUTPUTCONTRACTVERIFY:
> {
> // OP_CHECKOUTPUTCONTRACTVERIFY is only available in Tapscript
> if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> // (out_i x taptree d -- )
> if (stack.size() < 4)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> int out_i = CScriptNum(stacktop(-4), fRequireMinimal).getint();
> valtype& x = stacktop(-3);
> valtype& taptree = stacktop(-2);
> valtype& d = stacktop(-1);
> auto outps = checker.GetTxvOut();
> // Return error if the evaluation context is unavailable
> if (!outps)
> return set_error(serror, SCRIPT_ERR_UNKNOWN_ERROR); // TODO
> if (x.size() != 32 || taptree.size() != 32 || (d.size() != 0 && d.size() != 32))
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> if (out_i < 0 || out_i >= (int)outps->size())
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
> const XOnlyPubKey nakedXOnlyKey{Span<const unsigned char>{x.data(), x.data() + 32}};
> const uint256 data(d);
> const uint256 *data_ptr = (d.size() == 0 ? nullptr : &data);
> const uint256 merkle_tree(taptree);
> CScript scriptPubKey = outps->at(out_i).scriptPubKey;
> if (scriptPubKey.size() != 1 + 1 + 32 || scriptPubKey[0] != OP_1 || scriptPubKey[1] != 32)
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> const XOnlyPubKey outputXOnlyKey{Span<const unsigned char>{scriptPubKey.data() + 2, scriptPubKey.data() + 34}};
> // Verify that taptweak(tweak(lift_x(x), d), taptree) equals the internal pubkey
> if (!outputXOnlyKey.CheckDoubleTweak(nakedXOnlyKey, data_ptr, &merkle_tree))
> return set_error(serror, SCRIPT_ERR_WRONGCONTRACTDATA);
> popstack(stack);
> popstack(stack);
> popstack(stack);
> popstack(stack);
> }
> break;
>
> ### Commentary
>
> CheckDoubleTweak function (implemented in the branch) gets an x-only pubkey,
> optionally some data, and optionally taptree's merkle root.
> It verifies that the x-only pubkey being tested equals the given naked pubkey,
> optionally tweaked with the embedded data, optionally tweaked with the tagged
> hash of the merkle tree per BIP-0341 [3].
> Making both the tweaks optional allows to simplify the code, and also to obtain
> more compact scripts in some spending paths.
>
> In words:
>
> - OP_CHECKINPUTCONTRACTVERIFY: verify that the current input's internal key
> contains some embedded data (which would typically be passed through the
> witness stack)
> - OP_CHECKOUTPUTCONTRACTVERIFY: verify that a given output is a certain P2TR
> output script containing the desired embedded data.
>
> TBD if the tweaking used for the embedded data tweak should use a tagged hash;
> omitted for simplicity in this demo implementation.
>
> ### Amount preservation
>
> In the code above and in the linked demo implementation, the opcodes only
> operate on the scriptPubkey; a complete implementation would want to make sure
> that amounts are correctly preserved.
>
> The most direct and general way to address this would be to allow direct
> introspection on the output amounts. This has the complication that output
> amounts require 64-bits arithmetics, as discussed in the context of other
> proposals, for example: [4].
>
> One more limited approach that works well for many interesting contracts
> is that of the deferred checks, implemented in OP_VAULT [2].
> The idea is that all the amounts of the inputs that commit to the same output
> script with OP_CHECKOUTPUTCONTRACTVERIFY are added together, and the script
> interpreter requires that the amount of that output is not smaller than the
> total amount of those inputs. This check is therefore transaction-wide rather
> than being tested during the input's script evaluation.
>
> This behaviour is adequate for vaults and likely suitable for many other
> applications; however, it's not the most general approach. I didn't try to
> implement it yet, and defer the decision on the best approach to a later time.
>
> ### Extensions
>
> The opcodes above are not enough for the full generality of MATT: one would
> need to add an opcode like OP_SHA256CAT to allow the data embedding to commit
> to multiple pieces of data.
> This is not used in today's post, therefore I left it out of these code examples.
>
> It would be easy to extend OP_CHECKOUTPUTCONTRACTVERIFY to also apply for
> an arbitrary input (typically, different from the currently executed one); there
> are likely use cases for that, allowing to define contracts with more complex
> cross-input semantics, but I preferred to keep things simple.
>
> Of course, one could also entirely replace CICV/COCV with generic full
> introspection on inputs/output's program, plus opcodes for elliptic curve math
> and tagged hashes.
>
> ##########################
> # PART 2: Vaults with MATT
> ##########################
>
> In the rest of this post, I will document the first attempt at creating a vault
> using the opcodes described.
>
> While not an attempt at cloning exactly the functionality of OP_VAULT [2],
> it borrows heavily from the excellent work that was done there.
>
> In particular, it also inherits the choice of using OP_CTV as a primitive,
> building on top of the bitcoin-inquisition's current branch that has already
> merged OP_CTV. Reasonable vaults would be possible without CTV, but they
> would be less efficient, particularly in the case of sending to many addresses
> in a single unvaulting flow.
>
> ### Distilling OP_VAULT
>
> Abstracting from the implementation details, I mentally model a vault as a
> simple state machine with 2 states: [V] and [U]:
>
> [V]: the initial vault UTXO(s);
> [U]: the utxo produced by the "trigger transaction" during unvaulting.
>
> On the typical path: one or more [V] UTXOs are sent to the [U] state, and after
> a timelock set on [U] expires, [U] is spent to one or several destinations.
> Crucially, the destination outputs and amounts are already decided when [V] is
> spent into [U].
>
> At any time before the funds are spent from [U], they can always be spent by
> sending them to some specified recovery path.
>
> There are two key elements that are part of OP_VAULT's semantics, and could be
> generalized:
>
> − Forcing the script/amount of the next stepon
> − Storing some data for future Script's access (in the vault's case, a hash
> that commits to the final withdrawal transaction).
>
> CICV/COCV generalize both to arbitrary scripts (taptrees) and state machines,
> and to dynamical and witness-dependent data embedded in the pubkey of a P2TR
> output.
>
> ### Vault parameters
>
> A contract that represents a vault has the following parameters (hardcoded in
> the script when the vault is created):
>
> - alternate_pk: a key that can be used any time.
> - spend_delay: the relative timelock before the withdrawal can be finalized;
> - recover_pk: a pubkey for a P2TR output where funds can be sent at any time.
>
> The alternate_pk is a pubkey that can optionally be used as the key-path
> spending condition for both states [V] and [U]. If such a spending condition is not
> desired, it can be replaced with a NUMS point, making the key-path unspendable.
>
> The spend_delay is the number of blocks that must be mined before the final
> withdrawal transaction
>
> In this example we also use an unvault_pk needed to authorize the unvaulting
> process (that is, spend [V] into [U]); this could be replaced with any miniscript
> or other conditions expressible in Script.
>
> ### P2TR structure for [V] (vault)
>
> internal key: alternate_pk
>
> Script 1: "trigger"
> # witness: <out_i> <ctv-hash>
> {
> <alternate_pk>,
> <merkle root of U's taptree>,
> 2, OP_ROLL,
> OP_CHECKOUTPUTCONTRACTVERIFY,
>
> <unvault_pk>
> OP_CHECKSIG
> }
>
> Script 2: "recover"
> # witness: <out_i>
> {
> recover_pk,
> OP_0, # no data tweak
> OP_0, # no taptweak
> OP_CHECKOUTPUTCONTRACTVERIFY,
> OP_TRUE
> }
>
> The "trigger" script requires in the witness an output index and the ctv-hash
> that describes the withdrawal transaction.
> COCV forces the output to contain the ctv-hash as embedded data.
> That's followed by the unvaulting condition − in this example, a simple
> signature check.
>
> The "recover" script doesn't require any signature, and it simply forces
> the output specified in the witness to be a P2TR output with recover_pk as its
> pubkey.
>
> (Omitting the "recover" script in [V] would reduce the size of the witness by
> 32 bytes in the expected case, and might be preferred for some users)
>
> ### P2TR structure for [U] (unvaulting state)
>
> internal key: alternate_pk (tweaked with ctv_hash)
>
> Script 1: "withdrawal"
> # witness: <ctv_hash>
> {
> OP_DUP,
>
> # check that the top of the stack is the
> # embedded data in the current input
> <alternate_pk>, OP_SWAP,
> OP_CHECKINPUTCONTRACTVERIFY,
>
> # Check timelock
> <spend_delay>,
> OP_CHECKSEQUENCEVERIFY,
> OP_DROP,
>
> # Check that the transaction output is as expected
> OP_CHECKTEMPLATEVERIFY
> }
>
> Script 2: "recover"
> # witness: <out_i>
> {
> <recover_pk>,
> OP_0,
> OP_0,
> OP_CHECKOUTPUTCONTRACTVERIFY,
> OP_TRUE
> }
>
> The "withdrawal" finalizes the transaction, by checking that the timelock expired and
> the outputs satisfy the CTV hash that was committed to in the previous transaction.
>
> The "recover" script is identical as before.
>
> ### Differences with OP_VAULT vaults
>
> Here I refer to the latest version of OP_VAULT at the time of writing. [5]
> It is not a thorough analysis.
>
> Unlike the implementation based on OP_VAULT, the [V] utxos don't have an option
> to add an additional output that is sent back to the same exact vault.
> Supporting this use case seems to require a more general way of handling the
> distribution of amounts than what I discussed in the section above: that would
> in fact need to be generalized to the case of multiple
> OP_CHECKOUTPUTCONTRACTVERIFY opcodes executed for the same input.
>
> By separating the ctv-hash (which is considered "data") from the scripts in the
> taptree, one entirely avoids the need to dynamically create taptrees and
> replace leaves in the covenant-encumbered UTXOs; in fact, the taptrees of [V]
> and [U] are already set in stone when [V] utxos are created, and only the
> "data" portion of [U]'s scriptPubKey is dynamically computed. In my opinion,
> this makes it substantially easier to program "state machines" that control the
> behavior of coins, of which vaults are a special case.
>
> I hope you'll find this interesting, and look forward to your comments.
>
> Salvatore Ingala
>
> [1] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021223.html
> [2] - https://github.com/bitcoin/bips/pull/1421
> [3] - https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
> [4] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html
> [5] - https://github.com/bitcoin/bips/blob/7112f308b356cdf0c51d917dbdc1b98e30621f80/bip-0345.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230501/6f94a2a7/attachment-0001.html>

2023-06-07 23:20:50

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Default policy changes for Lightning are scattered and not formalized, making it difficult to follow. Integrating Lightning into Bitcoin Core could have benefits but requires strong incentives and significant effort.
📝 Original message:Hi Kostas
> Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing.
It is hard to follow because most of the discussions aren't on public channels, a number of the devs working on these proposed default policy changes aren't taking the BIP process seriously and no one is willing to discuss the criteria for merging default policy changes (and consensus changes for that matter) into bitcoin-inquisition (default signet). In addition the work (to the extent that it is public) is scattered all over the place. So yeah it seems like a mess to me from the perspective of someone is seeking to follow, review and monitor it.
This Bitcoin StackExchange post [0] is my first attempt to do what you're looking for and these Bitcoin Core PR review clubs [1], [2] were really good from Gloria. But yeah the BIP process (as I've said a thousand times and been ignored) is the place to hammer out specifications for complex things like default policy proposals and when people don't care about formalizing specifications it becomes very hard for people like you and me to follow.
> Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument.
>> I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX?
As I say in the original email having two separate P2P networks and two separate P2P protocols (perhaps) doesn't make much sense if all (or most of the nodes) are both full nodes and Lightning nodes. A testing framework that integrates both base layer and Lightning tests could potentially be easier to track edge cases which fall in the grey area between base layer and Lightning but are critically important for Lightning. A Core wallet that doesn't support Lightning doesn't make much sense in a world where transaction fees are really high and you have to use Lightning unless you are transferring huge amounts. I agree with you that these arguments have to be strong to counter the separation of concerns angle and maybe it is too early to consider it. But if moving in the direction of more widely used consensus compatible forks of Core then having Lightning integrated could make it an attractive option.
> PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)?
libbitcoinkernel can achieve smaller (and still important) goals but I'm skeptical that the more ambitious goal of having lots of different implementations in different languages with libbitcoinkernel at its core and not having to worry about consensus bugs will be reached in the medium term. As we saw with the recent btcd/lnd bugs [3] consensus bugs can crop up in places you might not expect. In that case it was a wire parsing library that you wouldn't expect to be part of a libbitcoinkernel. So if you're still going to encounter consensus bugs outside of libbitcoinkernel there isn't much point (in my view) in using it for alternative implementations.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/117315/what-and-where-are-the-current-status-of-the-bip-125-replacement-the-v3-policy
[1]: https://bitcoincore.reviews/25038
[2]: https://bitcoincore.reviews/25038-2
[3]: https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 10:05, Kostas Karasavvas <kkarasavvas at gmail.com> wrote:
> Hi Michael,
>
> On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not
>
> Could you please point me to a resource that describes the default policy changes (that are happening for lightning)? I have seen discussions here and there but it would help if they are aggregated somewhere for reviewing.
>
>> exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense.
>
> Separation of concerns always makes sense to manage complexity. One would need to have really strong incentives to counter the complexity argument.
>
> I might be missing some context here but what would the actual benefit of integrating them be? Not having to install lightning node separately and maybe a more intuitive UX?
>
>> Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.
>
>> The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.
>
> Personally, I have great difficulty seeing lightning as something other than an L2 build on top of Bitcoin. There will be other L2s.
>
> Regards,
> Kostas
>
> PS. Besides, the amount of effort would be significant. Wouldn't that effort be better spent on, say, separating the consensus logic (i.e. a second libbitcoinkernel attempt)?
>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:
>>
>>> I tweeted this [0] back in November 2022.
>>>
>>> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>>>
>>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>>>
>>> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>>>
>>> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>>>
>>> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>>>
>>> Thanks
>>> Michael
>>>
>>> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>>> Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> https://twitter.com/kkarasavvas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230419/43c5b5f7/attachment-0001.html>

2023-06-07 23:20:48

- reply

📅 Original date posted:2023-04-18
🗒️ Summary of this message: Tighter coupling between full node and Lightning node could make sense with proposed changes to default policy and APO/APOAS activation attempt. Core dominance may lead to Knots style forks.
📝 Original message:Any thoughts on this from the Core Lightning contributors? The way I see it with upcoming proposed changes to default policy (primarily though not exclusively for Lightning) and a soft fork activation attempt of APO/APOAS (primarily though not exclusively for Lightning) that a tighter coupling between the full node and the Lightning node could eventually make sense. In a world where transaction fees were much higher you'd think almost every full node would also want to be a Lightning node and so the separation of concerns would make less sense. Having two separate P2P networks and two separate P2P protocols also wouldn't make much sense in this scenario. You could obviously still opt out of Lightning P2P messages if you weren't interested in Lightning.
The alternative would be just to focus on Knots style consensus compatible forks of Core with limited additional functionality. But I think we've reached the point of no return on Core dominance and not having widely used "distros". As the ecosystem scales systems and processes should be constantly evolving and improving and to me if anything Core's seem to be going backwards.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, January 14th, 2023 at 20:26, Michael Folkson <michaelfolkson at protonmail.com> wrote:
> I tweeted this [0] back in November 2022.
>
> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>
> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>
> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>
> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>
> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>
> Thanks
> Michael
>
> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230418/a61cc0c7/attachment.html>

2023-06-07 23:20:47

- reply

📅 Original date posted:2023-04-20
🗒️ Summary of this message: Competition is the solution to concerns about monopolies, according to Anthony Towns, who suggests creating a fork and doing a better job.
📝 Original message:Hi AJ
> Competition is the only answer to concerns about the bad effects from a monopoly.
Well one can first make suggestions and requests to the monopoly and see if the monopoly is open to them. In the case of bitcoin-inquisition/default signet I like the idea of a group who are interested in following and testing proposed future consensus changes working on the same fork of Core / same signet blockchain. But I've asked on a number of occasions now what the thinking is in terms of criteria for merging a proposed default policy change or a proposed consensus change (progress on BIP, level of review, a work in progress / still in flux / essentially finalized unless a problem is identified) and you haven't been willing to discuss it. So it is essentially the same black box model of maintainership we see on Core. As far as I know you could wake up one day and just merge all open pull requests to the bitcoin-inquisition repo because you're bored. On a custom signet do whatever you want. On the default signet that we're trying to build an ecosystem around, get block explorers to support, can be connected to through the default config in Core etc merge decisions essentially being subject to the whims of AJ doesn't seem ideal to me.
The brunt of having to deal with the CTV activation chaos fell on me (not a long term contributor, unfunded) because few wanted to get involved so it would be nice if lessons were learned and we don't have a soft fork proposal merged onto default signet, a bunch of transactions generated to simulate demand and then this used to justify another contentious soft fork activation attempt on mainnet. When there are vacuums of communication from maintainers and long term contributors it just invites unnecessary chaos.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Thursday, April 20th, 2023 at 03:27, Anthony Towns <aj at erisian.com.au> wrote:
> On Tue, Apr 18, 2023 at 12:40:44PM +0000, Michael Folkson via bitcoin-dev wrote:
>
> > I do think the perception that it is “the one and only” staging
> > ground for consensus changes is dangerous
>
>
> If you think that about any open source project, the answer is simple:
> create your own fork and do a better job. Competition is the only answer
> to concerns about the bad effects from a monopoly. (Often the good effects
> from cooperation and collaboration -- less wasted time and duplicated
> effort -- turn out to outweigh the bad effects, however)
>
> In any event, inquisition isn't "the one and only staging ground for
> consensus changes" -- every successful consensus change to date has
> been staged through the developers' own repo then the core PR process,
> and that option still exists.
>
> Cheers,
> aj

2023-06-07 23:20:41

- reply

📅 Original date posted:2023-04-20
🗒️ Summary of this message: Public communication and explanations from reviewers and maintainers can improve the transparency and scalability of the open source project. Lack of communication can lead to confusion and difficulty for new contributors. The departure of long-time maintainers may also contribute to delays in merging pull requests.
📝 Original message:Thanks for this Andrew.
> What commentary does there need to be?
There doesn't "need" to be explanations about anything. There doesn't "need" to be any review comments whatsoever from anybody. But a world where reviewers explain what they've done to satisfy themselves that a pull request is ready to merge and a world where maintainers explain their thought process behind a merge decision is much easier to follow and much more scalable than the current black box where people see pull requests being self merged by a maintainer with no ACKs within a day of it being opened. Most likely these decisions make sense (low risk, unlikely to be reviewed by anybody else, blocking other pull requests etc). But more and more people are funded to work on Core and increasingly they seem to stick to their own mini projects and not review anybody else's work. Of course you can't put the responsibility for this entirely down to maintainers but the black box isn't scalable. Maintainers (presumably) have private discussions and so know how best to spend their review time. Everyone else (especially new contributors) are playing an uninformed and in the dark lottery with how they spend their review time (to the extent that they allocate any).
> There are currently 320 open PRs and 366 open issues.
I wake up every morning to 150+ email notifications containing
everything that went on overnight, and throughout the day, I typically
get hundreds more.
Indeed. All the more reason for more and higher quality public communication. If you struggle and you're in those private discussions with other maintainers on merge decisions and ready for merge discussions how do you think everyone is trying to assess how to spend their time? It is even more bewildering. As far as I know most of the current maintainers haven't worked on other projects or in the private sector for a sustained period of time but the way other projects and businesses function is that those with the most experience and most responsibilities are able to manage and provide guidance to those with less experience and less responsibilities. I'm sure this goes on within Brink if you've been anointed but this is supposed to be an open source project. If everything is done in private conversations and everything other than the code is open source it is pretty much a façade. It is very hard to make meaningful contributions without getting anointed. Those who do get anointed very early in their careers seem especially bad at hoarding information, refusing to do anything in public and not assisting those who haven't been anointed.
> Things can simply fall through the cracks.
> With several long time maintainers stepping away, this may be a factor
in PRs taking longer to get merged as the remaining maintainers may be
less familiar with the parts of the codebase that were previously
maintained by someone else.
> Requiring maintainers to have to write explanations for every single
merge is simply going to increase the burden on them and increase the
rate of burnout and resignations.
> We've had too many maintainers step down already.
This all points to a a need for additional maintainers (assuming they are sufficiently competent and qualified). We had a potential maintainer (Vasil) come forward (long term contributor, made significant contributions over a number of years, a qualified reviewer, contributes to a part of the codebase that current maintainers aren't very familiar with, ACKed by maintainers and long term contributors) and it was blocked. How does that make sense? You seem to want it both ways. We can't ask maintainers to meet higher standards because there's a shortage and they're close to burning out. But there's no need to add a new maintainer.
I've responded to the parts I disagree with and see inconsistencies with but generally I thought it was a very thoughtful and informative response so thank you. Of the current maintainers you seem to me to be one of (if not the) most responsive and open to public discussion on the project. I've learnt a tonne from your StackExchange posts and Twitch streams that are all public/open source that you do in addition to your contributions and maintenance of Core.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 22:33, Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Responses in-line.
> Note that the opinions expressed in this email are my own and are not
> representative of what other maintainers think or believe.
>
> On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
>
> > Communication has been a challenge on Bitcoin Core for what I can
>
> tell the entire history of the project. Maintainers merge a pull request
> and provide no commentary on why they’ve merged it.
>
> What commentary does there need to be?
> It's self evident that the maintainer believes the code is ready to be
> merged, and has observed enough ACKs from contributors that they are
> comfortable to do so.
> You're welcome to ask for clarification, but frankly, I don't think
> having any commentary on merges is going to be helpful or more elaborate
> in any way.
> Requiring maintainers to have to write explanations for every single
> merge is simply going to increase the burden on them and increase the
> rate of burnout and resignations.
> We've had too many maintainers step down already.
> It'll end up being a bunch of boilerplate comments that don't say
> anything meaningful.
>
> There are certainly situations where PRs are merged very quickly or with
> otherwise little apparent review.
> But, as I said, if you ask a maintainer why it was merged, the answer
> will be "I thought it was ready and had enough review".
> There may be other reasons that made the maintainer think it was ready
> sooner, such as the PR fixes a critical bug or security vulnerability,
> but these reasons aren't going to be stated publicly.
>
> > Maintainers leave a pull request with many ACKs and few (if any)
>
> NACKs for months and provide no commentary on why they haven't merged it.
>
> There are currently 320 open PRs and 366 open issues.
> I wake up every morning to 150+ email notifications containing
> everything that went on overnight, and throughout the day, I typically
> get hundreds more.
> It's impossible to keep up with everything that goes on throughout the repo.
> ACKs come in sporadically, PRs are updated, reviews are posted, etc.
> Often times PRs are not merged simply because the maintainers were not
> aware that a PR was ready to be merged.
> Things can simply fall through the cracks.
>
> Of course there are other reasons why something might not be merged, and
> these generally fall into the camp of "I don't think it has had enough
> review".
> It's the maintainer's judgement call to make as to whether something has
> been sufficiently reviewed, and part of the judgement call is to
> consider the quality and competence of the reviewers.
> If a PR had 100 ACKs but all from random people who have never
> contributed to the project in any capacity, then it's not going to be
> merged because those reviewers would be considered low quality.
> It's not just about the numbers, but also about whether the reviewers
> are people the maintainers think are familiar enough with an area and
> have had a history of thoroughly reviewing PRs.
> For example, if a reviewer who primarily works on the mempool reviewed a
> PR in the wallet, I would consider their review and ACK with less weight
> because they are unlikely to be familiar with the intricacies of the wallet.
> Obviously that changes over time as they make more reviews.
> For another example, if I see an ACK from a reviewer who posts reviews
> that primarily contain nits on code style and other trivialities, I
> would consider that ACK with less weight.
>
> Furthermore, the maintainers are not necessarily the ones who block a merge.
> Part of evaluating if something is ready to be merged is to read the
> comments on a PR.
> Other frequent contributors may have commented or asked questions that
> haven't been resolved yet.
> PRs will often not be merged (even if they have ACKs) until a maintainer
> deems that those comments and questions have been sufficiently resolved,
> typically with the commenter stating in some way that their concerns
> were addressed.
> In these situations, no commentary from maintainers is given nor
> necessary as it should be self evident (by reading the comments) that
> something is controversial.
> These kinds of comments are not explicit NACKs (so someone who is only
> counting (N)ACKs won't see them), but are blocking nonetheless.
>
> Lastly, personally I like to review every PR before I merge it.
> This often means that a PR that might otherwise be ready to be merged
> wouldn't be merged by myself as I may not be familiar with that part of
> the codebase.
> It may also mean that I would require more or specific additional people
> to review a PR before I merge it as I would weight my own review less
> heavily.
> With several long time maintainers stepping away, this may be a factor
> in PRs taking longer to get merged as the remaining maintainers may be
> less familiar with the parts of the codebase that were previously
> maintained by someone else.
>
> > but a casual observer would have only seen Concept ACKs and ACKs with
>
> 3 stray NACKs. Many of these casual observers inflated the numbers on
> the utxos.org site [4] signalling support for a soft fork activation
> attempt.
>
> Anyone who thinks that maintainers only look at the numbers of (N)ACKs
> is delusional.
> As I explained above, there is a whole lot more nuance to determining
> even just the status of the opinions on a PR, nevermind the code itself.
>
> In this specific example of a soft fork, there is also consideration of
> the opinions outside of the repo itself, such as on this mailing list
> and elsewhere that people discuss soft forks.
>
> On 04/19/2023 11:17 AM, Aymeric Vitte via bitcoin-dev wrote:
>
> > While some simple changes can allow bitcoin to surpass ethereum, as
>
> usual, like "Allow several OP_RETURN in one tx and no limited size"
> https://github.com/bitcoin/bitcoin/issues/27043
>
> > How long it will take remains mysterious
>
>
> No one (maintainers or contributors) is obligated to implement anything.
> A feature request not being implemented is because the people who do
> open PRs are either not interested in implementing the feature, or are
> working on other things that they believe to be higher priority.
> If there is a feature that you want, then you will often need to either
> to it yourself, or pay someone to do it for you.
>
> Additionally, a feature may seem like a good idea to you, but there are
> often interactions with other things that may end up resulting in it
> being rejected or need significant revision, especially for something
> which affects transaction relay.
>
>
>
> Andrew Chow
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:20:37

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Communication on merge decisions in Bitcoin Core is important to avoid frustration and chaos. Defining "enough" reviews and ACKs is crucial, especially for high-risk pull requests. Lack of communication can lead to controversial decisions and potential harm to the project's value. Creating a nonprofit to fund Bitcoin Core contributors is a solution, but it's irrelevant if current maintainers refuse to discuss merge decisions and block long-term contributors from becoming maintainers.
📝 Original message:Hi alicexbt
> I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.
The problem is defining what is "enough". "Enough" is determined by the quality of the review, the expertise of the reviewer(s), the complexity of the pull request and most importantly what risks a merge of the pull request poses. When there is zero communication on merge decisions (both merging and not merging over a long period of time) it creates frustration and worse vacuums and soft fork activation chaos. It is a complete black box. The vast majority of merge decisions are uncontroversial but it would still be nice to have a comment saying something like:
"This pull request only has 2 ACKs but it is low risk, relatively simple and is unlikely to be reviewed by anybody else in the near term"
"This pull request is a consensus change, extremely high risk and is unlikely to be merged in the near term"
On the rare occasions when merge decisions are controversial communication becomes a lot more important. If some maintainers aren't responsive on IRC and refuse to discuss merge decisions what can we expect in future? We wake up one day, a contentious consensus change has been merged with little review in advance of a release window and the maintainer won't discuss why they have merged it. This isn't a toy anymore, it is supporting hundreds of billions of dollars of value and could end up supporting a lot more. It is surely completely unreasonable to let maintainers merge or not merge whatever they like with no explanation and no willingness to discuss their merge decisions.
> So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core."
As I responded on the pull request if any long term contributor from this alternative nonprofit is blocked from being a maintainer and current maintainers refuse to discuss merge decisions it is irrelevant. To contribute you need a maintainer to merge your pull request(s) and to spend your review time wisely you need to know what pull request(s) could viably be merged by a maintainer. Otherwise you're just wasting your time. We not only have opacity on merge decisions for normal pull requests (e.g. code) we also now have opacity on decisions for the addition of new maintainers. I was always under the impression that any long term contributor who demonstrated over time that they were sufficiently competent, qualified and able to contribute both through opening pull requests and reviewing other people's pull requests could become a maintainer. To me and many others (until it was blocked by two maintainers for 5 months) Vasil met this criteria. This not only impacts Vasil's and others' commitment to the project but it impacts what pull requests are ultimately reviewed and merged. What is the point of spending time opening or reviewing a pull request if the current maintainers won't look at it or are unqualified to review it and hence won't merge it?
Gloria's advice effectively boils down to spend months setting up a non-profit, spend years becoming a long term contributor to the project and then you can have the honor of being blocked from becoming a maintainer and have your contributions stunted by the current maintainers with no recourse or ability to discuss their merge decisions. So yeah thanks for repeating that advice but I'm sure most would rather pass and do something else.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 13:24, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Michael,
>
> I was initially sad about the politics in Vasil's pull request, written about it and also tried to document the process. Still think he deserves to be a maintainer. Although I have some counter arguments:
>
> > Maintainers merge a pull request and provide no commentary on why they’ve merged it.
>
>
> I don't think commentary is required for each pull request that gets merged with enough reviews, ACKs and no controversy.
>
> > Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it
>
>
> This could be considered normal in pull requests that involve code changes.
>
> > The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC.
>
>
> Unfair to expect every human to behave the same or work similarly. Sometimes the unresponsiveness could be to avoid controversies and heated debates that go off-topic.
>
> > One farcical recent example 0 was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>
>
> - Maintainers should be free to avoid involvement in a pull request. As long as a subset of maintainers have an opinion on the pull request, things should be fine.
> - I agree with Gloria's comment: "I had not NACKed this either because my opinion could change over time, NACKs are sometimes needlessly interpreted as personal attacks, and Brink has been antagonized on Twitter each time multiple grantees have similar opinions about this. So I'll add that if you wish to have more decentralization in Bitcoin Core funding, you can start by creating a nonprofit, gathering donations, and funding somebody who works on Bitcoin Core." Last part of this comment also solves the problem shared in other thread related to new bitcoin implementation. Brink needs some competition and bitcoin core needs more reviewers.
> - I also agree with Andrew's comment: "frankly, I think opinions aren't being shared because of potential backlash from aggressive users such as yourself and bytes1440000"
>
> > Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
>
>
> - I don't see anything wrong with sharing honest opinion if someone agrees with the concept. It does not make a pull request ready to get merged.
> - utxos.org is an external site maintained by Jeremy with opinions on BIP 119. Everyone is free to maintain such lists and I think you had also created one as GitHub gist.
>
> > I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
>
>
> This perception (if exists) can be killed by creating a custom signet, maintaining it differently, get more reviews, testing and share details with community regularly.
>
> /dev/fd0
> floppy disk guy
>
> 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564
> 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example 0 was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
> >
> > A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
> >
> > Another farcical recent(ish) example was the CTV pull request 1 that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious 3 but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site 4 signalling support for a soft fork activation attempt.
> >
> > I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition 5) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous 6 if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
> >
> > As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-07 23:20:35

- reply

📅 Original date posted:2023-04-19
🗒️ Summary of this message: Discussion on BIP 118 and BIP 119 for Bitcoin covenant tech. James O'Beirne needs BIP 119/OP_CTV for his latest vault design. More experimentation needed.
📝 Original message:Hi Erik
> yes, the code itself was far less contentious than the weird stab at forking the network
>
> there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant tech for many use cases
>
> although im partial to 118 as well because lightning is a killer app and it makes batch channels more efficient
This is moving off the intended subject of the email although latest thoughts on BIP 118 and BIP 119 are an interesting separate topic. Perhaps start a new thread? The latest afaik is that both have been merged in bitcoin-inquisition [0] (default signet) and James O'Beirne concluded that he needed BIP 119/OP_CTV for his latest vault design that includes a new proposed opcode OP_VAULT (BIP 345) [1]. Designing and building vaults with the various proposed opcodes and sighash flags (and Simplicity when it is ready) is definitely what I hoped to see after the chaos of the attempted CTV activation. Hopefully more people will be drawn into this research and development area, I think it is a really interesting one [2] so I'm a bit bemused more people aren't following James and the Revault team and doing their own research and experimentation. I think darosior's (Revault) current view [3] is BIP 118/APO is sufficient for the vaults he wants to build. But yeah needs more informed views and you only really get a more informed view by trying to design and build things and realizing what you need or what is missing. It isn't convincing to embark on a soft fork activation process just because a couple of informed individuals want it.
Thanks
Michael
[0]: https://github.com/bitcoin-inquisition/bitcoin
[1]: https://github.com/bitcoin/bips/pull/1421
[2]: https://www.youtube.com/watch?v=S2lTfS5qMJE
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020276.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 19th, 2023 at 01:56, Erik Aronesty <erik at q32.com> wrote:
> yes, the code itself was far less contentious than the weird stab at forking the network
>
> there remains a real chance that bip 119 is the simplest and most flexible and reasonably safe covenant tech for many use cases
>
> although im partial to 118 as well because lightning is a killer app and it makes batch channels more efficient
>
> On Tue, Apr 18, 2023, 7:39 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
>>
>> A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
>>
>> Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.
>>
>> I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
>>
>> As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
>>
>> [0]: https://github.com/bitcoin/bitcoin/pull/25871
>>
>> [1]: https://github.com/bitcoin/bitcoin/pull/21702
>>
>> [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
>>
>> [3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>
>> [4]: https://utxos.org/signals/
>>
>> [5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>>
>> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230419/77bcfdc9/attachment-0001.html>

2023-06-07 23:20:34

- reply

📅 Original date posted:2023-04-18
🗒️ Summary of this message: Communication has been a long-standing issue in Bitcoin Core, with maintainers often failing to provide rationale for merge decisions or engage in discussion. This can lead to frustration and delays for pull request authors.
📝 Original message:Communication has been a challenge on Bitcoin Core for what I can tell the entire history of the project. Maintainers merge a pull request and provide no commentary on why they’ve merged it. Maintainers leave a pull request with many ACKs and few (if any) NACKs for months and provide no commentary on why they haven't merged it. I can only speculate on why and it probably depends on the individual maintainer. Sometimes it will be poor communication skills, sometimes it will be a desire to avoid accountability, sometimes it will be fear of unreasonable and spiteful legal action if they mistakenly merge a pull request that ends up containing a bug. But search through the pull requests on Bitcoin Core and you will rarely see a rationale for a merge decision. The difference between say previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC. If you disagreed with a merge decision or thought it had been merged prematurely they would be happy to discuss it on IRC. In present times at least a subset of the current maintainers are not responsive on IRC and will refuse to discuss a merge decision. One farcical recent example [0] was the pull request to add Vasil Dimov as a maintainer where despite many ACKs from other maintainers and other long term contributors two maintainers (fanquake and Gloria) refused to discuss it on the pull request or on IRC. It took almost 5 months for Gloria to comment on the pull request despite many requests from me on the PR and on IRC. I even requested that they attend the weekly Core Dev IRC meeting to discuss it which they didn’t attend.
A pull request to add a maintainer isn’t a normal pull request. Generally pull requests contain a lot more lines of code than a single line adding a trusted key. Not merging a pull request for a long period of time can be extremely frustrating for a pull request author especially when maintainers and long term contributors don’t comment on the pull request and the pull request is stuck in “rebase hell”. Clearly it is the lesser evil when compared to merging a harmful or bug ridden pull request but poor non-existent communication is not the only way to prevent this. Indeed it creates as many problems as it solves.
Another farcical recent(ish) example was the CTV pull request [1] that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. If you look at the comments on the pull request there were 3 individuals (including myself) who NACKed the pull request and I think it is fair to say that none of us would be considered long term contributors to Bitcoin Core. I have criticised Jeremy Rubin multiple times for continuing to pursue a soft fork activation attempt when it was clear it was contentious [3] but if you look at the pull request comments it certainly isn’t clear it was. Maintainers and long term contributors (if they commented at all) were gently enthusiastic (Concept ACKing etc) without ACKing that it was ready to merge. A long term observer of the Core repo would have known that it wasn’t ready to merge or ready to attempt to activate (especially given it was a consensus change) but a casual observer would have only seen Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers inflated the numbers on the utxos.org site [4] signalling support for a soft fork activation attempt.
I set out originally to write about the controls and processes around merges on the default signet (bitcoin-inquisition [5]) but it quickly became obvious to me that if communication around Core merges/non-merges is this weak you can hardly expect it to be any better on bitcoin-inquisition/default signet where there is no real monetary value at stake. I will probably write about bitcoin-inquisition/default signet in a future email as I do think the perception that it is “the one and only” staging ground for consensus changes is dangerous [6] if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers.
As I stated at the beginning there is an element to this which is not individual(s) specific and an adverse reaction to outright malicious actors external to any of these projects. I do not think any of the current maintainers on Core or bitcoin-inquisition are outright malicious even if a subset of them consistently frustrate me with their lack of transparency and accountability. But this issue isn't going away and I'm sure we'll hear more on this from others in the coming months. To me it is a straight choice of taking transparency and accountability much more seriously or failing that investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open.
[0]: https://github.com/bitcoin/bitcoin/pull/25871
[1]: https://github.com/bitcoin/bitcoin/pull/21702
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020386.html
[3]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[4]: https://utxos.org/signals/
[5]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
[6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020948.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230418/dd827725/attachment-0001.html>

2023-06-07 23:19:27

- reply

📅 Original date posted:2023-02-08
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated multiple times, incurring different Tapfee rates. The countermeasure is to know the entire Taptree.
📝 Original message:Hi Andrew
> There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates.
>> The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend.
I wouldn't say it is a "bug" unless there is a remedy for the bug that wasn't (and retrospectively should have been) included in the Taproot design. In retrospect and assuming you could redesign the Taproot consensus rules again today would you prevent spending from a valid P2TR address if a repeated Tapleaf hash was used to prove that a spending path was embedded in a Taproot tree? That's the only thing I can think of to attempt to remedy this "bug" and it would only be a partial protection as proving a spending path exists within a Taproot tree only requires a subset of the Tapleaf hashes.
I only point this out because there seems to be a push to find "bugs" and "accidental blowups" in the Taproot design currently. No problem with this if there are any, they should definitely be highlighted and discussed if they do exist. The nearest to a possible inferior design decision thus far that I'm aware of is x-only pubkeys in BIP340 [0].
Thanks
Michael
[0]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/#a-retrospective-look-at-bip340
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Tuesday, February 7th, 2023 at 18:35, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is a bug in Taproot that allows the same Tapleaf to be repeated multiple times in the same Taproot, potentially at different Taplevels incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree when interacting with someone's Tapspend.
>
> On Tue, Feb 7, 2023 at 1:10 PM Andrew Poelstra via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Some people highlighted some minor problems with my last email:
>>
>> On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>>>
>>> <snip>
>>>
>>> [1] https://bitcoin.sipa.be/miniscript/
>>> [2] In Taproot, if you want to prevent signatures migrating to another
>>> branch or within a branch, you can use the CODESEPARATOR opcode
>>> which was redisegned in Taproot for exactly this purpose... we
>>> really did about witness malleation in its design!
>>
>> In Taproot the tapleaf hash is always covered by the signature (though
>> not in some ANYONECANPAY proposals) so you can never migrate signatures
>> between tapbranches.
>>
>> I had thought this was the case, but then I re-confused myself by
>> reading BIP 341 .... which has much of the sighash specified, but not
>> all of it! The tapleaf hash is added in BIP 342.
>>
>>>
>>> If you want to prevent signatures from moving around *within* a
>>> branch,
>>>
>>
>> And this sentence I just meant to delete :)
>>
>> --
>> Andrew Poelstra
>> Director of Research, Blockstream
>> Email: apoelstra at wpsoftware.net
>> Web: https://www.wpsoftware.net/andrew
>>
>> The sun is always shining in space
>> -Justin Lewis-Webster
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230208/6a71e08e/attachment.html>

2023-06-07 23:18:40

- reply

📅 Original date posted:2023-01-16
🗒️ Summary of this message: Michael is considering the idea of creating a bare bones Knots-style Bitcoin implementation integrated with Core Lightning, as he believes the current management of Bitcoin Core is not how he would like an open-source project to be managed.
📝 Original message:Hi alicexbt
Thanks for the suggestion. I'll take a look at the branch.
I'm personally pretty bullish on Lightning and Core Lightning is criminally underused. Plus it is more exciting (and hopefully will attract more contributors) to try something ambitious than just trim Core. I'll see if it is something the Core Lightning contributors might be interested in helping out on. I remember that Rusty said on a podcast that if he had another life he'd have liked to have worked on Core. This way he could potentially do both :)
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, January 15th, 2023 at 12:58, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Michael,
>
> If I were to fork bitcoin core and maintain an implementation, I wouldn't integrate any lightning implementation with it. Instead remove some things from bitcoin core and keep it simple. There is also scope for improving privacy. Example: https://github.com/bitcoinknots/bitcoin/issues/50
>
> You might find the commits in this branch interesting if you are looking to remove things from bitcoin core and maintain an implementation with no gui, wallet, less RPCs etc.
>
> https://github.com/jeremyRubin/bitcoin/commits/delete-it-all
>
>
> /dev/fd0
> floppy disc guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Sunday, January 15th, 2023 at 1:56 AM, Michael Folkson via Lightning-dev lightning-dev at lists.linuxfoundation.org wrote:
>
>
>
> > I tweeted this 0 back in November 2022.
> >
> > "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
> >
> > A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
> >
> > The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
> >
> > Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
> >
> > I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
> >
> > Thanks
> > Michael
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-07 23:18:39

- reply

📅 Original date posted:2023-01-14
🗒️ Summary of this message: A Knots-style fork of Core in C++ integrated with Core Lightning in C is a better option for serious production use cases, according to Michael Folkson.
📝 Original message:I saw it was announced, yes. The author is brilliant, he has now managed two alternative implementations of Core in two different languages :)
The problem though and why I and many others think the Knots style fork of Core is the better option is because you avoid reimplementing consensus code in a different language. If you're ultra conservative about consensus code you either want to run Core in parallel with your alternative implementation to check they don't go out of consensus or you want to run the same consensus code as Core in a Knots like fork. Hence a Knots like fork of Core in C++ integrated with Core Lightning in C seems like the better option to me for serious running in production like use cases.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, January 14th, 2023 at 20:34, Fabian <fjahr at protonmail.com> wrote:
> Hi Michael,
>
> have you seen Mako? It might at least be a good start for what you would like to achieve: https://github.com/chjj/mako
>
> Best,
> Fabian
> ------- Original Message -------
> On Saturday, January 14th, 2023 at 9:26 PM, Michael Folkson via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>> I tweeted this [0] back in November 2022.
>>
>> "With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
>>
>> A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
>>
>> The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
>>
>> Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
>>
>> I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
>>
>> Thanks
>> Michael
>>
>> [0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230114/f701a6df/attachment-0001.html>

2023-06-07 23:18:38

- reply

📅 Original date posted:2023-01-14
🗒️ Summary of this message: Michael Folkson suggests that a bare bones Knots style Bitcoin implementation integrated with Core Lightning may be the future due to dysfunction in Bitcoin Core's management.
📝 Original message:I tweeted this [0] back in November 2022.
"With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."
A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.
The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.
Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.
I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.
Thanks
Michael
[0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230114/306cd5ac/attachment-0001.html>

2023-06-07 23:17:54

- reply

📅 Original date posted:2022-12-20
📝 Original message:Hi alicexbt
There does seem to be some confusion on this which I'm going to look into. I don't think ranting and raving or throwing toys out the pram on the mailing list is the productive way to go though. I'll chat to some people offline and see what the confusion is and hopefully this can be resolved without unnecessary drama. I'll respond in the new year. I don't know if you celebrate but if you do Happy Holidays.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, December 19th, 2022 at 23:58, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,
>
> List of present bitcoin core maintainers:
>
> Username
>
> Focus Area
>
> MarcoFalke
>
> General, QA
>
> fanquake
>
> General, Build
>
> hebasto
>
> General, UI/UX
>
> achow101
>
> General, Wallet
>
> glozow
>
> General, Mempool
>
> Last 2 developers that stepped down as bitcoin core maintainer:
>
> Username
>
> -------------
>
> sipa
>
> laanwj
>
> Process followed in adding last maintainer:
>
> 1) fanquake [nominated][0] glowzow as rbf/mempool/validation maintainer.
>
> 2) It was discussed in an IRC [meeting][1] and most of the developers agreed to add her as new maintainer except mild NACK from Jeremy Rubin. Some contributors did not like different opinions being shared in the meeting.
>
> 3) A [pull request][2] was opened by glowzow to add keys. There were several ACKs, 2 NACKs and 1 meta concept NACK.
>
> My NACK: https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172518409
>
> NACK by jamesob: https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1172570635
>
> Meta concept NACK by luke-jr: https://github.com/bitcoin/bitcoin/pull/25524#issuecomment-1175625779
>
> Eventually everyone agreed to add glowzow as maintainer and improve the process of adding maintainers. Pull request was merged by MarcoFalke.
>
> Initiatives to improve the process and documentation:
>
> 1) Jeremy opened a [pull request][3] and there were lot of disagreements with the documentation. It was closed since a related PR with less changes could be easy to agree upon.
>
> 2) Related [pull request][4] with minimal documentation was also closed by Jeremy with a comment that desire to improve docs seems to be missing based on reviews.
>
> 3) Jeremy opened an [issue][5] with title 'Call for Maintainer: P2P & Networking + Privacy' which was changed later and 'Privacy' was removed. He nominated jonatack and vasild was already self nominated so mentioned in the pull request. Nobody appreciated this effort to nominate self or others for a new maintainer. Later this was closed.
>
> 4) I had opened an [issue][6] with title Call for Maintainer: Privacy'. This even involved privacy of contributors and not just bitcoin core. It received some comments that made no sense and I eventually closed the issue.
>
> Process being followed for adding vasild as maintainer:
>
> 1) vasild volunteered to be a new maintainer on [IRC][7]
>
> 2) It was discussed in IRC [meeting][8], some developers ACKed it and there were no issues.
>
> 3) A [pull request][9] was opened by vasild to add keys which is still open and its been 4 months. There were already some ACKs from the IRC meeting and pull request also received some ACKs (16 until now). fanquake, dergoegge and JeremyRubin had some disagreements. Jeremy had recently withdrawn all ACK/NACK from bitcoin core repository for some reasons, fanquake has not replied yet and dergoegge had some new disagreements although don't mind if the pull request is merged.
>
> 4) Earlier disagreements were related to scoping and it was changed by vasild
>
> 4) There was even a comment that disrespected vasild's contributions in bitcoin core and we had to literally share pull requests in which vasild has improved bitcoin core.
>
> 5) I tried adding the topic for a bitcoin core dev weekly meeting but did not achieve anything.
>
> Since Bitcoin Core is the reference implementation for Bitcoin and used by 90% nodes, what should be the ideal process or changes you would expect in roles, procedures etc.?
>
> - 'Call for maintainers' issue should be opened if contributors or maintainers need a new maintainer.
>
> - Discussion about nominated contributors in an IRC meeting where everyone is allowed to share their opinion.
>
> - One of the nominated contributor that gets most ACKs could open pull request to add keys. Everyone can ACK/NACK this PR with reasons.
>
> - Maintainers should be unbiased in merging these pull requests.
>
> - New maintainer should not be funded by the organization that already does it for most of the maintainers.
>
> - Long term contributors that are not living in a first world country should be encouraged.
>
> - Either we should agree every maintainer is a general maintainer that can merge pull request from different modules or define scope for present and new maintainers. We can't do both.
>
> - Self merging pull requests should be avoided.
>
> Let me know if you have any thoughts that could improve this process and involve less politics.
>
> [0]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-06-28#826651
>
> [1]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-06-30#827695
>
> [2]: https://github.com/bitcoin/bitcoin/pull/25524
>
> [3]: https://github.com/bitcoin/bitcoin/pull/25560
>
> [4]: https://github.com/bitcoin/bitcoin/pull/25839
>
> [5]: https://github.com/bitcoin/bitcoin/issues/25870
>
> [6]: https://github.com/bitcoin/bitcoin/issues/25875
>
> [7]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-08-12#842847;
>
> [8]: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2022-08-18#844523
>
> [9]: https://github.com/bitcoin/bitcoin/pull/25871
>
> /dev/fd0
>
> 'floppy disc guy'
>
> Sent with Proton Mail secure email.
>
> _______________________________________________
>
> bitcoin-dev mailing list
>
> bitcoin-dev at lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:17:39

- reply

📅 Original date posted:2022-12-11
📝 Original message:I think it best I leave this discussion to others then as something I've written has obviously offended you. I'll also leave it to others to assess whether I was disrespectful or attacking your character or quality of experience in that email. Someone working on the P2P or mempool part of the Bitcoin Core codebase for years is going to understand the code and the subtle trade-offs of mempool policy defaults better than you or I. I hate to break it to you. Just like you are going to understand Synonym's business and technology better than that P2P/mempool developer. We all have different skillsets and different experiences.
> When I post in github, you mention I should be banned and you ignore my substantive arguments.
Pull requests on Bitcoin Core's GitHub repository are for technical review of the concept, approach and code contained within that pull request. Submitting your Concept (N)ACK and reasoning is perfectly fine as is opening a pull request with the same changes. But the general high level discussion (back and forth etc) you seem to want to have is much better suited here than on a Bitcoin Core pull request. It is impossible for the Bitcoin Core project to operate if the world's population aren't willing to follow project norms and want to have discussions on subjects that aren't within the scope of that pull request. I and others requested you go here and you initially refused and said you struggled to use this forum.
But yeah I'm not interested in engaging a shouting match. So with regards to your questions I'll leave it to others to discuss them with you.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, December 11th, 2022 at 16:56, John Carvalho <john at synonym.to> wrote:
> While I appreciate your reference links, and will check them out (thanks!), I do not appreciate your repeated takes about my character or quality of experience. I have been in Bitcoin for 10 years, I build with it, I manage a Bitcoin company with 8 engineers, and, modesty aside, there aren't very many non-engineers that grasp how Bitcoin works as well as I do. I put lots of time into Bitcoin, and do my best to scrutinize all concepts presented to me.
>
> When I post in github, you mention I should be banned and you ignore my substantive arguments. If I post on the list here, you imply I am a noob, have difficulty understanding, and that I'm biased by business. This is not useful other than some, probably false, notion that maybe you can position yourself as superior or myself as dismissable.
>
> My post is an analysis on incentives and how we understand them when designing for Bitcoin. You explained a bit about what the mempool is for, and some dynamics about it, but you may notice that doing something like mempoolfullrbf is actually inconsistent with a goal of mempool harmony. It is a disruptive change, therefore a tradeoff. The arguments for making that tradeoff use some oversimplified concepts, in my opinion.
>
> So, I am questioning the quality of current theory, and showing how it might be insufficient.
>
> - Do you think it is possible that a fully replaceable mempool, and obsoletion of zero-conf (merchant/consumer) use cases could result in less overall mining income? If not, why not?
> - Could this, and other active management by Bitcoin Core engineers, result in an overall less valuable, less useful Bitcoin, and is that bad for miners/security?
> - Do you think it is inconsistent that on one hand, Bitcoiners argue that miners do not control Bitcoin, yet Bitcoin Core is biasing decisions to cater to mining incentives over user incentives? Should miners do what users want, and might that be their actual incentive?
> - Do you think it is Core's place to influence or steer policy based on speculation about what may happen in the future, even when it conflicts with the present and past?
>
> *These* are the interesting questions. Do you have reasoned answers?
>
> You suggest you are comfortable outsourcing your understanding and decisions to others, well I am not, and my post was meant to show some reasons why. It is important that Bitcoiners question how, when, and whether Bitcoin software is changed, regardless of their ability to create or audit code.
>
> Please analyze my ideas instead of me, thank you. Or, you could stay out of it and outsource that to someone else as well.
>
> ~John
>
> On Sun, Dec 11, 2022 at 1:58 PM Michael Folkson <michaelfolkson at protonmail.com> wrote:
>
>> Hey John
>>
>> There was a discussion [0] started by Lisa on the mailing list last year on whether there is any point to a full node maintaining a mempool last year which you may find interesting. I also recommend Gloria's presentation [1] from Adopting Bitcoin last year on transaction relay policy.
>>
>> I think those are better resources than anything I could write. But I guess I'd summarize it like this. The job of the P2P/mempool/policy protocol devs in setting defaults is to ensure anyone can effectively propagate a consensus valid transaction across the network ultimately making its way into miners' mempools without harming network health (full node uptime, DoS attacks etc) and to give higher layers built on top of the Bitcoin network the best chance to succeed. If they totally screwed up that job with the defaults or they were unable to cater for a particular use case within default policy then there is always the alternative of submitting consensus valid transactions directly to miners bypassing the P2P network entirely. But clearly it is much better if the P2P network functions smoothly and every transaction isn't forced to be directly submitted to a miner. It is policy too of course rather than consensus so if the full node operator wants to change from the defaults they are free to do so without risking being forked off the network or risking a chain split.
>>
>>> I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate.
>>
>> This stuff is difficult to follow and understand especially for people who haven't been into Bitcoin for long or are trying to build Bitcoin businesses full time, there are lots of subtleties. I've certainly struggled at many points in my learning journey and I'm sure I will continue to do so in future. So there is no scoffing (from me at least) at individuals trying to learn and businesses trying to thrive and provide services to their customers. Unfortunately there are occasionally scenarios where trade-offs have to be weighed up and decisions have to be made where some people aren't happy. You may disagree but I'm a lot more comfortable delegating responsibility for policy defaults to those who have worked full time in this area for years than say consensus changes where I think we all have a responsibility to ensure suboptimal or worse harmful changes aren't made to the consensus rules. I thought your input on the CTV discussion earlier in the year was really positive for example. On this topic though I think you could do with doing some more reading as there is a lot of past discussion. I'm sure those who work in this area full time would be happy to answer any questions you have if you do.
>>
>> Thanks
>> Michael
>>
>> [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html
>> [1]: https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> As we debate mempoolfullrbf, and I familiarize myself with related PRs from engineers trying to reign in all of the possible behaviors that make it inconsistent, I can’t help but think about how I see people using the term “incentive-compatible” and how it seems to be awfully presumptive.
>>>
>>> The idea that a single Bitcoin transaction can be “incentive-compatible” by simply restricting it to having a higher fee or fee rate is theoretical, likely narrow, and not totally objective. RBF is inherently a fee-minimization tool, which as a concept, as I understand “incentive-compatibility” to be about miners in this context, makes RBF to be anti-incentives; miners are fee maximizers.
>>>
>>> Miners want the most fees per block, and per lifetime, do they not? If miners, and the mempool, are prioritizing for the smallest txns with the highest fees, over the longest acceptable amount of time, this may conflict with extra-mempool behaviors that result in more txns per block / per lifetime.
>>>
>>> If this isn’t making sense yet, let me summarize by how such a problem would express: a per-transaction fee-minimized, fully replaceable mempool as policy, that appears to always require the highest fee per txn, but ultimately includes less txns per block and less fees per lifetime. Basically, less use cases, less users, less txns — all to enforce a misunderstood theory and predictive speculation of what people want out of the system and what miners will do about it.
>>>
>>> Simply, we probably want designs that fill blocks, and we don’t need to do anything at all to facilitate bidding on a use case like replacement.
>>>
>>> Bidding does not require protocol enforcement, it is miner-subjective. So why are we pursuing it? Why do we even have RBF? Why are we trying to clean up all of the mess RBF creates with more and more code? If bidding is already accepted as incentive-compatible, and Bitcoin already allows setting a fee, then replacement requires no special code at all.
>>>
>>> I would think a holistic definition of what is incentive-compatible would be something more like what is “market compatible” and enables the complementary goals & incentives of every user in the system to make it thrive.
>>>
>>> It has been shown that users control Bitcoin (UASF) and thus ultimately miners would be incentivized to do what users want, up to the point of inability or loss. Correct?
>>>
>>> So, in contrast, how would the opposite, a user-compatible design, express? Well, I think the idea of txns being able to signal intent and desired behavior is more interesting (more useful) than a mempool that overrides all intent with RBF, and possibly more incentive-compatible than mempoolfullrbf as concept.
>>>
>>> Since we can’t be sure what the market wants, but we can be sure that the more users we have, making the most possible txns, at the highest possible prices, will yield the most valuable Bitcoin, and thus the most hashpower, we could entertain giving users the most ways to express their intent, the most flexibility.
>>>
>>> The most basic design would be to simply have no mempool policy at all, and let market incentives emerge on their own, but we have a status quo to consider, and most users do not have the technical expertise to express their own policies with misc patches and hacks of their Bitcoin Core software.
>>>
>>> I know this is a bit of a high-level abstract perspective, but I think it is important to respect such dynamics when making smaller decisions. It certainly is not our charge to prioritize what miners want any more than any other user type, nor is it within our ability to predict the future or fully model incentives of all players across all use cases.
>>>
>>> I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate.
>>>
>>> So, what to do?
>>>
>>> —
>>>
>>> John Carvalho
>>> CEO, Synonym.to
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221211/d69ce1a1/attachment-0001.html>

2023-06-07 23:17:36

- reply

📅 Original date posted:2022-12-11
📝 Original message:Hey John
There was a discussion [0] started by Lisa on the mailing list last year on whether there is any point to a full node maintaining a mempool last year which you may find interesting. I also recommend Gloria's presentation [1] from Adopting Bitcoin last year on transaction relay policy.
I think those are better resources than anything I could write. But I guess I'd summarize it like this. The job of the P2P/mempool/policy protocol devs in setting defaults is to ensure anyone can effectively propagate a consensus valid transaction across the network ultimately making its way into miners' mempools without harming network health (full node uptime, DoS attacks etc) and to give higher layers built on top of the Bitcoin network the best chance to succeed. If they totally screwed up that job with the defaults or they were unable to cater for a particular use case within default policy then there is always the alternative of submitting consensus valid transactions directly to miners bypassing the P2P network entirely. But clearly it is much better if the P2P network functions smoothly and every transaction isn't forced to be directly submitted to a miner. It is policy too of course rather than consensus so if the full node operator wants to change from the defaults they are free to do so without risking being forked off the network or risking a chain split.
> I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate.
This stuff is difficult to follow and understand especially for people who haven't been into Bitcoin for long or are trying to build Bitcoin businesses full time, there are lots of subtleties. I've certainly struggled at many points in my learning journey and I'm sure I will continue to do so in future. So there is no scoffing (from me at least) at individuals trying to learn and businesses trying to thrive and provide services to their customers. Unfortunately there are occasionally scenarios where trade-offs have to be weighed up and decisions have to be made where some people aren't happy. You may disagree but I'm a lot more comfortable delegating responsibility for policy defaults to those who have worked full time in this area for years than say consensus changes where I think we all have a responsibility to ensure suboptimal or worse harmful changes aren't made to the consensus rules. I thought your input on the CTV discussion earlier in the year was really positive for example. On this topic though I think you could do with doing some more reading as there is a lot of past discussion. I'm sure those who work in this area full time would be happy to answer any questions you have if you do.
Thanks
Michael
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019572.html
[1]: https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, December 10th, 2022 at 14:10, John Carvalho via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> As we debate mempoolfullrbf, and I familiarize myself with related PRs from engineers trying to reign in all of the possible behaviors that make it inconsistent, I can’t help but think about how I see people using the term “incentive-compatible” and how it seems to be awfully presumptive.
>
> The idea that a single Bitcoin transaction can be “incentive-compatible” by simply restricting it to having a higher fee or fee rate is theoretical, likely narrow, and not totally objective. RBF is inherently a fee-minimization tool, which as a concept, as I understand “incentive-compatibility” to be about miners in this context, makes RBF to be anti-incentives; miners are fee maximizers.
>
> Miners want the most fees per block, and per lifetime, do they not? If miners, and the mempool, are prioritizing for the smallest txns with the highest fees, over the longest acceptable amount of time, this may conflict with extra-mempool behaviors that result in more txns per block / per lifetime.
>
> If this isn’t making sense yet, let me summarize by how such a problem would express: a per-transaction fee-minimized, fully replaceable mempool as policy, that appears to always require the highest fee per txn, but ultimately includes less txns per block and less fees per lifetime. Basically, less use cases, less users, less txns — all to enforce a misunderstood theory and predictive speculation of what people want out of the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don’t need to do anything at all to facilitate bidding on a use case like replacement.
>
> Bidding does not require protocol enforcement, it is miner-subjective. So why are we pursuing it? Why do we even have RBF? Why are we trying to clean up all of the mess RBF creates with more and more code? If bidding is already accepted as incentive-compatible, and Bitcoin already allows setting a fee, then replacement requires no special code at all.
>
> I would think a holistic definition of what is incentive-compatible would be something more like what is “market compatible” and enables the complementary goals & incentives of every user in the system to make it thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimately miners would be incentivized to do what users want, up to the point of inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design, express? Well, I think the idea of txns being able to signal intent and desired behavior is more interesting (more useful) than a mempool that overrides all intent with RBF, and possibly more incentive-compatible than mempoolfullrbf as concept.
>
> Since we can’t be sure what the market wants, but we can be sure that the more users we have, making the most possible txns, at the highest possible prices, will yield the most valuable Bitcoin, and thus the most hashpower, we could entertain giving users the most ways to express their intent, the most flexibility.
>
> The most basic design would be to simply have no mempool policy at all, and let market incentives emerge on their own, but we have a status quo to consider, and most users do not have the technical expertise to express their own policies with misc patches and hacks of their Bitcoin Core software.
>
> I know this is a bit of a high-level abstract perspective, but I think it is important to respect such dynamics when making smaller decisions. It certainly is not our charge to prioritize what miners want any more than any other user type, nor is it within our ability to predict the future or fully model incentives of all players across all use cases.
>
> I know some of you may scoff at my bias for use cases like zero-conf, but what I am trying to convey is a possible folly in active management, speculation, and misapplied game theory that may permeate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / zero-conf debate.
>
> So, what to do?
>
> —
>
> John Carvalho
> CEO, Synonym.to
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221211/e7e913a6/attachment-0001.html>

2023-06-07 23:17:21

- reply

📅 Original date posted:2022-12-05
📝 Original message:> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun wallet developers) could work on a fork and run several nodes with such functionality.
Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is possible with him. But as others have said turning a mempool policy issue (users have always been free to choose whatever policy they like with zero chain split risk) into a consensus issue and a contentious soft fork issue at that would not be advised. I highly doubt any of the long term Muun contributors would want to support a contentious soft fork and fight a consensus rule war on this.
[0]: https://coingeek.com/gap600-ceo-daniel-lipshitz-talks-bsv-powered-stablecoins-on-coingeek-backstage-video/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, December 5th, 2022 at 16:12, Rijndael via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand a transaction to a miner privately. I hand a transaction to a miner with some reasonable fee, and then I go and broadcast a different transaction with a minimal fee that spends the same inputs. The whole network (including the miner I handed the tx to) could all be running with a strict first-seen mempool policy, but we can still have a situation where the miner creates a block with a different transaction from what you see in your mempool. If anytime this happens, the nodes running your proposed rule drop the block, then anyone can fork those nodes off the network whenever they want.
>
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt to) promise consistency across mempools. Making a consensus rule that enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
> - rijndael
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
>> The only option I see against the attack Peter Todd is doing to opt-in RBF and 0Conf bitcoin usage is working on a bitcoin core implementation that stops propagation of full-rbf replaced blocks. Running multiple of such nodes on the network will add a risk to miners that enable full-rbf that would work as an incentive against that.
>>
>> Obviously that would require adding an option on bitcoin core (that is not technically but politically difficult to implement as Petter Todd already have commit access to the main repository).
>>
>> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun wallet developers) could work on a fork and run several nodes with such functionality. As far as I understand the percolation model, with 10 to 20 nodes running such a rule would create a significant risk for full-rbf miners.
>>
>> Regards.
>>
>> --- Eloy
>>
>> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev wrote:
>>>> On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote:
>>>> > FYI I've gotten a few hundred dollars worth of donations to this effort, and
>>>> > have raised the reward to about 0.02 BTC, or $400 USD at current prices.
>>>>
>>>> Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>>
>>> I'm turning it back on when (if) the mempool settles down. I've got more than
>>> enough donations to give another run at it (the majority was donated privately
>>> FWIW). There's a risk of the mempool filling up again of course; hard to avoid
>>> that.
>>>
>>> Right now of course it's really easy to double spend with the obvious
>>> low-fee/high-fee method as the min relay fee keeps shifting.
>>>
>>>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>>>>
>>>> The block it was claimed in seems to have been about an hour after the
>>>> default mempool filled up:
>>>>
>>>> https://twitter.com/murchandamus/status/1592274621977477120
>>>>
>>>> That block actually seems to have included two
>>>> alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>>>> (309sat/vb):
>>>>
>>>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>>
>>> The second is because I turned down the full-rbf reward to more normal fee
>>> levels. There's also another full-rbf double-spend from the Bob calendar, along
>>> the same lines: 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>>
>>> I double-spent the txin of the high fee tx that got mined. But I mistakenly had
>>> RBF enabled in that double-spend, so while it propagated initially, I believe
>>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb tx.
>>>
>>>> Timeline (utc) to me looks like:
>>>>
>>>> - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb
>>>> - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>>>> is announced and propogates widely (1.2sat/vb)
>>>> - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>>>> is announced and propogates widely (1.2sat/vb)
>>>> - 21:52 - ba967010 tx is announced and propogates widely, since
>>>> conflicting tx 746daab9 has been removed from default
>>>> mempools
>>>> - 21:53 - murch tweets about default mempool filling up
>>>> - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>>>> conflicting tx f503868 has already been removed from default
>>>> mempools
>>>
>>> Is that 22:03 time for 397 from your node's logs? It was originally announced
>>> hours earlier. From one of my full-rbf nodes:
>>>
>>> 2022-11-14T14:08:37Z [mempool] replacing tx 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for 0.00468 additional fees, -1 delta bytes
>>>
>>>> - 22:35 - block 763189 is mined
>>>> - 22:39 - block 763190 is mined
>>>> - 23:11 - block 763191 is mined
>>>> - 23:17 - block 763192 is mined including 397dcbe4
>>>>
>>>> miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>>>> first three blocks, and gives similar mempool ages for those txs to what
>>>> my logs report:
>>>>
>>>> https://miningpool.observer/template-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>>>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>>>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>>>>
>>>> That presumably means those pools (AntPool twice and "unknown") are
>>>> running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>>
>>> To be clear, you think that AntPool and that other exchange is running with a
>>> larger than normal max mempool size limit? You mean those miners *did* keep the
>>> earlier 1.2sat/vb tx?
>>>
>>>> The txs were mined by Foundry:
>>>>
>>>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>>>>
>>>> This seems to be pretty good evidence that we currently don't have any
>>>> significant hashrate mining with fullrbf policies (<0.5% if there was a
>>>> high fee replacement available prior to every block having been mined),
>>>> despite the bounty having been collected.
>>>
>>> Oh, we can put much lower bounds on that. I've been running OTS calendars with
>>> full-rbf replacements for a few months without clear evidence of a full-rbf
>>> replacement. While there was good reason to think some miners were mining
>>> full-rbf before a few years back, they probably didn't bother to reapply their
>>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/60f49caa/attachment-0001.html>

2023-06-07 23:17:04

- reply

📅 Original date posted:2022-11-22
📝 Original message:Hi alicexbt
Thanks for setting this up. Generally it seems to me like an excellent idea to set up custom signets (and/or get proposals enabled on the default signet) for testing and experimenting with new proposals.
I have two questions.
1) In this particular case the -mempoolfullrbf configuration option is in the recent Bitcoin Core 24.0 release and so can be used both on mainnet and the default signet, testnet etc. What could be tested on this custom signet that can't be tested on the default signet with Bitcoin Core 24.0? Perhaps there are some things that are easier to test with a smaller custom signet network starting from scratch?
2) I know a number of people have struggled (e.g. [0], [1]) to get a custom signet set up. I think the CTV signet took a while to get set up too. It seems you followed the instructions on the Bitcoin wiki [2] for setting this one up? Was there anything you found difficult or was counterintuitive getting this custom signet set up? You are the sole block signer on this custom signet. How regularly are you mining blocks (e.g. strictly every 10 minutes, replicating the Poisson process on mainnet, adhoc etc?) Are you running this custom signet node on the same machine as a default signet, mainnet, testnet full node? I'm a little tentative to start joining custom signet networks on the same machine that is already running other nodes but perhaps there are no problems.
I'm not sure yet if I have a use case in mind for this particular custom signet but I'm very interested in custom signet setup generally and the docs/resources to make this as easy as possible so thanks again for posting about this.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/114477/could-someone-share-with-me-some-documentations-or-sites-on-how-to-set-up-a-cust
[1]: https://bitcoin.stackexchange.com/questions/114724/peer-discovery-on-a-custom-signet-custom-signetchallenge
[2]: [0]: https://en.bitcoin.it/wiki/Signet#Custom_Signet
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, November 20th, 2022 at 08:36, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,
>
> I have setup a [custom signet][0] for testing full RBF. You can connect to one or more of these nodes using `addnode`:
>
> 13.115.34.55 (issuer, full-rbf)
> kfupbqwb2yvzzqjomfq5pkem553a6uzp2k73seqn4d46smy7azua.b32.i2p (rbf-optin)
> luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion (full-rbf)
>
> Example config:
>
> `signet=1 signetchallenge=5121035daaa313aada6310340a242af17238cc1fd8849e875940bce65a60ac7e0e0ff751ae proxy=127.0.0.1:9050 [signet] addnode=luvczzzppiqnc2b7poivkxlugafe3uqaj245ebjqxtceio7poaorqcyd.onion mempoolfullrbf=1`
>
> Example for a simple test case:
>
> - Run 2 nodes
> - Connect node 1 with i2p node and use default opt-in rbf
> - Connect node 2 with node 1 and onion node. This node should use `mempoolfullrbf=1` in config and compile bitcoind using PR [#26454][1] branch
> - Broadcast Tx1 using node 2 and replace with Tx2 using `bumpfee` RPC
>
> It will be fun to test with more nodes joining this custom signet. If anyone interested to test, please post your bitcoin address in [full-rbf room][2]. We can even setup an explorer if this experiment makes sense.
>
> [0]: https://en.bitcoin.it/wiki/Signet#Custom_Signet
> [1]: https://github.com/bitcoin/bitcoin/pull/26454
> [2]: #full-rbf:matrix.org
>
> Sent with Proton Mail secure email.
>
> /dev/fd0
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:14:02

- reply

📅 Original date posted:2022-10-02
📝 Original message:Thanks for this AJ, especially the history on prior soft forks, the vast majority of which I was unclear on.
> The point of doing it via signet and outside of core is there doesn't
need to be any community consensus on soft forks. Unlike mainnet, signet
sBTC isn't money, and it isn't permissionless; and unlike merging it
into core, there isn't a risk of a mege having unintended side effects
impacting mainnet operation.
Agreed. I'm obviously much happier with proposed consensus changes being activated prematurely on a signet (default or custom) than on mainnet.
> Because signet mining is a closed set (determined by the first block
after genesis when the signetchallenge is locked in), signet soft forks
always have gatekeepers.
I'm also perfectly happy with the status quo of the default signet having block signers and gatekeepers for soft forks activated on the default signet. I'm more concerned with those gatekeepers being under pressure to merge unfinished, buggy soft fork proposals on the default signet which need to be reversed or changed disrupting all default signet users. The bar for mainnet activations is obviously much higher than for the default signet but the default signet does still need a bar.
> If you don't want to risk any disruption, then regtest or a private
signet is a better option. A global p2p network *always* has risk of
disruption at some level or another.
Right but disruption isn't boolean, it is a spectrum. It isn't disruption or zero disruption. The more soft fork proposals that are enabled on the default signet (and the more changes to those soft fork proposals pushed to the default signet) the higher the risk of a stalling blockchain (your signet node rejects a block the rest of the signet network accepts). The small number of block signers (currently 2) should prevent you being forked off entirely onto a different default signet chain with new mined blocks being added to your blockchain tip but your blockchain could stall.
What should happen in this scenario? Say I'm a default signet full node runner and I don't want to run any code outside of say the Bitcoin Core repo. I don't care about the proposed soft forks being tested on the default signet, I just care about testing my application with the existing consensus rules on mainnet. However, my default signet blockchain has stalled because of some consensus rule adjustment (an effective hard fork) made by the signet miners and the block signers. I have to run a patch from bitcoin-inquisition to get my node adding blocks again? I'm essentially being forced to run code from bitcoin-inquisition or wait many months for a default signet checkpoint in a Core release.
I looked into linux-next[0] which you mentioned as an interesting parallel in the Linux ecosystem on last week's Bitcoin Optech Twitter Spaces [1]. In that link linux-next is described as:
"The linux-next tree is the holding area for patches aimed at the next kernel merge window."
I guess I'd also want expectations to be tempered a little for consensus changes on bitcoin-inquisition versus say this description of linux-next. I don't know where the bar will be set for default signet soft fork activations by the block signers and the miners but wherever it is set it will be lower than mainnet. And to be considered for activation on mainnet these proposals do require community consensus if we want to minimize the risk of mainnet chain splits. There are no block signers or regularly updated checkpoints on mainnet. It is certainly possible that soft fork proposals that get activated on the default signet never get activated on mainnet and that being activated on the default signet offers no guarantees or even intentions/aims for the next Bitcoin Core (or any alternative implementation) release. I'd like to avoid the "my soft fork proposal has been activated on the default signet so you should expect it to be activated on mainnet within x months or y years" type thing.
Thanks
Michael
[0]: https://www.kernel.org/doc/man-pages/linux-next.html
[1]: https://twitter.com/bitcoinoptech/status/1574697495325974528?s=20&t=XWkpA459C9qxOOrBuP2fYA
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, October 2nd, 2022 at 07:12, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Sep 16, 2022 at 05:15:45PM +1000, Anthony Towns via bitcoin-dev wrote:
>
> > So that's the concept. For practical purposes, I haven't yet merged
> > either CTV or APO support into the bitcoin-inquisition 23.0 branch yet
>
>
> I've now merged CTV and updated my signet miner to enforce both CTV and
> APO (though you'd need to be either lucky or put some effort into it to
> figure out how to get a CTV/APO transaction relayed to my miner).
>
> Updating APO to be compatible with CTV actually seems to have found a
> previously unknown bug in the CTV PR against core [0], so that seems
> productive at the very least.
>
> [0] https://github.com/bitcoin-inquisition/bitcoin/pull/8
> https://github.com/bitcoin/bitcoin/pull/21702#pullrequestreview-1118047730
>
> I've also mined a couple of test APO transactions [1]; both reusing an
> APOAS signature [2], including demonstrating the case where a third party
> can replay APO signatures to send funds from duplicate UTXOs to fees,
> by spending those UTXOs in a single tx [3] [4].
>
> [1] https://mempool.space/signet/address/tb1pesae595q3cpzp8j3gy07gussw9t9hh580xj027sfz6g8e530u3nqscn0yn
>
> [2] "ec764a8ed632916868ca6dbfdc5bed95f74b83be62d01397aba7ec916982c6721c923fa22d29b5e0c4fddde0148233f0cf401758df23d8cc89c88f04beffc3c3c1" -- sighash of 0xc1 = ANYPREVOUTANYSCRIPT|ALL
>
> https://mempool.space/signet/tx/ee6f6eda93a3d80f4f65f2e1000334132c9a014b3ed3dec888fdcc1f3441f52c
> https://mempool.space/signet/tx/2cbcc4857e6ee8510d9479c01fbf133a9a2cde3f5c61ccf9439c69b7b83334ba
>
> [3] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#Signature_replay
>
> [4] https://mempool.space/signet/tx/53a9747546e378956072795351e8436cf704da72d235c8ac7560787b554a4d3f
>
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:13:36

- reply

📅 Original date posted:2022-09-28
📝 Original message:I've given this some extra thought and discussed with others who may later chime in on this thread. I'm now convinced this should be done on a custom public signet rather than on the default signet. SegWit was added to a new testnet (Segnet) for testing rather than the pre-existing testnet and I think future soft fork proposals should follow a similar approach.
Even if there is community consensus on what soft fork proposals should be added to the default signet today (which may or may not be case) I find it highly unlikely this will always be the case. We then get into the situation where the block signers (currently AJ and Kalle) are the gatekeepers on what soft fork proposals are added. The default signet is directly supported with the -signet flag in Bitcoin Core. Even if we are moving the proposed soft fork code to an external repo (to avoid it being merged into Core prematurely) it is still determining what soft forks are accessible from the signet flag in Bitcoin Core. I don't think it is fair on the signet block signers to put them in that position and I don't think it is wise to put other Bitcoin Core contributors/maintainers in the position of having to defend why some proposed soft forks are accessible on the default signet while others aren't.
The default signet was a long term project to address the unreliability and weaknesses of testnet. Many default signet users won't be interested in testing soft fork proposals and it is not reasonable for them to be subject to a stalling or forked blockchain because changes to a soft fork proposal or a buggy soft fork proposal pushed to the default signet makes previous valid/invalid transactions invalid/valid. If they want to test proposed soft forks on a custom signet they are opting in to possible disruption rather than it being forced upon them.
By focusing on custom signets rather than the default signet it also allows for more experimentation. Don't like the choices of which soft fork proposals have been added to bitcoin-inquisition? Set up your own custom signet with a different set of soft fork proposals and get users for your custom signet on a level playing field to bitcoin-inquisition. A soft fork proposal is found to be strictly inferior to another soft fork proposal? Just spin down the custom signet with that inferior soft fork proposal on it without impacting default signet users.
So TL;DR still enthusiastic about this concept. Just with a strong preference that it is done on a custom signet rather than on the default signet.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, September 19th, 2022 at 11:05, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, Sep 18, 2022 at 02:47:38PM -0400, Antoine Riard via bitcoin-dev wrote:
>
> > Said succinctly, in the genesis of creative ideas, evaluation doesn't
> > happen at a single clear point but all along the idea lifetime, where this
> > evaluation is as much done by the original author than its peers and a
> > wider audience.
>
>
> Sure. I definitely didn't mean to imply a waterfall development model,
> or that the phases wouldn't overlap etc.
>
> > I would still expose a concern to not downgrade in the pure empiricism in
> > matter of consensus upgrades. I.e, slowly emerging the norm of a working
> > prototype running on bitcoin-inquisition` as a determining factor of the
> > soundness of a proposal. E.g with "upgrading lightning to support eltoo", a
> > running e2e won't save us to think the thousands variants of pinnings, the
> > game-theory soundness of a eltoo as mechanism in face of congestions, the
> > evolvability of APO with more known upgrades proposals or the
> > implementation complexity of a fully fleshed-out state machine and more
> > questions.
>
>
> I agree here; but I think not doing prototypes also hinders thinking
> about all the thousands of details in a fork. It's easy to handwave
> details away when describing things on a whiteboard; and only realise
> they're trickier than you thought when you go to implement things.
>
> > E,g if one implements the "weird" ideas
> > about changes in the block reward issuance schedule discussed during the
> > summer, another one might not want "noise" interferences with new
> > fee-bumping primitives as the miner incentives are modified.
>
>
> (I don't think "miner incentives" are really something that can be
> investigated on signet. You can assume how miners will respond to
> incentives and program the mining software to act that way; but there's
> no competitive pressure in signet mining so I don't think that really
> demonstrates anything very much. Likewise, there's much less demand for
> blockspace on signet than on mainnet, so it's probably hard to experiment
> with "fee incentives" too)
>
> > I hope the upcoming
> > Contracting Primitives WG will be able to document and discuss some of the
> > relevant experiments run on bitcoin-inquisition.
>
>
> Likewise.
>
> (Lots trimmed due to either agreeing with it or having nothing to add)
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:13:33

- reply

📅 Original date posted:2022-09-18
📝 Original message:Hi alicexbt
> Good to see some positivity, finally.
I had enthusiasm for this concept of enabling proposed soft fork functionality on signet 2 years ago [0]. Nothing has changed, still enthusiastic :) Not enthusiastic about the months wasted on unnecessary contentious soft fork drama since but can't change the past.
> 1)Nobody uses Liquid. Signet has more activity than Liquid.
2)Testing something on Liquid will be completely different as its
a separate blockchain with some similarities.
Perhaps you should take your own advice with regards to positivity (or at least have more of an open mind) with regards Liquid and sidechains. Signet Bitcoin are totally free [1] and experimentation doesn't ever result in loss of real monetary value so you would expect more experimentation on signet versus Liquid long term. However, building protocols and prototypes with real monetary value is a step up from doing so with worthless signet coins. So I don't really see them as direct competitors. Some things take a lot longer to come to fruition than others but the original vision [2] of sidechains still makes perfect sense to me. Competing sets of consensus rules aren't possible on a single mainnet blockchain. Hence you either go the sidechain(-like) route or you go the altcoin route if you want to take the step up from signet/testnet and start using real monetary value. I much prefer the sidechain model to the altcoin route myself. Especially when in say vaults you do want the equivalent of Bitcoin to be locked up rather than a more volatile altcoin.
Thanks
Michael
[0]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining
[1]: https://signetfaucet.com/
[2]: https://blockstream.com/sidechains.pdf
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, September 18th, 2022 at 13:27, alicexbt <alicexbt at protonmail.com> wrote:
> Hi Michael,
>
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time" 0 and "it was the lack of process that was the problem" the better.
>
>
> The linked gist cannot be taken seriously and I am not sure why you keep sharing it as some document to prove there was no technical consensus for BIP 119. Nadav has already mentioned this in the comments. If you care about community consensus, maybe feedback about the links in that gist should also be respected. There was chaos, misinformation and lot of drama on twitter. Some people that opposed CTV on twitter still have no clue what CTV actually does and a few were super enthusiastic because of the author for BIP 119.
>
> > I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it 1 whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it.
>
>
> Good to see some positivity, finally. Because tx introspection aka covenants would help everyone involved in bitcoin. This idea of experimenting with soft forks on signet together with research and meetings suggested by Antoine should help in better evaluation phase with less drama, politics etc. and more technical discussions to reach a goal.
>
> > I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled 2 there but maybe there is more happening than I'm aware of.
>
>
> 1)Nobody uses Liquid. Signet has more activity than Liquid.
> 2)Testing something on Liquid will be completely different as its a separate blockchain with some similarities.
>
> I have summarized a few other positives of testing soft forks on signet based on AJ's email:
>
> a)Better evaluation
> b)PR implementing soft fork could be reviewed and merged outside core
> c)Testing on signet with pre-existing signet infrastructure
> d)Can deploy multiple consensus changes so easier to compare alternative approaches (eg CTV vs ANYPREVOUT vs OP_TXHASH vs OP_TX, etc)
> e)Pre-baked ability to abandon the soft fork
> f)No need to regularly rebase consensus changes against bitcoin core's master branch
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Saturday, September 17th, 2022 at 3:53 PM, Michael Folkson via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time" 0 and "it was the lack of process that was the problem" the better. If people don't care about lack of community consensus there is no process in a permissionless, open source community that can stop them or direct them down a more patient, productive path (I tried). I think it is a shame because I think (maybe I'm wrong) at least in the technical community there is an understanding that long term Bitcoin is far from finished in exhausting its potential and we do need people who will work on changes that we'll need in the long term.
> >
> > There are a few interesting things in here though. I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it 1 whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it. I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled 2 there but maybe there is more happening than I'm aware of. Protocols or use cases built out and demonstrated on signet (and/or Liquid/sidechains) seem an obvious stepping stone to me for convincing the community that it is potentially worth taking the chain split risk for a particular upgrade. It is a long slog to get community consensus on an upgrade (Taproot certainly was a slog) but I think the vast majority of us think Taproot was worth that slog and Bitcoin would be poorer today without it.
> >
> > The Great Consensus Cleanup is an interesting example in that I get Matt doesn't have time to champion it or focus on it with his LDK commitments but I have no idea where it would rank on his long term priority list if he wasn't working on LDK. Similarly I have no idea what people who understand this evolving system much better than I do are thinking with regards to say adding new opcodes, sighash flags versus say waiting on Simplicity and possibly adding new functionality within that potential upgrade. For people like me who are extremely unlikely to propose their own consensus change(s) getting some signal on what to spend time digging into would be useful rather than second guessing what people are thinking. There is a danger that you flirt with perceived public roadmaps when possible authority figures stick their necks out and effectively say "I'm not in charge but in an imaginary world where I was this is my current thinking of the ordering in which we could improve this system
> > long term. But this could change depending on x, y and z and possible upgrades are only ready when they're ready and they have community consensus." There is no way people don't play these exercises in their minds. I do, I just have very few answers :) I personally think APO is in prime position to improve Lightning channel state management with eltoo and if it enables some covenant schemes too that seems like an added bonus. On APO versus waiting for APO like functionality in Simplicity I have no idea. Work on APO/eltoo and Simplicity both seem to be progressing in parallel so the APO versus Simplicity discussion perhaps rests on whether people think certain covenants should only really be enabled once we have the security guarantees of Simplicity 3 (if at all).
> >
> > Antoine's covenant R&D effort 4 seems really promising and I hope the shenanigans from earlier in the year don't put people off from engaging with that. Hopefully we can see more exploration, development and research in covenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways to Control the Future" 5) and we can foster a community which has very high standards, is open to new ideas and new research but can avoid these months long resisting chain split fights. I think the discussion would be much more interesting and much more productive if people didn't have to think "If I express a view now it will be used to attack me personally later" or worse "If I express a view now it will be used to justify an upcoming chain split".
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> >
> > ------- Original Message -------
> > On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > On 9/17/22 2:14 AM, Anthony Towns wrote:
> > >
> > > > On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote:
> > > >
> > > > > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > > > >
> > > > > > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier
> > > > > > in the year 0, the question of "how to successfully get soft fork
> > > > > > ideas from concept to deployment" doesn't really have a good answer today.
> > > > > > I strongly disagree with this.
> > > >
> > > > Okay? "X is good" is obviously just a statement of opinion, so if you
> > > > want to disagree, that's obviously allowed.
> > > >
> > > > I also kind of feel like that's the least interesting paragraph in the
> > > > entire email to talk further about; if you think the current answer's
> > > > already good, then the rest of the mail's just about (hopefully) making
> > > > it better, which would be worthwhile anyway?
> > >
> > > No, I think its at least a good chunk of the "statement of problem". Yes, more testing is good, and
> > > this project is a way to get that. Cool. But implying that lack of test frameworks is in any
> > > material way part of the lack of movement on forks in Bitcoin I think is very wrong, so its worth
> > > pointing out, whether the particular project is useful or not is separate.
> > >
> > > > > Going back many, many years we've had many
> > > > > discussions about fork process, and the parts people (historically) agreed
> > > > > with tend to be:
> > > > > (1) come up with an idea
> > > > > (2) socialize the idea in the technical community, see if anyone comes up
> > > > > with any major issues or can suggest better ideas which solve the same
> > > > > use-cases in cleaner ways
> > > > > (3) propose the concrete idea with a more well-defined strawman, socialize
> > > > > that, get some kind of rough consensus in the loosely-defined, subjective,
> > > > > "technical community" (ie just ask people and adapt to feedback until you
> > > > > have found some kind of average of the opinions of people you, the
> > > > > fork-champion, think are reasonably well-informed!).
> > > > > (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there.
> > > > > Turns out, the issue today is a lack of champions following steps 1-3, we
> > > > > can debate what the correct answer is to step (4) once we actually have
> > > > > people who want to be champions who are willing to (humbly) push an idea
> > > > > forward towards rough agreement of the world of technical bitcoiners
> > > > > (without which I highly doubt you'd ever see broader-community consensus).
> > > >
> > > > Personally, I think this is easily refuted by contradiction.
> > > >
> > > > 1) If we did have a good answer for how to progress a soft-fork, then
> > > > the great consensus cleanup 0 would have made more progress over the
> > > > past 3.5 years
> > >
> > > No? Who is the champion for it? I haven't been. No one else is obliged to take up the reins and run
> > > with it, that's not how open-source works. And no one has emerged who has strong interest in doing
> > > so, and that's totally fine. It means it hasn't made any progress, but that's an indication that no
> > > one feels strongly enough about it that its risen to the top of their personal priority list so
> > > clearly doesn't need to make progress.
> > >
> > > > Maybe not all of the ideas in it were unambiguously good
> > > > 1, but personally, I'm convinced at least some of them are, and I
> > > > don't think I'm alone in thinking that. Even if the excuse is that its
> > > > original champion wasn't humble enough, there's something wrong with
> > > > the process if there doesn't exist some other potential champion with
> > > > the right balance of humility, confidence, interest and time who could
> > > > have taken it over in that timeframe.
> > >
> > > No? Its not up to the community to find a champion for someone who wants a fork to happen. Either
> > > someone thinks its a good enough idea that they step up, or no one does. If no one does, then so be
> > > it. If the original proper (me, in this case) thought it was that important then its their
> > > responsibility to be the champion, no one else's.
> > >
> > > > 2) Many will argue that CTV has already done steps (1) through (3) above:
> > > > certainly there's been an idea, it's been socialised through giving talks,
> > > > having discussion forums, having research workshops 2, documenting use
> > > > cases use cases; there's been a concrete implementation for years now,
> > > > with a test network that supports the proposed feature, and new tools
> > > > that demonstrate some of the proposed use cases, and while alternative
> > > > approaches have been suggested 3, none of them have even really made
> > > > it to step (2), let alone step (3).
> > >
> > > I don't really see how you can make this argument seriously. Honestly, if a soft-fork BIP only has
> > > one author on the list, then I'm not sure one can argue that step (3) has really been completed, and
> > > maybe not even step (2).
> > >
> > > > So that leaves a few possibilities
> > > > to my mind:
> > >
> > > > * CTV should be in step (4), and its lack of definition is a problem,
> > > > and trying the "deal with it when we get there" approach is precisely
> > > > what didn't work back in April.
> > > >
> > > > * The evaluation process is too inconclusive: it should either be
> > > > saying "CTV is not good enough, fix these problems", or "CTV hasn't
> > > > sufficiently demonstrated its value/cost, work on X next", but it
> > > > isn't.
> > > >
> > > > * Parts (2) to (3) are too hard, and that's preventing alternatives
> > > > from making progress, which in turn is preventing people from
> > > > being able to decide whether CTV is the superior approach, or some
> > > > alternative is.
> > >
> > > I think this is most of it, but its not that they're too hard, its that people are too busy. There
> > > seemed to be more positive feedback, for example, to Rusty's proposal, but being the champion for a
> > > soft-fork is a full-time job for months on end, and last I checked Rusty has a lightning
> > > implementation to maintain, which tends to be a more-than-full-time job already.
> > >
> > > To my knowledge, no one but Jeremy has made any serious attempt at being the champion for a
> > > soft-fork since Taproot, and before that Segwit (if someone reading this who contributes to Core
> > > already wants to, and isn't sure how to, there's lots of people who would happily mentor you! I'm
> > > sure you can figure out who to reach out to!).
> > >
> > > Matt
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:13:32

- reply

📅 Original date posted:2022-09-17
📝 Original message:I agree with Matt. The less said about the "Aw shucks Jeremy didn't know that CTV didn't have community consensus at the time" [0] and "it was the lack of process that was the problem" the better. If people don't care about lack of community consensus there is no process in a permissionless, open source community that can stop them or direct them down a more patient, productive path (I tried). I think it is a shame because I think (maybe I'm wrong) at least in the technical community there is an understanding that long term Bitcoin is far from finished in exhausting its potential and we do need people who will work on changes that we'll need in the long term.
There are a few interesting things in here though. I'm not convinced by the name (bitcoin-inquisition, shedpaint, shedpaint, let's park that for the moment) but I do like the idea of signet having soft fork proposals enabled on it [1] whether that be CTV, APO etc and if that requires more of the signet code to be moved out of the Core repo so be it. I'm surprised more isn't being done on Liquid already with what possible future functionality is (and could be) enabled [2] there but maybe there is more happening than I'm aware of. Protocols or use cases built out and demonstrated on signet (and/or Liquid/sidechains) seem an obvious stepping stone to me for convincing the community that it is potentially worth taking the chain split risk for a particular upgrade. It is a long slog to get community consensus on an upgrade (Taproot certainly was a slog) but I think the vast majority of us think Taproot was worth that slog and Bitcoin would be poorer today without it.
The Great Consensus Cleanup is an interesting example in that I get Matt doesn't have time to champion it or focus on it with his LDK commitments but I have no idea where it would rank on his long term priority list if he wasn't working on LDK. Similarly I have no idea what people who understand this evolving system much better than I do are thinking with regards to say adding new opcodes, sighash flags versus say waiting on Simplicity and possibly adding new functionality within that potential upgrade. For people like me who are extremely unlikely to propose their own consensus change(s) getting some signal on what to spend time digging into would be useful rather than second guessing what people are thinking. There is a danger that you flirt with perceived public roadmaps when possible authority figures stick their necks out and effectively say "I'm not in charge but in an imaginary world where I was this is my current thinking of the ordering in which we could improve this system long term. But this could change depending on x, y and z and possible upgrades are only ready when they're ready and they have community consensus." There is no way people don't play these exercises in their minds. I do, I just have very few answers :) I personally think APO is in prime position to improve Lightning channel state management with eltoo and if it enables some covenant schemes too that seems like an added bonus. On APO versus waiting for APO like functionality in Simplicity I have no idea. Work on APO/eltoo and Simplicity both seem to be progressing in parallel so the APO versus Simplicity discussion perhaps rests on whether people think certain covenants should only really be enabled once we have the security guarantees of Simplicity [3] (if at all).
Antoine's covenant R&D effort [4] seems really promising and I hope the shenanigans from earlier in the year don't put people off from engaging with that. Hopefully we can see more exploration, development and research in covenants (e.g. this excellent research paper "Bitcoin Covenants: Three Ways to Control the Future" [5]) and we can foster a community which has very high standards, is open to new ideas and new research but can avoid these months long resisting chain split fights. I think the discussion would be much more interesting and much more productive if people didn't have to think "If I express a view now it will be used to attack me personally later" or worse "If I express a view now it will be used to justify an upcoming chain split".
[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[1]: https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining
[2]: https://bitcoin.stackexchange.com/questions/109764/what-opcodes-are-supported-on-liquid-but-not-yet-on-bitcoin
[3]: https://bitcoinops.org/en/topics/simplicity/
[4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020912.html
[5]: https://arxiv.org/pdf/2006.16714.pdf
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, September 17th, 2022 at 09:39, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 9/17/22 2:14 AM, Anthony Towns wrote:
>
> > On Fri, Sep 16, 2022 at 12:46:53PM -0400, Matt Corallo via bitcoin-dev wrote:
> >
> > > On 9/16/22 3:15 AM, Anthony Towns via bitcoin-dev wrote:
> > >
> > > > As we've seen from the attempt at a CHECKTEMPLATEVERIFY activation earlier
> > > > in the year [0], the question of "how to successfully get soft fork
> > > > ideas from concept to deployment" doesn't really have a good answer today.
> > > > I strongly disagree with this.
> >
> > Okay? "X is good" is obviously just a statement of opinion, so if you
> > want to disagree, that's obviously allowed.
> >
> > I also kind of feel like that's the least interesting paragraph in the
> > entire email to talk further about; if you think the current answer's
> > already good, then the rest of the mail's just about (hopefully) making
> > it better, which would be worthwhile anyway?
>
>
> No, I think its at least a good chunk of the "statement of problem". Yes, more testing is good, and
> this project is a way to get that. Cool. But implying that lack of test frameworks is in any
> material way part of the lack of movement on forks in Bitcoin I think is very wrong, so its worth
> pointing out, whether the particular project is useful or not is separate.
>
> > > Going back many, many years we've had many
> > > discussions about fork process, and the parts people (historically) agreed
> > > with tend to be:
> > > (1) come up with an idea
> > > (2) socialize the idea in the technical community, see if anyone comes up
> > > with any major issues or can suggest better ideas which solve the same
> > > use-cases in cleaner ways
> > > (3) propose the concrete idea with a more well-defined strawman, socialize
> > > that, get some kind of rough consensus in the loosely-defined, subjective,
> > > "technical community" (ie just ask people and adapt to feedback until you
> > > have found some kind of average of the opinions of people you, the
> > > fork-champion, think are reasonably well-informed!).
> > > (4) okay, admittedly beyond this is a bit less defined, but we can deal with it when we get there.
> > > Turns out, the issue today is a lack of champions following steps 1-3, we
> > > can debate what the correct answer is to step (4) once we actually have
> > > people who want to be champions who are willing to (humbly) push an idea
> > > forward towards rough agreement of the world of technical bitcoiners
> > > (without which I highly doubt you'd ever see broader-community consensus).
> >
> > Personally, I think this is easily refuted by contradiction.
> >
> > 1) If we did have a good answer for how to progress a soft-fork, then
> > the great consensus cleanup [0] would have made more progress over the
> > past 3.5 years
>
>
> No? Who is the champion for it? I haven't been. No one else is obliged to take up the reins and run
> with it, that's not how open-source works. And no one has emerged who has strong interest in doing
> so, and that's totally fine. It means it hasn't made any progress, but that's an indication that no
> one feels strongly enough about it that its risen to the top of their personal priority list so
> clearly doesn't need to make progress.
>
> > Maybe not all of the ideas in it were unambiguously good
> > [1], but personally, I'm convinced at least some of them are, and I
> > don't think I'm alone in thinking that. Even if the excuse is that its
> > original champion wasn't humble enough, there's something wrong with
> > the process if there doesn't exist some other potential champion with
> > the right balance of humility, confidence, interest and time who could
> > have taken it over in that timeframe.
>
>
> No? Its not up to the community to find a champion for someone who wants a fork to happen. Either
> someone thinks its a good enough idea that they step up, or no one does. If no one does, then so be
> it. If the original proper (me, in this case) thought it was that important then its their
> responsibility to be the champion, no one else's.
>
> > 2) Many will argue that CTV has already done steps (1) through (3) above:
> > certainly there's been an idea, it's been socialised through giving talks,
> > having discussion forums, having research workshops [2], documenting use
> > cases use cases; there's been a concrete implementation for years now,
> > with a test network that supports the proposed feature, and new tools
> > that demonstrate some of the proposed use cases, and while alternative
> > approaches have been suggested [3], none of them have even really made
> > it to step (2), let alone step (3).
>
>
> I don't really see how you can make this argument seriously. Honestly, if a soft-fork BIP only has
> one author on the list, then I'm not sure one can argue that step (3) has really been completed, and
> maybe not even step (2).
>
> > So that leaves a few possibilities
> > to my mind:
>
> > * CTV should be in step (4), and its lack of definition is a problem,
> > and trying the "deal with it when we get there" approach is precisely
> > what didn't work back in April.
> >
> > * The evaluation process is too inconclusive: it should either be
> > saying "CTV is not good enough, fix these problems", or "CTV hasn't
> > sufficiently demonstrated its value/cost, work on X next", but it
> > isn't.
> >
> > * Parts (2) to (3) are too hard, and that's preventing alternatives
> > from making progress, which in turn is preventing people from
> > being able to decide whether CTV is the superior approach, or some
> > alternative is.
>
>
> I think this is most of it, but its not that they're too hard, its that people are too busy. There
> seemed to be more positive feedback, for example, to Rusty's proposal, but being the champion for a
> soft-fork is a full-time job for months on end, and last I checked Rusty has a lightning
> implementation to maintain, which tends to be a more-than-full-time job already.
>
> To my knowledge, no one but Jeremy has made any serious attempt at being the champion for a
> soft-fork since Taproot, and before that Segwit (if someone reading this who contributes to Core
> already wants to, and isn't sure how to, there's lots of people who would happily mentor you! I'm
> sure you can figure out who to reach out to!).
>
> Matt
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:13:19

- reply

📅 Original date posted:2022-09-12
📝 Original message:Hi Ali
> do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?
Any generation of a signature(s), whether that be single key (e.g. OP_CHECKSIG), multisig with multiple signatures going onchain (e.g. OP_CHECKMULTISIG, OP_CHECKSIGADD) or key aggregation multisig with only a single signature going onchain (e.g. OP_CHECKSIG), requires private key(s) and hence has concerns with regards to security and theft of those private keys. Clearly funds locked behind any kind multisig arrangement is better than no multisig arrangement as otherwise theft of a single private key can result in loss of funds.
With regards to connectivity or interactivity key aggregation multisig does increase the interactivity requirements so if you wanted to minimize interactivity requirements you'd probably stick to OP_CHECKMULTISIG, OP_CHECKSIGADD that only requires you to generate a signature and then pass it onto the next signer.
> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.
I'm not sure what you mean here. In the realm of generating signatures there isn't really a concept of a "lite node". That makes more sense in the realm of verification where you may or may not be doing full verification. In the generating signatures realm you are either contributing to the aggregated signature or generating a standalone signature yourself. If you are not doing either of those and aren't doing some kind of coordination then you are entirely irrelevant to the scheme. In the case of Liquid there is a 11-of-15 threshold signature arrangement where currently 11 signatures go onchain when funds are moved but if Liquid used a key aggregation scheme like FROST only a single signature would need to go onchain. With regards to centralization/decentralization you could increase the 11-of-15 to say a 22-of-30. Or you could have a nested MuSig/FROST scheme behind one of the 11 signers of the 11-of-15. But you can't get around the fact that you are either generating a signature that ultimately contributes to the moving of the funds or you aren't. If you aren't generating a signature then you are just verifying the signature(s) that go onchain like all other full nodes on the network.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, September 11th, 2022 at 08:43, Ali Sherief <ali at notatether.com> wrote:
> Hi Michael.
>
> I read the transcript of the Socratic and I have to say that it is quite detailed and touches a lot of problems including the well-known theft/offline problems which also has forms elsewhere such as for passwords.
>
> My question is, do you or anyone else in the Socratic know of any research to this that's don't involve a trade-off of theft or online connectivity?
>
> ROAST and Liquid is perhaps the farthest I know of that addresses this problem, but it's using centralized nodes right now. I was thinking, maybe these federated nodes can be decentralized into a few of these "lite nodes" managed by each service wanting a payment, that make a threshold signature out of many subscribers paying at the same time.
>
> - Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220912/f261ff41/attachment.html>

2023-06-07 23:13:19

- reply

📅 Original date posted:2022-09-08
📝 Original message:Hi
We had an online Socratic on August 11th with Tim Ruffing (co-author of MuSig2 draft BIP) and Elizabeth Crites (co-author of research papers on MuSig(2), FROST). It was previously announced here [0] but ended up being rescheduled.
The transcript is here [1], the video is here [2] and a reading list collecting together a number of resources on MuSig(2), FROST, ROAST etc is here [3].
We discussed a retrospective look at BIP340, handling x-only public keys in MuSig2 and the proposed TLUV covenant opcode, the history from initially broken MuSig1 through MuSig-DN to MuSig2, how MuSig2 and FROST compare for multisig schemes (i.e. n-of-n), why MuSig2 doesn't use proofs of possession and the current state of the draft MuSig2 BIP.
We covered a lot of topics and it was rather long (~2.5 hours) so check out the transcript or video if you are interested in any of the above topics. Many thanks to those who participated.
Jonas Nick recently tweeted [4] that the MuSig2 BIP [5] is approaching a stable version 1.0 which should be helpful to those who are interested (or already!) using it in the wild.
[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020772.html
[1]: https://btctranscripts.com/london-bitcoin-devs/2022-08-11-tim-ruffing-musig2/
[2]: https://www.youtube.com/watch?v=TpyK_ayKlj0
[3]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c
[4}: https://twitter.com/n1ckler/status/1567168267025874944
[5]: https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220908/f6918882/attachment.html>

2023-06-07 23:12:35

- reply

📅 Original date posted:2022-08-06
📝 Original message:Hi alicexbt
What do you mean by "replacement transaction"? Replacing or swapping outputs with a counterparty's?
I guess I'm struggling to understand exactly what you are attempting to achieve here with regards to privacy and if this additional protocol complexity is worth it. Recall a 2 (or n) party coinjoin would get you an output where it isn't clear to blockchain observers which output you control and a coinswap [0] would have you taking the coin history of your counterparty. What does this scheme offer with regards to privacy that those don't? This seems to have more complexity too though I maybe misunderstanding something.
Thanks
Michael
[0]: https://bitcoinops.org/en/topics/coinswap/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Friday, August 5th, 2022 at 15:44, alicexbt via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Bitcoin Developers,
>
> Does it make sense to trade replacement transactions for privacy? I have shared basic details to implement this and would love to read opinions about it or ways to improve it:
>
> =============================
> alice
> =============================
>
> tx1: input a (0.01) -> output b1 (0.008)
> -> change c1 (0.001)
>
> tx2: input a (0.01) -> output e2 (0.007)
> -> output f2 (0.001)
>
> =============================
>
> bob
> =============================
>
> tx1: input d (0.011) -> output e1 (0.007)
> -> change f1 (0.003)
>
> tx2: input d (0.011) -> output b2 (0.008)
> -> output c2 (0.001)
>
> =============================
>
> carol
> =============================
>
> - creates an API to manage trades that will use 2 of 3 multisig
> - alice and bob create orders for replacement
> - either they could be matched automatically using some algorithm or bob manually accepts the offer
> - 2 of 3 multisig is created with Alice, Bob and Carol keys
> - bob locks 0.01 BTC in it and shares outputs e2,f2 with alice
> - alice signs tx2 and shares tx with bob
> - alice locks 0.011 BTC in it and shares outputs b2,c2 with bob
> - bob signs tx2 and shares with alice
> - both replacement txs can be broadcasted
> - funds are released from 2 of 3 multisig with a tx having 3 outputs (one to pay fee which goes to carol)
>
> positives:
>
> - privacy
>
> negatives:
>
> - extra fees
> - will take some time although everything will be managed by wallet with API provided by carol
> - need to lock bitcoin with same amount as used in tx1
> - amounts could still be used to link txs in some cases- carol and other peer knows the details
>
> /dev/fd0
>
> Sent with [Proton Mail](https://proton.me/) secure email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220806/efb828d3/attachment.html>

2023-06-07 23:12:33

- reply

📅 Original date posted:2022-08-04
📝 Original message:Thanks for this Luke.
> Since BIP125 is widely implemented, it should not be changed except for corrections to things which are errors deviating from the original intent.
In this example the BIP125/RBF rules implemented in Core are (and always have been) different to the rules as described in BIP125. As far as I know other implementations have also followed how it is implemented in Core rather than as described in BIP125. So we have the BIP125 rules, BIP125/RBF as implemented in Core and future intended changes to how RBF rules are implemented in Core which may or may not also be in a state of flux. I take the view that once those new RBF rules are "finalized" there should be a new BIP but others disagree.
> Also note that security should NEVER depend on assumptions of node policies. Doing so would be a serious security vulnerability, regardless of what actual network policies are.
You regularly state this and of course you're right. I tried to allude that it is far from ideal that L2 security is impacted by default policy rules to any extent in my post. But if it is a matter of fact that default policy rules impact the viability of some L2 protocol attacks today what should one do when setting default policy rules in the dominant implementation on the network? I think you lean towards not factoring that in whatsoever to decisions on default policy rules whereas (perhaps mistakenly) I lean towards factoring that in to default policy rule decisions especially when there don't seem to be many other factors to consider. In the case of Lightning Network I think we both want it to succeed and hopefully in the long term default policy rules will have no impact on its security whatsoever. But today that seems to not be the case.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Thursday, August 4th, 2022 at 20:35, Luke Dashjr <luke at dashjr.org> wrote:
> Policy is a subjective per-node, not systemic, not enforcable or expectable,
> and generally not eligible for standardization.
>
> The reason BIP125 is an exception, is because it is more than just policy.
> It is a way for wallets and nodes to communicate. The wallet is saying "this
> is the policy I would like you to apply to potential replacements of these
> transactions". Whether the nodes abide this request or not, the purpose and
> justification of the BIP is to standardize the communication of it.
>
> Since BIP125 is widely implemented, it should not be changed except for
> corrections to things which are errors deviating from the original intent.
> If there is merely a new policy intended to be conveyed, a new BIP should be
> written that is distinguishable from BIP125 (perhaps drop the sequence number
> by 1 more). However, unless nodes are going to honour both the BIP125-request
> policy and a new policy, it might be simpler for them to just not honour
> the requested BIP125 policy exactly.
>
> Also note that security should NEVER depend on assumptions of node policies.
> Doing so would be a serious security vulnerability, regardless of what actual
> network policies are. It's fine to blame nodes/miners if they single out your
> transactions, but if it's just a matter of a general policy your transactions
> are failing to meet, that's on the sender/L2 to adapt.
>
> Luke
>
>
> On Thursday 04 August 2022 14:54:54 Michael Folkson via bitcoin-dev wrote:
>
> > A short history of RBF and BIP125
> >
> > The history of BIP125 is as far as I’m aware this. RBF rules were merged
> > into Bitcoin Core in November 2015 0. Following that merge David Harding
> > and Peter Todd drafted a BIP (BIP125 1) outlining the RBF rules that had
> > been implemented in Bitcoin Core. The rationales for the rules in the BIP
> > was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!)
> > when L2 protocols were in their infancy. Certainly the research on the
> > security of L2 protocols has come a long way since and we have a much
> > better idea of some of the possible attacks on L2 protocols that to some
> > extent are impacted by policy rules.
> >
> > In addition it was discovered 2 in May 2021 that the Bitcoin Core
> > implementation of the RBF rules had never matched the RBF rules outlined in
> > BIP125. Clearly this isn’t ideal but mistakes happen and will continue to
> > happen. I certainly do not intend any criticism whatsoever to any of the
> > individuals involved. Thankfully this discrepancy doesn’t seem to have
> > resulted in any loss of funds or disruption. However, cross checking a
> > specification with an implementation presumably led to the discovery and
> > allowed for a post mortem on why the implementation didn’t match the
> > specification.
> >
> > There seems to be two views on what to do next given that the RBF rules
> > need to be updated. One is to ditch the idea of a specification for RBF
> > rules and just document them in the Core repo instead. The other is to have
> > a new specification for the RBF rules in Core and attempt to correct the
> > mistakes made with BIP125 by having a BIP that does correctly outline the
> > RBF rules implemented in Core and includes detailed rationales for why
> > those RBF rules have been implemented.
> >
> > Should anyone care about where things are documented?
> >
> > Perhaps not but I think if you are a stakeholder in L2 protocol security
> > you should. Suppose in the long term future an attacker exploits a L2
> > vulnerability that is based on the default policy set by the dominant
> > implementation on the network (Bitcoin Core). Which would you prefer the
> > norm to be? A detailed static, well reviewed BIP standard that lays out the
> > updated RBF rules and the rationales for those new rules that is reviewed
> > outside the Core repo and hence not just by Core reviewers? Or cross
> > checking Bitcoin Core code with non-standardized Core documentation
> > typically reviewed only by Core reviewers?
> >
> > For the same reason the norm for consensus changes is a specification (BIP)
> > and a reference implementation (Bitcoin Core) I think the norm for material
> > step change policy changes should be a specification (BIP) and a reference
> > implementation (Bitcoin Core). Policy is of course less risky than
> > consensus for various reasons including there being no chain split risk if
> > the user changes the default policy of their node. Alternative
> > implementations are free to set entirely different policy rules too. But
> > with L2 protocol security to some extent relying on policy whether we like
> > it or not I think we should aspire to similar standards where possible for
> > policy too.
> >
> > Specifications and implementations
> >
> > The Bitcoin Core review process generally requires Concept ACKs, Approach
> > ACKs and then code review, testing ACKs in that order. The reason for this
> > is even if the code is perfect if it is implementing a concept or an
> > approach that informed reviewers oppose then it doesn’t matter that the
> > code is perfect. Documentation is generally done post merge if at all. For
> > most PRs e.g. refactors this makes sense. There is no point documenting
> > something in advance if it is still under review or may not get merged. For
> > consensus PRs this clearly doesn’t make sense. Many of us have and continue
> > to cross check the Taproot BIPs with the Taproot reference implementation
> > in Bitcoin Core. Having two points of reference released simultaneously is
> > treating consensus changes with the highest possible standards we can. I
> > think we should strive towards the highest possible standards for step
> > change default policy changes in Core too given L2 protocol security is
> > (unfortunately, ideally this wouldn’t be the case) relying on them.
> >
> > What are the new RBF rules replacing the BIP125 rules?
> >
> > The new RBF rules as implemented in Core today are documented here 3 in
> > the Core repo (thanks for the link glozow). To the extent that these are a
> > work in progress or close to final (i.e. intended to be static) I don’t
> > know. The devs who work on policy will have a much better idea on these
> > questions than me. Will the new RBF rules continue to be iterated upon as
> > new research on L2 security comes to light? Will this iteration make it
> > impossible to maintain a static set of rules that the broader ecosystem can
> > get comfortable with? Or is a new static set of RBF rules close to being
> > finalized and there is just an aversion to using BIPs and a specification?
> >
> > Generally, as time passes, the ecosystem grows, layers on top of the base
> > layer get built out I get uncomfortable with what I perceive (correctly or
> > incorrectly) as a slip in standards. If anything it should be going in the
> > opposite direction. Standards should be improving and we should be striving
> > to do better and be more rigorous than whatever the standard was in 2015.
> > But I don’t work on policy in Core full time and it is very possible that
> > there are subtleties that I’m entirely missing here. I think this is the
> > right forum to ask about those subtleties though. Thanks to those who work
> > on this important area.
> >
> > l
> >
> > nts.md
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

2023-06-07 23:12:31

- reply

📅 Original date posted:2022-08-04
📝 Original message:A short history of RBF and BIP125
The history of BIP125 is as far as I’m aware this. RBF rules were merged into Bitcoin Core in November 2015 [0]. Following that merge David Harding and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had been implemented in Bitcoin Core. The rationales for the rules in the BIP was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!) when L2 protocols were in their infancy. Certainly the research on the security of L2 protocols has come a long way since and we have a much better idea of some of the possible attacks on L2 protocols that to some extent are impacted by policy rules.
In addition it was discovered [2] in May 2021 that the Bitcoin Core implementation of the RBF rules had never matched the RBF rules outlined in BIP125. Clearly this isn’t ideal but mistakes happen and will continue to happen. I certainly do not intend any criticism whatsoever to any of the individuals involved. Thankfully this discrepancy doesn’t seem to have resulted in any loss of funds or disruption. However, cross checking a specification with an implementation presumably led to the discovery and allowed for a post mortem on why the implementation didn’t match the specification.
There seems to be two views on what to do next given that the RBF rules need to be updated. One is to ditch the idea of a specification for RBF rules and just document them in the Core repo instead. The other is to have a new specification for the RBF rules in Core and attempt to correct the mistakes made with BIP125 by having a BIP that does correctly outline the RBF rules implemented in Core and includes detailed rationales for why those RBF rules have been implemented.
Should anyone care about where things are documented?
Perhaps not but I think if you are a stakeholder in L2 protocol security you should. Suppose in the long term future an attacker exploits a L2 vulnerability that is based on the default policy set by the dominant implementation on the network (Bitcoin Core). Which would you prefer the norm to be? A detailed static, well reviewed BIP standard that lays out the updated RBF rules and the rationales for those new rules that is reviewed outside the Core repo and hence not just by Core reviewers? Or cross checking Bitcoin Core code with non-standardized Core documentation typically reviewed only by Core reviewers?
For the same reason the norm for consensus changes is a specification (BIP) and a reference implementation (Bitcoin Core) I think the norm for material step change policy changes should be a specification (BIP) and a reference implementation (Bitcoin Core). Policy is of course less risky than consensus for various reasons including there being no chain split risk if the user changes the default policy of their node. Alternative implementations are free to set entirely different policy rules too. But with L2 protocol security to some extent relying on policy whether we like it or not I think we should aspire to similar standards where possible for policy too.
Specifications and implementations
The Bitcoin Core review process generally requires Concept ACKs, Approach ACKs and then code review, testing ACKs in that order. The reason for this is even if the code is perfect if it is implementing a concept or an approach that informed reviewers oppose then it doesn’t matter that the code is perfect. Documentation is generally done post merge if at all. For most PRs e.g. refactors this makes sense. There is no point documenting something in advance if it is still under review or may not get merged. For consensus PRs this clearly doesn’t make sense. Many of us have and continue to cross check the Taproot BIPs with the Taproot reference implementation in Bitcoin Core. Having two points of reference released simultaneously is treating consensus changes with the highest possible standards we can. I think we should strive towards the highest possible standards for step change default policy changes in Core too given L2 protocol security is (unfortunately, ideally this wouldn’t be the case) relying on them.
What are the new RBF rules replacing the BIP125 rules?
The new RBF rules as implemented in Core today are documented here [3] in the Core repo (thanks for the link glozow). To the extent that these are a work in progress or close to final (i.e. intended to be static) I don’t know. The devs who work on policy will have a much better idea on these questions than me. Will the new RBF rules continue to be iterated upon as new research on L2 security comes to light? Will this iteration make it impossible to maintain a static set of rules that the broader ecosystem can get comfortable with? Or is a new static set of RBF rules close to being finalized and there is just an aversion to using BIPs and a specification?
Generally, as time passes, the ecosystem grows, layers on top of the base layer get built out I get uncomfortable with what I perceive (correctly or incorrectly) as a slip in standards. If anything it should be going in the opposite direction. Standards should be improving and we should be striving to do better and be more rigorous than whatever the standard was in 2015. But I don’t work on policy in Core full time and it is very possible that there are subtleties that I’m entirely missing here. I think this is the right forum to ask about those subtleties though. Thanks to those who work on this important area.
[0]: https://github.com/bitcoin/bitcoin/pull/6871
[1]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
[3]: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220804/0036ee9e/attachment.html>

2023-06-07 23:12:08

- reply

📅 Original date posted:2022-07-23
📝 Original message:Hi
There is an online Socratic discussion [0] on MuSig2 next week (Thursday July 28th, 17:00 UTC) that Tim Ruffing has kindly agreed to attend. There is a reading list [1] covering Tim's work and other people's work implementing and researching MuSig2 and hopefully some of those people will attend too. It will be similar in format to the excellent Sydney Socratic with Jesse Posner on FROST in March [2].
For those who prefer IRC discussions rather than video discussions a biweekly secp256k1 IRC meeting (next one is Monday August 1st 2022 at 15:00 UTC) has recently started on the Libera IRC channel #secp256k1. (To be clear this isn't organized by me but I thought it might be of interest to a similar group of people.)
Thanks
Michael
[0]: https://www.meetup.com/bitdevsldn/events/286583988/
[1]: https://gist.github.com/michaelfolkson/5bfffa71a93426b57d518b09ebd0998c
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020352.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220723/6a1f6e51/attachment.html>

2023-06-07 23:12:02

- reply

📅 Original date posted:2022-07-23
📝 Original message:Hi Antoine
This looks great and I can certainly see progress being made in a number of directions on this. I thought you did a great job with the L2 onchain support workshops and I'm sure you'll do a great job moving this forward.
One cautionary word from someone who is probably still feeling the effects of burn out from the activation drama earlier in the year. No process can guarantee community consensus at the end of it especially if some of those who we consider experts in this area only tentatively participate. The personal attacks and ignoring of views counter to those who were pushing an activation attempt really should not be repeated. (Especially if this process is seeking to include those who we consider experts in this area and don't want their participation to be perceived as tacit approval of whatever is attempted next.)
As long as this is understood and agreed by participants I can only see positives coming out of this. But please let's not repeat the activation drama from earlier in the year because a process with a subset of those who we would consider experts in this area come to a view and then try to ram that view down everyone's throats by attempting activation at the end of it. Maybe this will result in community consensus on covenant proposal(s) going forward but also maybe it won't. Either outcome is fine. At the very least research will progress and work will be carried out that moves us in a positive direction.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, July 20th, 2022 at 21:42, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> Discussions on covenants have been prolific and intense on this mailing list and within the wider Bitcoin technical circles, I believe however without succeeding to reach consensus on any new set of contracting primitives satisfying the requirements of known covenant-enabled use-cases. I think that's a fact to deplore as covenants would not only offer vast extensions of the capabilities of Bitcoin as a system, i.e enabling new types of multi-party contract protocols. But also empowering Bitcoin on its fundamental value propositions of store of value (e.g by making vaults more flexible) and payment system (e.g by making realistic channel factories/payment pools).
>
> If we retain as a covenant definition, a spending constraint restricting the transaction to which the spent UTXO can be spent, and enabling to program contracts/protocols at the transaction-level instead of the script-level, the list of Script primitives proposed during the last years has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all the listed primitives are at different states of formalization, some already fully fleshed-out in BIPs, other still ideas on whiteboard, yet they all extend the range of workable multi-party contract protocols.
>
> Indeed this range has grown wild. Without aiming to be exhaustive (I'm certainly missing some interesting proposals lost in the abyss of bitcointalk.org), we can mention the following use-cases: multi-party stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" layered commitments [14], programmable vaults [15], multi-events contracts [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral lending [19], ...
>
> Minding all those facts, I would say the task of technical evaluation of any covenant proposal sounds at least two fold. There is first reasoning about the enabled protocols on a range of criterias such as scalability, efficiency, simplicity, extensibility, robustness, data confidentiality, etc. Asking questions like what are the interactions between layers, if any ? Or how robust is the protocol, not just interactivity failure between participant nodes but in the face of mempools spikes or internet disruption ? Or if the performance is still acceptable on shared resources like blockspace or routing tables if everyone is using this protocol ? Or if the protocol minimizes regulatory attack surface or centralization vectors ?
>
> Though once this step is achieved, there is still more reasoning work to evaluate how good a fit is a proposed Script primitive, the efficiency/simplicity/ease to use trade-offs, but also if there are no functionality overlap or hard constraints on the use-cases design themselves or evolvability w.rt future Script extensions or generalization of the opcode operations.
>
> Moreover, if you would like your evaluation of a covenant proposal to be complete, I don't believe you can squeeze the implications with the mempool rules and combination with any consistent fee-bumping strategy. To say things politely, those areas have been a quagmire of vulnerabilities, attacks and defects for second-layers Bitcoin protocols during the last years [20].
>
> Considering the abundant problem-space offered by covenants, I believe there is a reasonable groundwork to pursue in building the use-cases understanding (e.g prototype, pseudo-specification, documentation, ...) and building consensus on the framework of criterias on which to evaluate them [21]. It might raise a really high bar for any covenant proposal compared to previous softforks, however I think it would adequately reflect the growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open specification process, in the same spirit as we have with the BOLTs or dlcspecs. We would have regular meetings (biweekly/monthly ?), an open agenda where topics of discussion can be pinned in advance and documentation artifacts would be built with time driven by consensus (e.g 1st phase could be to collect, pseudo-specify and find champion(s) for known use-cases ?) and no timeframe. Starting date could be September / October / November (later, 2023 ?), giving time for anyone interested in such a covenant process to allocate development and contribution bandwidth in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2 onchain support meetings last year, I think it would be better to keep the agenda open, loose and free as much we can in a "burn-the-roadmap" spirit, avoiding to create a sense of commitment or perceived signaling in the process participants towards any covenant solution. I would guess things to be experimental and evolutionary and folks to spend the first meetings actually to express what they would like the covenant process to be about (and yes that means if you're a domain expert and you find the pace of things too slow sometimes, you have to learn to handle your own frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to have rotating meeting chairs and multiple covenant documentation archivists. I'm super happy to spend the time and energy bootstrapping well such covenant process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look like. We might end up concluding that complex covenants are too unsafe by enabling sophisticated MEV-attacks against LN [22]. Or even if there is an emergent technical consensus, it doesn't mean there is a real market interest for such covenant solutions. That said, I'm not sure if it's really a subject of concern when you're reasoning as a scientist/engineer and you value technical statements in terms of accuracy, systematic relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact that covenants are required building blocks to enable scalable payments pools design like CoinPool. I believe payments pools are a) cool and b) a good shot at scaling Bitcoin as a payment system once we have reached scalability limits of Lightning, still under the same security model for users. However, as a community we might sense it's not the good timing for a covenant process. I'm really fine with that outcome as there are still holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft forks, the hard part isn't about coming up with the best technical solution to a set of problems but in the iterative process where all voices are listened to reach (or not) consensus on what is actually meant by "best" and if the problems are accurate. The real physics of Bitcoin is the physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant specification process looks like. As usual, all opinions and mistakes are my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
> [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
> [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
> [9] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
> [12] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
> [13] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
> [14] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16] https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18] https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220723/7b57f683/attachment-0001.html>

2023-06-07 23:11:20

- reply

📅 Original date posted:2022-07-20
📝 Original message:So this half aggregation BIP draft could potentially play the role that BIP340 did for BIP341/342 but it is too premature to start formalizing what the equivalent of BIP341/342 for this draft BIP would look like. And given there are use cases for this half aggregation BIP that can be worked on today (e.g. Lightning gossip [0], Lightning gossip seems to be a very interesting research area at the moment with a number of possible upgrades) it makes sense to focus on those first.
There is a section[1] in the CISA repo which I missed originally that describes some of the challenges of implementing CISA/CISHA as a consensus change. A couple of things that stand out to me if this was attempted in the long term. One is that there would almost need to be two tiers of verification: verification for single signature key path spends where CISA, CISHA could be applied and verification for Taproot script paths where CISA, CISHA couldn't be applied. It could even be the case that a new output type is defined specifically for the CISA, CISHA use case where there is no access to a script path at all (i.e. where users don't have a need for anything other than a single signature spend path). With SegWit v0 (and today with SegWit v1) the intention is to get the entire community to move to the new output type. But there could be a long term future where you pick an output type depending on your use case. I recall that Mimblewimble only worked if scripting was ditched entirely and every spend was assumed to be a single signature spend.
Anyway...thanks for indulging me on the long term stuff :)
[0]: https://github.com/ElementsProject/cross-input-aggregation#sigagg-case-study-ln-channel-announcements
[1]: https://github.com/ElementsProject/cross-input-aggregation#integration-into-the-bitcoin-protocol
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, July 17th, 2022 at 21:45, Jonas Nick <jonasdnick at gmail.com> wrote:
> To be clear, whether "half aggregation needs a new output type or not" does not
> become clear in the draft BIP because it is out of scope. Half-aggregation has a
> few possible applications. The draft only specifies the cryptographic scheme.
>
> The StackExchange post you link to argues that CISA requires a new output type.
> The same argument applies to half aggregating signatures across transaction
> inputs (CISHA, if you will). The only difference to "full aggregation" is that
> the transaction signature is a single half-aggregate signature instead of a
> 64-byte signature. You're right that it's possible to do batch verification of
> Taproot output key spends (Schnorr signatures) and script spends (key tweaks).

2023-06-07 23:11:19

- reply

📅 Original date posted:2022-07-17
📝 Original message:Thanks for this Jonas. One question that was asked on Telegram (credit: Antoine D) and isn't clear to me skimming the blog post and the draft BIP is whether half aggregation needs a new output type or not like we expect cross input signature aggregation (CISA) to [0]. My understanding is Schnorr signature batch verification (no aggregation of signatures) can be done today but half aggregation and CISA would need a soft fork and potentially a new output type in addition.
(I know this work is in its early stages and won't be proposed for a soft fork anytime soon. A few of us are just trying to get a basic sketch in our heads of what they require and whether they could be enabled in the same upgrade.)
[0]: https://bitcoin.stackexchange.com/questions/106240/will-cross-input-signature-aggregation-need-a-new-output-type/
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Friday, July 8th, 2022 at 16:53, Jonas Nick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Half-aggregation has been mentioned several times on this list in various
> contexts. To have a solid basis for discussing applications of half-aggregation,
> I think it's helpful to have a concrete specification of the scheme and a place
> for collecting supplemental information like references to cryptographic
> security proofs. You can find the BIP draft at
>
> https://github.com/ElementsProject/cross-input-aggregation/blob/master/half-aggregation.mediawiki
>
> Similar to BIP-340, this BIP draft specifies only the cryptographic scheme and
> does not prescribe specific applications. It has not received an extensive
> security review yet. Thanks to Elliott Jin and Tim Ruffing for the review so
> far. One new feature that the specified scheme has is "incremental aggregation"
> which allows aggregating additional BIP-340 signatures into an existing
> half-aggregate signature.
>
> While BIP-340 has a pseudocode specification and a reference implementation in
> python, this BIP draft has a formal specification written in hacspec [0] and
> auxiliary pseudocode. The formal specification is a mathematically precise
> description of the scheme, which paves the way for computer-aided formal proofs.
> Software tools ("proof assistants") allow proving properties about the formal
> specification ("no integer overflow") and apply formal software verification
> ("implementation is behaviorally equivalent to the spec"). I don't have concrete
> plans (nor the skillset) to use these techniques. Still, I think this is an
> exciting area to explore because it has the potential to increase the Bitcoin
> ecosystem's robustness significantly and has little downside. Since hacspec's
> syntax is a subset of Rust's syntax, one can use the standard rust toolchain to
> compile, execute and test the specification.
>
> You can find a blog post that gives a broader context at
> https://blog.blockstream.com/half-aggregation-of-bip-340-signatures/
>
> [0] https://github.com/hacspec/hacspec
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:08:38

- reply

📅 Original date posted:2022-04-30
📝 Original message:I’ve been in two minds on whether to completely move on to other topics or to formulate some thoughts on the recent attempt to activate a contentious soft fork. In the interests of those of us who have wasted days/weeks/months of our time on this (with no personal upside) and who don’t want to repeat this exercise again I thought I should at least raise the issue for discussion of what should be done differently if this is tried again in future.
This could be Jeremy with OP_CTV at a later point (assuming it is still contentious) or anyone who wants to pick up a single opcode that is not yet activated on Bitcoin and try to get miners to signal for it bypassing technical concerns from many developers, bypassing Bitcoin Core and bypassing users.
Maybe the whole thing worked as designed. Some users identified what was going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy Song etc brought additional attention to the dangers, a URSF movement started to gain momentum and those attempting a contentious soft fork activation backed off. (Disappointingly Bitcoin Optech didn't cover my previous posts to this mailing list [1], [2], [3] highlighting the dangers many months ago or recent posts. Normally Optech is very high signal.)
Alternatively this was the first time a contentious soft fork activation was attempted, we were all woefully unprepared for it and none of us knew what we were doing.
I’m unsure on the above. I’d be interested to hear thoughts. What I am sure of is that it is totally unacceptable for one individual to bring the entire Bitcoin network to the brink of a chain split. There has to be a personal cost to that individual dissuading them from trying it again otherwise they’re motivated to try it again every week/month. Perhaps the personal cost that the community is now prepared if that individual tries it again is sufficient. I’m not sure. Obviously Bitcoin is a permissionless network, Bitcoin Core and other open source projects are easily forked and no authority (I’m certainly no authority) can stop things like this happening again.
I’ll follow the responses if people have thoughts (I won't be responding to the instigators of this contentious soft fork activation attempt) but other than that I’d like to move on to other things than contentious soft fork activations. Thanks to those who have expressed concerns publicly (too many to name, Bob McElrath was often wording arguments better than I could) and who were willing to engage with the URSF conversation. If an individual can go directly to miners to get soft forks activated bypassing technical concerns from many developers, bypassing Bitcoin Core and bypassing users Bitcoin is fundamentally broken. The reason I still have hope that it isn't is that during a period of general apathy some people were willing to stand up and actively resist it.
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220430/0b8a6f2f/attachment.html>

2023-06-07 23:08:38

- reply

📅 Original date posted:2022-04-30
📝 Original message:Hi
Another transcript that may be of interest to this list. Carl Dong recently did an excellent short video explaining the libbitcoinkernel project in Bitcoin Core. The transcript is here:
https://btctranscripts.com/chaincode-labs/2022-04-12-carl-dong-libbitcoinkernel/
As he explains in the video libbitcoinkernel is the latest attempt to extract the consensus engine out of Bitcoin Core. There are many motivations for doing this. Obviously disagreements between the consensus engines of nodes across the network can lead to catastrophic forks. This boundary between what is part of consensus and what is not has occasionally been blurred in the past and for the most security critical part of Bitcoin Core (and Bitcoin generally) this is clearly unacceptable. This is not a criticism of anyone in the past, unravelling Satoshi's spaghetti code and the entanglement between the consensus engine and the rest of the codebase has been a decade long task, requires extreme care and is by no means completed.
As well as leading to some consensus bugs in older versions of Bitcoin Core, the leaky consensus abstraction has made it difficult for alternative implementations to be built in other languages and with different RPCs etc without risking falling out of consensus with Bitcoin Core.
This is clearly an ambitious long term project but the first PR in the series was recently merged [1] and Carl explains his thinking on the future direction of this project in the video and on the linked issue.
[1]: https://github.com/bitcoin/bitcoin/issues/24303
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220430/c9029435/attachment.html>

2023-06-07 23:08:37

- reply

📅 Original date posted:2022-04-29
📝 Original message:Hi
Assessing what should be sent to this mailing list is difficult. We don't want to be bombarded with full on company promotional materials obviously but then at the same time only focusing on contentious consensus changes at the expense of everything else just gives a warped view to readers of this list of what is happening in the community and what 99 percent of Bitcoin devs are working on.
One example of many is Miniscript. In this excellent blog post [1] by Salvatore Ingala he explains the work he is doing to get Miniscript support in the Ledger hardware wallet (or "signing device" [2], hat tip nvk). Miniscript has been in the works for a number of years now and the first of multiple Miniscript related pull requests was recently merged into the Bitcoin Core wallet [3]. This wasn't included in the recent Bitcoin Core 23.0 release [4] but one would expect it to be included in the next major release (24.0).
Salvatore explains that to start enabling Miniscript support in Ledger only requires ~20 lines of code but there is additional complexity that isn't covered by the included code snippet. And of course the Policy to Miniscript compiler(s) don't (yet) support Taproot trees of scripts so we are talking primarily Bitcoin scripts pre-Taproot. He also includes a short video of what the Policy/Miniscript user experience might look like on a Ledger Nano.
For those who are interested in learning more about Miniscript stickies-v is hosting a Bitcoin Core PR review club on Miniscript on May 18th [5].
Disclaimer: I have personal views on hardware wallets/signing devices as anyone does but I do not receive funding from any particular company or product in the space.
[1]: https://blog.ledger.com/miniscript-is-coming/
[2]: https://signingdevice.com/
[3]: https://github.com/bitcoin/bitcoin/pull/24147
[4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020321.html
[5]: https://bitcoincore.reviews/24148
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220429/18ff2b2a/attachment.html>

2023-06-07 23:08:35

- reply

📅 Original date posted:2022-04-27
📝 Original message:Hi
I thought this transcript might be of interest to the mailing list.
https://btctranscripts.com/sydney-bitcoin-meetup/2022-03-29-socratic-seminar/
Jesse Posner joined the online Sydney Socratic [1] last month to discuss his work on FROST. There is a video [2] too. As Jesse states [3] "With the introduction of Taproot, we can begin to bridge this divide between a "hot" and "cold" key by leveraging distributed key generation and threshold signing."
During the Socratic he discussed how with FROST you can simulate a threshold signature arrangement (k-of-n, k<n or indeed n-of-n) with only one signature going onchain when making a transaction. There are lots of upsides, you can swap participants in and out without needing an onchain transaction and even change the arrangement from say a 3-of-5 to a 4-of-5 without needing an onchain transaction. There are challenges too of course and it was discussed how the various participants might swap nonces and keep track of which nonce they should be using when signing, how hardware wallets might support FROST and to what extent accountability can be achieved if malicious parties are included in the threshold arrangement.
Thanks to Lloyd Fournier for organizing it and thanks to Adam Jonas for maintaining the btctranscripts.com site. The Sydney Socratic is online, open to all and Lloyd has a number of ideas for future topics.
[1]: https://github.com/bitcoin-sydney/socratic
[2]: https://rumble.com/vz3i3u-frost-the-future-of-schnorr-multisignatures-on-bitcoin.html
[3]: https://brink.dev/blog/2021/04/15/frost/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220427/d69ceab9/attachment.html>

2023-06-07 23:08:11

- reply

📅 Original date posted:2022-04-26
📝 Original message:Jeremy
> The reason there was not a mailing list post is because that's not a committed plan, it was offered up for discussion to a public working group for feedback as a potential plan.
In the interests of posterity from your personal blog on April 17th [1]:
"Within a week from today, you’ll find software builds for a CTV Bitcoin Client for all platforms linked here:
- Mac OSX TODO:
- Windows TODO:
- Linux TODO:
These will be built using GUIX, which are reproducible for verification."
Doesn't sound to me that this was being "offered up for discussion". A week from April 17th would have been Sunday April 24th (2 days ago). Readers of this mailing list would have had no idea of these plans.
> You've inaccurately informed the list on something no one has communicated committed intent for.
I'll let readers assess from the above who is accurately informing the mailing list and who is using personal blog posts and messaging apps to give a completely different impression to one set of people versus readers of this mailing list.
I like to give people the benefit of the doubt and assume incompetence rather than malice but when it comes to potential chain splits it doesn't really matter which it is. It has the same effect and poses the same network risk. If and when you try something like this again I hope this is remembered.
The Binance hack rollback suggestion, the NACKing then coin flip suggestion on Taproot activation and now this. It seems like this trillion dollar industry is a joke to you. I know we aren't supposed to get personal on this mailing list but honestly if you are going to continue with these stunts I'd rather you do them on a different blockchain.
[1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Tuesday, April 26th, 2022 at 6:48 AM, Jeremy Rubin <jeremy.l.rubin at gmail.com> wrote:
> The reason there was not a mailing list post is because that's not a committed plan, it was offered up for discussion to a public working group for feedback as a potential plan. You've inaccurately informed the list on something no one has communicated committed intent for. This was an alternative discussed in the telegram messaging app but did not seem to strike the correct balance so was not furthered.
>
> I was hoping to be able to share something back to this list sooner rather than later, but I have not been able to get, among those interested to discuss in that venue, coherence on a best next step. I communicated inasmuch on the bird app https://twitter.com/JeremyRubin/status/1518347793903017984 https://twitter.com/JeremyRubin/status/1518477022439247872, but do not have a clear next step and am pouring over all the fantastic feedback I received so far.
>
> Further, you're representing the state of affairs as if there's a great need to scramble to generate software for this, whereas there already are scripts to support a URSF that work with the source code I pointed to from my blog. This approach is a decent one, even though it requires two things, because it is simple. I think it's important that people keep this in mind because that is not a joke, the intention was that the correct set of check and balance tools were made available. I'd be eager to learn what, specifically, you think the advantages are of a separate binary release rather than a binary + script that can handle both cases? I'm asking sincerely because I would make the modifications to the release I prepared to support that as well, if they do not entail substantial technical risk. Personally, were I aligned with your preferences, I'd be testing the forkd script and making sure it is easy to use as the simplest and most effective way to achieve your ends.
>
> regards,
>
> Jeremy
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)
>
> On Mon, Apr 25, 2022 at 3:44 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The latest I'm hearing (this mailing list appears to be being bypassed in favor of personal blogs and messaging apps) is that Speedy Trial miner signaling for the contentious CTV soft fork is no longer going to start on May 5th (as previously communicated [1]) and may instead now start around August 1st 2022.
>>
>> Hence for now the drama seems to have been averted. I am deeply skeptical that in the next 3 months this soft fork activation attempt will obtain community consensus and will no longer be contentious (although I guess theoretically it is possible). As a result I suspect we'll be in the exact same situation with a URSF effort required 2-3 months down the line.
>>
>> If we are I'll try to keep the mailing list informed. It is important there is transparency and ample time to research and prepare before making decisions on what software to run. Obviously I have no control over what others choose to do. Please don't be rushed into running things you don't understand the implications of and please only signal for a soft fork if you are convinced it has community consensus (what should precede signaling as it did for Taproot) and you are ready to activate a soft fork.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> As I said in my post:
>>>
>>> "If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support."
>>>
>>> Ideally everyone would come to an informed view independently. Unfortunately many people don't have the time to follow Bitcoin drama 24/7 and hence struggle to separate noise from signal. In this case simple heuristics are better than nothing. One heuristic is to listen to those in the past who showed good judgment and didn't seek to misinform. Of course it is an imperfect heuristic. Ideally the community would be given sufficient time to come to an informed view independently on what software to run and not be rushed into making decisions. But it appears they are not being afforded that luxury.
>>>
>>>> I fear you risk losing respect in the community
>>>
>>> I appreciate your concern.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>>> Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>
>>> ------- Original Message -------
>>> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <billy.tetrud at gmail.com> wrote:
>>>
>>>>> assuming people pay attention and listen to the individuals who were trusted during that period
>>>>
>>>> Bitcoin is not run by a group of authorities of olde. By asking people to trust "those.. around in 2015-2017" you're asking people to blindly trust authorities. This, in my strong opinion, goes against the bitcoin ethos, and is an incredibly harmful way to push for your agenda. I'd very much recommend you reassess the way you're going about what you're trying to do. I fear you risk losing respect in the community by implying without any evidence that certain people are "taking advantage" of some situation and attempting "to confuse".
>>>>
>>>> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> If the next few weeks go how I fear they will it could get messy. If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support. For those of you who were around in 2015-2017 you'll know what to expect. The right outcome endured in 2017 and I'm sure the right outcome will endure here assuming people pay attention and listen to the individuals who were trusted during that period. There are always a large number of motivated parties who are incentivized to break nodes off from Bitcoin and may seek to take advantage of a contentious soft fork activation attempt.
>>>>>
>>>>> Remember that if all the information is presented to users in a clear way well ahead of time then they can make their own mind up. I fear that things will be made as convoluted as possible in a way intended to confuse and information will be withheld until the last minute. When in doubt it is generally better to rely on the status quo and tried and trusted. In this case that would be Bitcoin Core. Alternative releases such as those seeking to attempt to activate CTV or indeed those seeking to resist the activation of CTV really should only be considered if you are informed on exactly what you are running.
>>>>>
>>>>> If you are interested in the effort to resist the contentious soft fork activation attempt of CTV please join ##ursf on Libera IRC.
>>>>>
>>>>> Have a good weekend. Hopefully those behind this contentious soft fork activation attempt will see sense and we can go back to more productive things than resisting contentious soft forks.
>>>>>
>>>>> --
>>>>> Michael Folkson
>>>>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>>>>> Keybase: michaelfolkson
>>>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/82531c39/attachment-0001.html>

2023-06-07 23:08:09

- reply

📅 Original date posted:2022-04-25
📝 Original message:The latest I'm hearing (this mailing list appears to be being bypassed in favor of personal blogs and messaging apps) is that Speedy Trial miner signaling for the contentious CTV soft fork is no longer going to start on May 5th (as previously communicated [1]) and may instead now start around August 1st 2022.
Hence for now the drama seems to have been averted. I am deeply skeptical that in the next 3 months this soft fork activation attempt will obtain community consensus and will no longer be contentious (although I guess theoretically it is possible). As a result I suspect we'll be in the exact same situation with a URSF effort required 2-3 months down the line.
If we are I'll try to keep the mailing list informed. It is important there is transparency and ample time to research and prepare before making decisions on what software to run. Obviously I have no control over what others choose to do. Please don't be rushed into running things you don't understand the implications of and please only signal for a soft fork if you are convinced it has community consensus (what should precede signaling as it did for Taproot) and you are ready to activate a soft fork.
[1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, April 23rd, 2022 at 11:03 AM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> As I said in my post:
>
> "If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support."
>
> Ideally everyone would come to an informed view independently. Unfortunately many people don't have the time to follow Bitcoin drama 24/7 and hence struggle to separate noise from signal. In this case simple heuristics are better than nothing. One heuristic is to listen to those in the past who showed good judgment and didn't seek to misinform. Of course it is an imperfect heuristic. Ideally the community would be given sufficient time to come to an informed view independently on what software to run and not be rushed into making decisions. But it appears they are not being afforded that luxury.
>
>> I fear you risk losing respect in the community
>
> I appreciate your concern.
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <billy.tetrud at gmail.com> wrote:
>
>>> assuming people pay attention and listen to the individuals who were trusted during that period
>>
>> Bitcoin is not run by a group of authorities of olde. By asking people to trust "those.. around in 2015-2017" you're asking people to blindly trust authorities. This, in my strong opinion, goes against the bitcoin ethos, and is an incredibly harmful way to push for your agenda. I'd very much recommend you reassess the way you're going about what you're trying to do. I fear you risk losing respect in the community by implying without any evidence that certain people are "taking advantage" of some situation and attempting "to confuse".
>>
>> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> If the next few weeks go how I fear they will it could get messy. If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support. For those of you who were around in 2015-2017 you'll know what to expect. The right outcome endured in 2017 and I'm sure the right outcome will endure here assuming people pay attention and listen to the individuals who were trusted during that period. There are always a large number of motivated parties who are incentivized to break nodes off from Bitcoin and may seek to take advantage of a contentious soft fork activation attempt.
>>>
>>> Remember that if all the information is presented to users in a clear way well ahead of time then they can make their own mind up. I fear that things will be made as convoluted as possible in a way intended to confuse and information will be withheld until the last minute. When in doubt it is generally better to rely on the status quo and tried and trusted. In this case that would be Bitcoin Core. Alternative releases such as those seeking to attempt to activate CTV or indeed those seeking to resist the activation of CTV really should only be considered if you are informed on exactly what you are running.
>>>
>>> If you are interested in the effort to resist the contentious soft fork activation attempt of CTV please join ##ursf on Libera IRC.
>>>
>>> Have a good weekend. Hopefully those behind this contentious soft fork activation attempt will see sense and we can go back to more productive things than resisting contentious soft forks.
>>>
>>> --
>>> Michael Folkson
>>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>>> Keybase: michaelfolkson
>>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/f414c306/attachment-0001.html>

2023-06-07 23:08:08

- reply

📅 Original date posted:2022-04-23
📝 Original message:As I said in my post:
"If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support."
Ideally everyone would come to an informed view independently. Unfortunately many people don't have the time to follow Bitcoin drama 24/7 and hence struggle to separate noise from signal. In this case simple heuristics are better than nothing. One heuristic is to listen to those in the past who showed good judgment and didn't seek to misinform. Of course it is an imperfect heuristic. Ideally the community would be given sufficient time to come to an informed view independently on what software to run and not be rushed into making decisions. But it appears they are not being afforded that luxury.
> I fear you risk losing respect in the community
I appreciate your concern.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, April 23rd, 2022 at 6:10 AM, Billy Tetrud <billy.tetrud at gmail.com> wrote:
>> assuming people pay attention and listen to the individuals who were trusted during that period
>
> Bitcoin is not run by a group of authorities of olde. By asking people to trust "those.. around in 2015-2017" you're asking people to blindly trust authorities. This, in my strong opinion, goes against the bitcoin ethos, and is an incredibly harmful way to push for your agenda. I'd very much recommend you reassess the way you're going about what you're trying to do. I fear you risk losing respect in the community by implying without any evidence that certain people are "taking advantage" of some situation and attempting "to confuse".
>
> On Fri, Apr 22, 2022 at 12:33 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> If the next few weeks go how I fear they will it could get messy. If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support. For those of you who were around in 2015-2017 you'll know what to expect. The right outcome endured in 2017 and I'm sure the right outcome will endure here assuming people pay attention and listen to the individuals who were trusted during that period. There are always a large number of motivated parties who are incentivized to break nodes off from Bitcoin and may seek to take advantage of a contentious soft fork activation attempt.
>>
>> Remember that if all the information is presented to users in a clear way well ahead of time then they can make their own mind up. I fear that things will be made as convoluted as possible in a way intended to confuse and information will be withheld until the last minute. When in doubt it is generally better to rely on the status quo and tried and trusted. In this case that would be Bitcoin Core. Alternative releases such as those seeking to attempt to activate CTV or indeed those seeking to resist the activation of CTV really should only be considered if you are informed on exactly what you are running.
>>
>> If you are interested in the effort to resist the contentious soft fork activation attempt of CTV please join ##ursf on Libera IRC.
>>
>> Have a good weekend. Hopefully those behind this contentious soft fork activation attempt will see sense and we can go back to more productive things than resisting contentious soft forks.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220423/f083def3/attachment-0001.html>

2023-06-07 23:08:07

- reply

📅 Original date posted:2022-04-22
📝 Original message:If the next few weeks go how I fear they will it could get messy. If you care about Bitcoin's consensus rules I'd request you pay attention so you can make an informed view on what to run and what to support. For those of you who were around in 2015-2017 you'll know what to expect. The right outcome endured in 2017 and I'm sure the right outcome will endure here assuming people pay attention and listen to the individuals who were trusted during that period. There are always a large number of motivated parties who are incentivized to break nodes off from Bitcoin and may seek to take advantage of a contentious soft fork activation attempt.
Remember that if all the information is presented to users in a clear way well ahead of time then they can make their own mind up. I fear that things will be made as convoluted as possible in a way intended to confuse and information will be withheld until the last minute. When in doubt it is generally better to rely on the status quo and tried and trusted. In this case that would be Bitcoin Core. Alternative releases such as those seeking to attempt to activate CTV or indeed those seeking to resist the activation of CTV really should only be considered if you are informed on exactly what you are running.
If you are interested in the effort to resist the contentious soft fork activation attempt of CTV please join ##ursf on Libera IRC.
Have a good weekend. Hopefully those behind this contentious soft fork activation attempt will see sense and we can go back to more productive things than resisting contentious soft forks.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/3da4d053/attachment.html>

2023-06-07 23:07:54

- reply

📅 Original date posted:2022-04-24
📝 Original message:Hi Jorge
> Can we agree now that resisting a bip8 proposal is simpler and cleaner than resisting a speedy trial proposal?
Personally I'd rather stick to one challenge at a time :) Currently we are facing a contentious soft fork activation attempt of CTV using an alternative client which we expect [1] to be a Speedy Trial deployment. Once this is resolved we can discuss the lessons and observations that come out of this.
> Is there any PR to actively resist the proposal on bitcoin core?
Not currently. Unless this becomes really, really messy and starts to pose a true existential threat to Bitcoin itself I think it best that attempts to actively resist the proposal are done outside of Bitcoin Core in an alternative client(s). Contrary to what some CTV proponents say getting anything consensus related into Bitcoin Core is extremely difficult (especially at short notice). There is no BDFL or Linus Torvalds like figure, there are a large number of contributors (and maintainers) who all have differing personal views. Hence directing people to have this discussion on a particular PR in the Bitcoin Core repo seems to me to be counterproductive and a massive distraction to other work that is going on on Bitcoin Core. We've already started to see online attacks on Bitcoin Core by CTV proponents [2] claiming an "old guard trying to assert dictatorship over the Bitcoin protocol". It is nonsense of course but directing that nonsense to the Bitcoin Core repo is surely not the right way to go.
As I've said in previous emails there is a Libera (and Freenode now) IRC channel ##ursf that has been set up to discuss an alternative client. We'll get a conversation log up too. And of course we wait for confirmation on what the Speedy Trial deployment parameters for this attempted CTV soft fork are going to be.
[1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/
[2]: https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Saturday, April 23rd, 2022 at 21:40, Jorge Timón <jtimon at jtimon.cc> wrote:
> I've been calling them "controversial softforks" for long.
> I hate to be right some times, but I guess I'm happy that I'm not the only one who distrusts jeremy rubin anymore.
>
> Can we agree now that resisting a bip8 proposal is simpler and cleaner than resisting a speedy trial proposal?
> I guess now we don't need to discuss it in hypothetical terms anymore, do we?
>
> Is there any PR to actively resist the proposal on bitcoin core?
>
> On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy thought that there would be a Speedy Trial signaling period for a CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>>
>> (I have to take what he says at face value. I can understand why one would be skeptical.)
>>
>> Understandably this has angered and surprised a few people including some of those who have voiced opposition to a CTV soft fork activation being attempted in the first place [2].
>>
>> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate (and older versions) does not include any CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some chance CTV was to activate through some other software release Bitcoin Core releases would not apply CTV rules but they also wouldn't reject blocks that apply CTV rules. Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
>>
>> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm open to better names. I certainly don't want to discourage those who dislike or oppose UASFs from contributing to this effort and potentially ultimately running a URSF release. If you don't want this rushed CTV soft fork to activate we are all on the same side whatever we call it.
>>
>> For now I've set up a ##ursf channel on Libera IRC to monitor developments and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
>>
>> The intention of this would be to provide additional direction and incentive to miners that the community does not want this soft fork to be activated. To repeat running a Bitcoin Core release will not signal for a CTV soft fork out the box. If a miner runs a Bitcoin Core release it will not signal for CTV.
>>
>> Apologies that this is rushed. But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>> [2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/18ffef7b/attachment-0001.html>

2023-06-07 23:07:53

- reply

📅 Original date posted:2022-04-22
📝 Original message:I'm going to keep this short as I'm sure you are not interested in discussion on supposedly "unhinged" takes. Plus I know you support this soft fork activation attempt, you have heard the arguments from various people against attempting it and if you don't believe by now that soft forks should have community consensus before they are attempted nothing will convince you.
> Resisting changes that don't affect you
The consensus rules are essentially what define Bitcoin. Bitcoin is nothing without well defined and rarely changing consensus rules. If they can be changed by a subset of the community against the wishes of another subset of the community then we may as well accept that all soft fork proposals will eventually get activated because all soft fork proposals will be able to get a subset of the community to support them. (There are a lot of proposals out there.) Decentralized decision making requires that we collectively set high bars when considering making changes to the most important and dangerous part of Bitcoin. Once consensus rules are changed they generally need a hard fork to revert. This is Bitcoin 101. I really shouldn't need to explain this to you. There was a lot of work done by a large number of people to slowly build community consensus around Taproot. You seem to be arguing that that work was pointless because ultimately Taproot doesn't affect the community. If you don't like it don't use it right? Just keep quiet? Nothing to do with you? Gosh....
> You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement.
Can you provide a link? If there was community consensus a single NACK from me would be pointless. I'm assuming that's the context in which it was said. I've been consistent on wanting community consensus before any soft fork is attempted. If there is community consensus it doesn't matter what I think. This is not a proposal that currently has community consensus and you are seeking to attempt to activate it anyway. Look at some of the individuals on this list. Only yesterday Matt Corallo, Adam Back, Murch, Bob McElrath etc were arguing online this should not be attempted. Perhaps you want to call their takes "unhinged" too?
https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
I'm happy to discuss anything with those who are on the fence or who are genuinely trying to come to a view on this. But I won't be responding again to people like Jeremy, Keagan etc who I know perfectly well understand these arguments, ignore them and proceed regardless.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Friday, April 22nd, 2022 at 12:36 AM, Keagan McClelland <keagan.mcclelland at gmail.com> wrote:
> Good day Michael,
>> and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
> This seems silly to me.
>
> The structure of CTV is imbuing an OP_NOP with script semantics. Resisting changes that don't affect you is not consistent with the ideals of people being able to structure their own private agreements as they see fit...aka freedom. It seems needlessly coercive to try and resist CTV in this way. CTV is ultimately an opt-in proposal. If you don't like the risk/benefit ratio, you can simply not generate scripts that contain CTV checks. Conservatism and apathy are something I can understand, but resisting CTV via an escalating soft fork is not conservatism or apathy, it's fundamental opposition. What is it that you hope to accomplish by blocking others from using a new opcode? According to your formal statement, you haven't really opposed CTV on fundamental grounds so much as vaguely questioning whether or not it is the "best tool for the job"...as if anyone really has the capacity to judge that for a diverse group with varying interests and use cases that may differ substantially from their own.
>
> There are really two ways to effectively resist this change: 1. reject all blocks during the lockin period, 2. reject all blocks that include OP_CTV in the script.
>
> Regardless of which method you choose, it is ultimately going to be a far more forceful/invasive consensus change than CTV was in the first place. So have fun trying to explain yourself out of that one. You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement. Did you change your mind or something?
>> Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
>
> Making the statement that "the community doesn't want this to activate" as if it's some kind of foregone conclusion is a pretty bold claim. I think you'll be surprised at how broad support actually is. To contrast your second citation, here's the set of people who have endorsed the proposal, along with a handful of people opposed (such as yourself): https://utxos.org/signals/. If you are aware of others who are opposed, it would be worth your time to solicit a statement from them that can be put on the signals page. Absent that, it seems appropriate to assume that the overwhelming majority of people who have opined on the subject are for it.
>> But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
>
> What an unhinged take. The level of effort put into gathering consensus for CTV has set the bar higher than Taproot. Taproot didn't have the level of outreach effort that CTV does, and the complexity in taproot is significantly larger than for CTV. You didn't seem to have a problem organizing that activation process. That proposal was opened for public discussion in Jan'20, merged in Oct'20, and you were organizing activation discussions as early as Jan'21. The design of CTV has been *final* since Feb'20, a month after Taproot was opened for public discussion. There's a ton of Proof-of-Concept code that has been written to test out use cases for CTV, but for Taproot it still doesn't look like we'll have MuSig for a while longer (I heard a year, but someone can correct me on that if I'm wrong), and wallet support for Taproot wasn't fleshed out until after activation. Characterizing Jeremy's efforts as throwing caution and conservatism out the window is hypocritical at best and malicious at worst.
>
> Finally, I think it is worth stating that if Bitcoin adopts a culture where a willfully ignorant set of people can block changes that have no impact on them, despite a large constituency wanting those changes, then Bitcoin kind of deserves the slow deterioration that will result from that. I don't really find that future appealing and so I think that trying to find ways to activate non-invasive changes should be everyone's goal, *even if* they personally may not have an immediate use case, or have a slight preference for alternate solutions. The exception to this is any introduction of systemic risk. Not all soft-forks are equal, and therefore the meta-consensus requirements for getting them activated should vary based on how broadly consequential the change is.
>
> Feel free to resist this if you want. In some sense that's what the Speedy Trial procedure is for. However, I think your case would be more compelling if you actually had some sort of affirmative argument for why CTV induces systemic risk to non-users of the opcode. Expressing uncertainty over whether it is the globally optimal solution (to a problem that cannot be globally defined due to diverse interests) is not persuasive to me and many others in the community.
> Keagan
>
> On Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy thought that there would be a Speedy Trial signaling period for a CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>>
>> (I have to take what he says at face value. I can understand why one would be skeptical.)
>>
>> Understandably this has angered and surprised a few people including some of those who have voiced opposition to a CTV soft fork activation being attempted in the first place [2].
>>
>> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate (and older versions) does not include any CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some chance CTV was to activate through some other software release Bitcoin Core releases would not apply CTV rules but they also wouldn't reject blocks that apply CTV rules. Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
>>
>> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm open to better names. I certainly don't want to discourage those who dislike or oppose UASFs from contributing to this effort and potentially ultimately running a URSF release. If you don't want this rushed CTV soft fork to activate we are all on the same side whatever we call it.
>>
>> For now I've set up a ##ursf channel on Libera IRC to monitor developments and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
>>
>> The intention of this would be to provide additional direction and incentive to miners that the community does not want this soft fork to be activated. To repeat running a Bitcoin Core release will not signal for a CTV soft fork out the box. If a miner runs a Bitcoin Core release it will not signal for CTV.
>>
>> Apologies that this is rushed. But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>> [2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/f136410f/attachment-0001.html>

2023-06-07 23:07:49

- reply

📅 Original date posted:2022-04-21
📝 Original message:Ok so we've had to scramble a bit as I don't think anyone except perhaps Jeremy thought that there would be a Speedy Trial signaling period for a CTV soft fork planned to start on May 5th [1]. That is two weeks away.
(I have to take what he says at face value. I can understand why one would be skeptical.)
Understandably this has angered and surprised a few people including some of those who have voiced opposition to a CTV soft fork activation being attempted in the first place [2].
As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate (and older versions) does not include any CTV code or CTV activation code. If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If by some chance CTV was to activate through some other software release Bitcoin Core releases would not apply CTV rules but they also wouldn't reject blocks that apply CTV rules. Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.)
I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but I'm open to better names. I certainly don't want to discourage those who dislike or oppose UASFs from contributing to this effort and potentially ultimately running a URSF release. If you don't want this rushed CTV soft fork to activate we are all on the same side whatever we call it.
For now I've set up a ##ursf channel on Libera IRC to monitor developments and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV.
The intention of this would be to provide additional direction and incentive to miners that the community does not want this soft fork to be activated. To repeat running a Bitcoin Core release will not signal for a CTV soft fork out the box. If a miner runs a Bitcoin Core release it will not signal for CTV.
Apologies that this is rushed. But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted.
[1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
[2]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/f082253d/attachment.html>

2023-06-07 23:07:19

- reply

📅 Original date posted:2022-04-20
📝 Original message:Ok last one. Whatever you say and whatever personal attacks you come up with I'm not responding after this one :)
> Where can I see the use cases you have built out in recent years? Do you have a writeup in which you compare CTV to existing covenant enabling proposals? Do you have a strong reason to favour a different proposal? Have you written any code?
You don't seem to quite understand the asymmetry here. I (and the rest of the community excluding Jeremy) am not a full time CTV developer or full time CTV advocate. There are a number of soft fork proposals I am interested in and attempting to follow in addition to all the work that is going around Taproot etc. But if you/Jeremy want to make a change to the consensus rules the onus is on you to get community review and community consensus. I am not demanding the consensus rules be changed. I am quite happy to wait until there is community consensus over a particular soft fork like there was with Taproot.
I have looked into CTV a considerable number of times now. I have asked 5 of the 6 CTV related questions on Bitcoin StackExchange at the time of writing [1], 2 of which I have attempted to answer. Does this mean I understand as much about Jeremy about CTV? Of course not. But if you believe that soft forks should have community consensus it is up to you/Jeremy to address concerns from curious, relatively informed, skeptical people like me. I am not convinced at the time of writing that CTV is the best tool for the job on any of its intended use cases. On this I don't think even Jeremy is convinced as when asked to compare CTV to alternatives he often just says it is ready and other proposals aren't.
> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.
I'm not entirely sure where you are going with this. That because Jeremy has worked really hard on it for a long time we should activate it without community consensus? I'm sorry that's not how consensus changes work or how they should work. Personally I very much doubt I will ever attempt to change the consensus rules with one of my proposals. I struggle to follow all of the work and the proposals others work on and at least for now believe others are much more qualified than me to design and code up consensus code changes. So again there is an asymmetry if you are going down the comparing Jeremy's goals with my own.
> I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119.
I think CTV is an immature proposal given what I've said already about it not being at all clear it is the best tool for any of its intended use cases.
> If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?
Others are currently working on alternative proposals to CTV (CAT, CSFS, TLUV, Simplicity, arguably APO depending on the use case etc). I haven't asked them to, they already are. As far as I know (they can correct me if wrong) those working on alternative proposals don't support an upcoming activation of CTV. You can try to make this personal all you want and write snide comments if it makes you feel better. But I doubt it is the right approach to getting more review of a soft fork proposal.
> Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.
If you have a magic wand to wave away activation drama and create an activation method that the entire community is happy with I'd love to see it. That magic wand would have got a few months of my life back in 2021 that I'll never get back.
As I said no more responses from me. I am going to go back to a transcript on FROST, one of the many exciting things people are working on that is Taproot related and what I believe the focus should be on at least until there is clear community consensus for a future soft fork.
[1]: https://bitcoin.stackexchange.com/questions/tagged/bip119-checktemplateverify
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 20th, 2022 at 20:46, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Michael,
>
> Thank you for your reply. You wrote:
>
>> I have a better (and safer) way forward which is to continue to build out use cases of CTV, convince the community it is the best tool for the job (whatever use case(s) that is), compare it to other existing covenant enabling proposals on those use cases and then get to a point where the community is confident that it is activating a proposal(s) that will stand the test of time.
>
> Where can I see the use cases you have built out in recent years? Do you have a writeup in which you compare CTV to existing covenant enabling proposals? Do you have a strong reason to favour a different proposal? Have you written any code?
>
> I've seen pages of text of you complaining about details of CTV activation but nothing tangible that would prove that you are actually interested in real progress on covenants.
> In contrast, Jeremy has been doing exactly what you are proposing. He wrote the BIP, implemented it, explained use cases in detail, spoke at conferences, organised workshops, and built the Sapio framework for the community to experiment with covenants. He even puts his money where his mouth is and offers a bug bounty for any security flaw in the code.
>
>> You may not like that way forward because it requires a lot of work, a lot of time and a lot of patience.
>
> A lot of work, a lot of time and a lot of patience is exactly what Jeremy has been investing for years. I think by framing his contributions as "immature" you are disrespecting all the work he put into BIP-119. If you could point me to essays of you thoughtfully comparing various covenant proposals then I could see your point, but you're only ranting on other people's work which requires no real effort and it doesn't contribute much. If you are not willing to do what you are suggesting for years why should anybody else do it? Should the entire community stall progress on covenants until somebody else works on what you think is ideal?
> Bike shedding is just as big of an issue as "contentious soft forks". Pointless activation drama is a huge issue of bitcoin protocol development because it is so draining. Some of the most respected devs do not participate in activation politics anymore because it harms their health. That's nuts. If you really want to be of service to the Bitcoin community you should work on what you think is the right path forward and not just criticise Jeremy for progressing with his excellent work.
>
> Looking forward to check out your contributions!
>
> Regards,
> Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/697e178e/attachment-0001.html>

2023-06-07 23:07:18

- reply

📅 Original date posted:2022-04-20
📝 Original message:Hi Robin
I was in two minds to respond because I feel I am just repeating myself from previous emails to this list [1], [2], [3]. I'm not sure whether you have read those posts or are just blocking them out because you disagree with them. I also don't think much (anything?) has changed since I wrote those emails a few months ago.
> Honestly, the reasons you mentioned here [1] do not make much sense to me and it feels like your attitude is not very constructive as you do not suggest a better way forward.
I have a better (and safer) way forward which is to continue to build out use cases of CTV, convince the community it is the best tool for the job (whatever use case(s) that is), compare it to other existing covenant enabling proposals on those use cases and then get to a point where the community is confident that it is activating a proposal(s) that will stand the test of time.
You may not like that way forward because it requires a lot of work, a lot of time and a lot of patience. It is certainly easier to agitate for a soft fork on a mailing list. But that would be "my" and other people's way forward who think only the best proposals should get into Bitcoin consensus rules and those worthy of taking on the chain split risk.
> It's not clear to me what you want because you just keep opposing CTV without trying to make better suggestions. What do you want?
There are a number of competing covenant enabling proposals out there. I don't know if they are better or not for specific use cases. I also don't think there is consensus on that yet. Mainnet should not be treated like testnet, signet or an altcoin. It isn't for experimenting with new consensus rules or proving that something is useful. That should be done elsewhere.
> Your other arguments mostly discuss soft forks in general. This is a different topic though. I think it is not a good idea to mix that up.
Any soft fork introduces chain split risk into the equation. Taproot had overwhelming community consensus so it had much less chain split risk. A contentious soft fork activation attempt contains a lot more chain split risk. When discussing whether to attempt to activate soft forks you have to appreciate that important fact. To ignore that seems bizarre to me.
But as I said I'm repeating myself. If we have to do this contentious soft fork activation attempt exercise we have to do it and get it over with. The kind of work and progress I was hoping to see on CTV use cases over many months (and/or years) doesn't seem to be happening. Instead we just have a flame war every couple of months on the mailing list over whether CTV should be activated or not and rehash all the same arguments in an environment in which nothing (anything?) has moved forward.
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
[3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019731.html
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, April 20th, 2022 at 18:13, Robin Linus via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dear Michael,
>
> Firstly, I think it is great that you do share enthusiasm for "vaults, eltoo constructions, payment pools etc". Many people see covenants (or covenant-like features) as one of the most important upgrades currently in the pipe line because it enables so many important use cases and interesting areas of research. In particular vaults and scalability solutions.
>
> However, I have tried to figure out why you invest so much time and effort to oppose CTV. Honestly, the reasons you mentioned here [1] do not make much sense to me and it feels like your attitude is not very constructive as you do not suggest a better way forward.
> You wrote "This research and experimentation should mature before considering activation" even though you know that BIP-119 has been finalised more than two years ago. Also the implementation has been reviewed extensively and it has matured for years. So, your framing of "experimentation" and "premature activation" just doesn't reflect the truth here. Even your argument is already more than a year old...
>
> Additionally, you do not address that CTV is intentionally designed to be the most simple and conservative upgrade towards full-featured covenants. CTV only enables a feature that is already possible today using a trusted party. Opposing this conservative approach means you are either in favour of activating a more powerful feature or you do not want covenants at all. It's not clear to me what you want because you just keep opposing CTV without trying to make better suggestions. What do you want?
> Your other arguments mostly discuss soft forks in general. This is a different topic though. I think it is not a good idea to mix that up. And claiming that CTV implies continuous soft forks is again dishonest framing. It suggests that covenants were just a random idea of Jeremy even though you know that many reputable bitcoin developers have been researching this topic for years. Truth is Jeremy does a great service to the community by facing this draining activation drama to make trustless covenants possible.
>
> Now, in your most recent email your main concern seems to be a potential chain split. This is again a weak argument against CTV because your concerns apply to any upgrade. Furthermore, you are increasing this risk by opposing CTV without trying to find a common way forward to activate covenants. This doesn't serve bitcoin. I think it would be better for everyone if you would invest your time in trying to formulate a better solution. Covenants are too important to just oppose them because of inaccurate framing or because of opposition to soft forks in general.
>
> Regards,
> Robin
>
> [1] https://github.com/JeremyRubin/utxos.org/issues/27
>
> ------- Original Message -------
> On Wednesday, April 20th, 2022 at 3:24 PM, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>> The client has a Speedy trial release similar to Taproots with parameters proposed to be....
>>
>> As I've said before I was hoping we'd avoid this exercise. Best case, it wastes the time of people who could be working on all sorts of valuable projects for the ecosystem. Worst case, we take a Russian roulette style gamble with a chain split.
>>
>> But here's a summary of the basic facts:
>>
>> The latest Bitcoin Core release candidate (23.0) does not contain any new soft fork code, either CTV code or any new activation code. Running Bitcoin Core 23.0 out the box will not signal for any new soft fork and will not enforce any new soft fork rules (CTV or otherwise). Of course it will continue to enforce Taproot rules as Taproot activated last year.
>>
>> There are a number of individuals who have stated opposition to attempting to activate a CTV soft fork in the near term:
>>
>> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>
>> Most of those individuals haven't logged their opposition on Jeremy's site:
>> https://utxos.org/signals/
>>
>> Hence their views haven't been included or discussed in Jeremy's latest blog post.
>>
>> Chain split risk
>>
>> I can't predict how many full nodes and miners will run Jeremy's client attempting to activate CTV. One would expect that many will continue to run versions of Bitcoin Core that will not enforce CTV rules and will not activate it. But whether Jeremy's client will be a majority, significant minority, insignificant minority of full nodes and miners would be speculation on my part. (Personally I highly doubt those running Jeremy's client will be a majority which leaves a significant minority and insignificant minority as the most likely options).
>>
>> Jeremy's client is intending to use Speedy Trial presumably with similar parameters to that used for Taproot. That would mean seeking 90 percent of miners to signal for this CTV soft fork activation attempt.
>>
>> Assuming 90 percent of miners don't signal for it in one of the Speedy Trial windows then the activation attempt will have failed and it will be back in Jeremy's court whether he tries again with a different activation attempt.
>>
>> Assuming 90 percent of miners do signal for it (unlikely in my opinion but presumably still a possibility) then the CTV soft fork could activate unless full nodes resist it. This resistance would most likely be in the form of a UASF style client which rejects blocks that apply the CTV rules and/or includes transactions that don't meet the CTV rules post activation. We would now be in chain split territory with two different assets and blockchains like we had with BTC and BCH.
>>
>> If I oppose this activation attempt and the associated chain split risk what should I do?
>>
>> Firstly, you can register your opposition to this soft fork activation attempt on Jeremy's site: https://utxos.org/signals/
>>
>> It seems Jeremy will continue this activation attempt regardless but it will be useful for others to see clearly that this a contentious soft fork activation attempt and act accordingly. So far only 3 individuals' opposition is registered on his site.
>>
>> Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) of miners are going to signal for a CTV soft fork then you can consider joining a UASF style effort to resist the soft fork activation attempt. I will certainly seek to participate and will continue to inform this list of efforts in this direction.
>>
>> The saddest thing is that if Jeremy's soft fork activation attempt causes the uncertainty, confusion and disruption I fear it could it will make future soft forks that do have community consensus orders of magnitude harder to pull off. There are a number of soft fork proposals that I'm personally excited about (enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get with a sensible approach to only activating soft forks that have community consensus. But the more uncertainty, confusion and disruption we create over contentious soft forks the more dangerous any soft fork of any form will appear. The primary focus will need to be resisting soft forks that don't have community consensus and ensuring Bitcoin doesn't splinter into a large number of different assets/blockchains with different combinations of soft forks active.
>>
>> So if you oppose this soft fork activation attempt please voice your opposition, run full node software that doesn't include CTV and CTV activation code such as Bitcoin Core and if/when necessary and available run full node software that proactively rejects application of the CTV rules.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Devs,
>>>
>>> In advance of the CTV meeting today, I wanted to share what my next step is in advocating for CTV, as well as 7 theses for why I believe it to be the right course of action to take at this time.
>>>
>>> Please see the post at https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>>>
>>> As always, open to hear any and all feedback,
>>>
>>> Jeremy
>>>
>>> archived at: https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/87aa6c18/attachment-0001.html>

2023-06-07 23:07:17

- reply

📅 Original date posted:2022-04-20
📝 Original message:> The client has a Speedy trial release similar to Taproots with parameters proposed to be....
As I've said before I was hoping we'd avoid this exercise. Best case, it wastes the time of people who could be working on all sorts of valuable projects for the ecosystem. Worst case, we take a Russian roulette style gamble with a chain split.
But here's a summary of the basic facts:
The latest Bitcoin Core release candidate (23.0) does not contain any new soft fork code, either CTV code or any new activation code. Running Bitcoin Core 23.0 out the box will not signal for any new soft fork and will not enforce any new soft fork rules (CTV or otherwise). Of course it will continue to enforce Taproot rules as Taproot activated last year.
There are a number of individuals who have stated opposition to attempting to activate a CTV soft fork in the near term:
https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
Most of those individuals haven't logged their opposition on Jeremy's site:
https://utxos.org/signals/
Hence their views haven't been included or discussed in Jeremy's latest blog post.
Chain split risk
I can't predict how many full nodes and miners will run Jeremy's client attempting to activate CTV. One would expect that many will continue to run versions of Bitcoin Core that will not enforce CTV rules and will not activate it. But whether Jeremy's client will be a majority, significant minority, insignificant minority of full nodes and miners would be speculation on my part. (Personally I highly doubt those running Jeremy's client will be a majority which leaves a significant minority and insignificant minority as the most likely options).
Jeremy's client is intending to use Speedy Trial presumably with similar parameters to that used for Taproot. That would mean seeking 90 percent of miners to signal for this CTV soft fork activation attempt.
Assuming 90 percent of miners don't signal for it in one of the Speedy Trial windows then the activation attempt will have failed and it will be back in Jeremy's court whether he tries again with a different activation attempt.
Assuming 90 percent of miners do signal for it (unlikely in my opinion but presumably still a possibility) then the CTV soft fork could activate unless full nodes resist it. This resistance would most likely be in the form of a UASF style client which rejects blocks that apply the CTV rules and/or includes transactions that don't meet the CTV rules post activation. We would now be in chain split territory with two different assets and blockchains like we had with BTC and BCH.
If I oppose this activation attempt and the associated chain split risk what should I do?
Firstly, you can register your opposition to this soft fork activation attempt on Jeremy's site: https://utxos.org/signals/
It seems Jeremy will continue this activation attempt regardless but it will be useful for others to see clearly that this a contentious soft fork activation attempt and act accordingly. So far only 3 individuals' opposition is registered on his site.
Secondly, if it is looking like 90 percent (or whatever percentage Jeremy uses) of miners are going to signal for a CTV soft fork then you can consider joining a UASF style effort to resist the soft fork activation attempt. I will certainly seek to participate and will continue to inform this list of efforts in this direction.
The saddest thing is that if Jeremy's soft fork activation attempt causes the uncertainty, confusion and disruption I fear it could it will make future soft forks that do have community consensus orders of magnitude harder to pull off. There are a number of soft fork proposals that I'm personally excited about (enabling covenants, eltoo, Simplicity, CISA etc) that long term we might get with a sensible approach to only activating soft forks that have community consensus. But the more uncertainty, confusion and disruption we create over contentious soft forks the more dangerous any soft fork of any form will appear. The primary focus will need to be resisting soft forks that don't have community consensus and ensuring Bitcoin doesn't splinter into a large number of different assets/blockchains with different combinations of soft forks active.
So if you oppose this soft fork activation attempt please voice your opposition, run full node software that doesn't include CTV and CTV activation code such as Bitcoin Core and if/when necessary and available run full node software that proactively rejects application of the CTV rules.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Tuesday, April 19th, 2022 at 18:31, Jeremy Rubin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Devs,
>
> In advance of the CTV meeting today, I wanted to share what my next step is in advocating for CTV, as well as 7 theses for why I believe it to be the right course of action to take at this time.
>
> Please see the post at https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/.
>
> As always, open to hear any and all feedback,
>
> Jeremy
>
> archived at: https://web.archive.org/web/20220419172825/https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220420/e4f13a10/attachment.html>

2023-06-07 23:05:49

- reply

📅 Original date posted:2022-03-09
📝 Original message:Hi Jorge
> Since this has meetings like taproot, it seems it's going to end up being added in bitcoin core no matter what.
Anyone can set up a IRC channel, anyone can organize a IRC meeting, anyone can announce meetings on the mailing list. Just because an individual is enthusiastic for a soft fork proposal does not imply it has community consensus or that it is likely to be merged into Core in the short term or long term. It is true that other soft fork proposal authors/contributors are not taking the approach Jeremy is taking and are instead working quietly in the background. I prefer the latter approach so soon after Taproot activation but I look forward to hearing about the progress made on other proposals in due course.
> Should we start the conversation on how to resist it when that happens?
We should talk more about activation mechanisms and how users should be able to actively resist them more.
I can only speak for myself but if activation was being pursued for a soft fork that didn't have community consensus I would seek to join you in an effort to resist that activation. Taproot (pre-activation discussion) set a strong precedent in terms of community outreach and patiently building community consensus over many years. If that precedent was thrown out I think we are in danger of creating the chaos that most of us would seek to avoid. You are free to start whatever conversation you want but personally until Jeremy or whoever else embarks on an activation attempt I'd rather forget about activation discussions for a while.
> What is ST? If it may be a reason to oppose CTV, why not talk about it more explicitly so that others can understand the criticisms?
ST is short for Speedy Trial, the activation mechanism used for Taproot. I have implored people on many occasions now to not mix discussion of a soft fork proposal with discussion of an activation mechanism. Those discussions can happen in parallel but they are entirely independent topics of discussion. Mixing them is misleading at best and manipulative at worst.
> It seems that criticism isn't really that welcomed and is just explained away.
Perhaps it is just my subjective perception. Sometimes it feels we're going from "don't trust, verify" to "just trust jeremy rubin", i hope this is really just my subjective perception. Because I think it would be really bad that we started to blindly trust people like that, and specially jeremy.
I think we should generally avoid getting personal on this mailing list. However, although I agree that Jeremy has done some things in the past that have been over-exuberant to put it mildly, as long as he listens to community feedback and doesn't try to force through a contentious soft fork earlier than the community is comfortable with I think his work can add material value to the future soft fork discussion. I entirely agree that we can't get into a situation where any one individual can push through a soft fork without getting community consensus and deep technical review from as many qualified people as possible. That can take a long time (the demands on long term contributors' time are vast) and hence anyone without serious levels of patience should probably exclusively work on sidechains, altcoins etc (or non-consensus changes in Bitcoin) rather than Bitcoin consensus changes.
Thanks
Michael
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Timón via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Since this has meetings like taproot, it seems it's going to end up being added in bitcoin core no matter what.
>
> Should we start the conversation on how to resist it when that happens?
> We should talk more about activation mechanisms and how users should be able to actively resist them more.
>
> On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> * Tuesday, March 8th.
>>
>> I think Noon PT == 8pm UTC?
>>
>> but dont trust me i cant even tell what day is what.
>> --
>> [@JeremyRubin](https://twitter.com/JeremyRubin)
>>
>> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin <jeremy.l.rubin at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> There will be a CTV meeting tomorrow at noon PT. Agenda below:
>>>
>>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes)
>>> - Experimental support for Taproot merged on master https://github.com/sapio-lang/sapio
>>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes)
>>> - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html
>>> - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
>>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes)
>>> - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html
>>> 4) What the heck is everyone talking about on the mailing list all of the sudden (30 minutes)
>>> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc
>>> 5) Q&A (30 mins)
>>>
>>> Best,
>>>
>>> Jeremy
>>>
>>> --
>>> [@JeremyRubin](https://twitter.com/JeremyRubin)
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220309/750d12a9/attachment-0001.html>

2023-06-07 23:04:25

- reply

📅 Original date posted:2022-02-14
📝 Original message:> This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.
Right, not immediately. If and when new policy rules are included in a Bitcoin Core release it would take a while before a significant majority of the network were running those new policy rules (barring some kind of urgency, an attacker exploiting a systemic security flaw etc). That's not an argument not to do it though if you take a longer term perspective on building the strongest possible foundation for Lightning or other Layer 2 projects. The security benefit would just be delayed until a significant majority of Bitcoin Core users upgraded to a version including those new policy rules.
> Bitcoin Core with different versions are used at any point and not sure if this will ever change.
Sure there will always be some stray full nodes running extremely old versions but the general direction of travel is more and more full nodes upgrading to newer versions. A network where *all* full nodes are running the same policy rules is clearly not an option available to us without making policy rules effective consensus rules and forking/kicking those old versions off the network.
> Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.
Definitely agree. It is a really interesting research area and lots of opportunities for simulations and experiments on the default or custom signet networks. Especially if we fill blocks with auto-generated transactions and/or reduce block sizes and create an artificial fee market.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, February 14th, 2022 at 5:18 AM, Prayank <prayank at tutanota.de> wrote:
>> I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical).
>
> 30% nodes are using 0.21.1 right now whereas latest version was 22.0 and some are even running lower versions. Different versions in future with defaults might be running RBF v1 and RBF v2.
>
>> But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.
>
> Agree and attackers will want to run the nodes with policy that helps them exploit bitcoin projects. Miners can run nodes with policy that helps them get more fees.
>
>> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used.
>
> Bitcoin Core with different versions are used at any point and not sure if this will ever change.
>
> https://luke.dashjr.org/programs/bitcoin/files/charts/security.html
>
> https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22&facet=product
>
>> I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>
> This is the assumption which I don't agree with and hence asked some questions in my email. A new RBF policy used by default in Core will not improve the security of projects that are vulnerable to multiple RBF policies or rely on these policies in a way that affects their security.
>
> Maybe some experiments on signet might help in knowing more issues associated with multiple RBF policies.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
> Feb 13, 2022, 21:16 by michaelfolkson at protonmail.com:
>
>> Hi Prayank
>>
>>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>
>> Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
>>
>>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>
>> Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning.
>>
>> As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
>>
>>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>
>> I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
>>
>>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>
>> The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hello World,
>>>
>>> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>>>
>>> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>>>
>>> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>>>
>>> Based on the things shared by 'aj' in
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>>>
>>> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>>>
>>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>>>
>>> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>>>
>>> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>>>
>>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220214/c2938382/attachment-0001.html>

2023-06-07 23:04:23

- reply

📅 Original date posted:2022-02-13
📝 Original message:Hi Prayank
> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
Clearly the security of the Lightning Network and some other Layer 2 projects are at least impacted or partly dependent on policy rules in a way that the base blockchain/network isn't. As I (and others) have said on many occasions ideally this wouldn't be the case but it is best we can do with current designs. I (and others) take the view that this is not a reason to abandon those designs in the absence of an alternative that offers a strictly superior security model. Going back to a model where *all* activity is onchain (or even in less trust minimized protocols than Lightning) doesn't seem like the right approach to me.
> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
Without making policy rules effective consensus rules users (including miners) are free to run different policy rules. I think it is too early to say what the final incentives will be to run the same or differing policies. Research into Lightning security is still nascent and we have no idea whether alternative Layer 2 projects will thrive and whether they will have the same or conflicting security considerations to Lightning. I suspect as with defaults generally most users will run whatever the defaults are as they won't care to change them (or even be capable of changing them if they are very non-technical). But users who have a stake in the security of Lightning (or other Layer 2 projects) will clearly want to run whatever policy rules are beneficial to those protocols.
As you know the vast majority of the full nodes on the network currently run Bitcoin Core. Whether that will change in future and whether this a good thing or not is a whole other discussion. But the reality is that with such strong dominance there is the option to set defaults that are widely used. I think if certain defaults can bolster the security of Lightning (and possibly other Layer 2 projects) at no cost to full node users with no interest in those protocols we should discuss what those defaults should be.
> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
I think by nature of the Lightning Network being the most widely adopted Layer 2 project most of the focus has been on Lightning security. But contributors to other Layer 2 projects are free to flag and discuss security considerations that aren't Lightning specific.
> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
The maintainer(s) and contributors to Bitcoin Knots are free to determine what default policy rules they want to implement (and make it easier for users to change those defaults) in the absence of those policy rules being made effective consensus rules. I suspect there would be strong opposition to making some policy rules effective consensus rules but we are now venturing again into future speculation and none of us have a crystal ball. Certainly if you take the view that these policy rules should never be made effective consensus rules then the fact there is at least one implementation taking a contrasting approach to Core is a good thing.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Hello World,
>
> There was a discussion about improving fee estimation in Bitcoin Core last year in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook in which which everyone is bidding for block space because nodes can use different relay policies: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>
> Although I still don't consider fee rates used in last few blocks relevant for fee estimation, it is possible that we have nodes with different relay policies.
>
> Similarly if we have different RBF policies being used by nodes in future, how would this affect the security of lightning network implementations and other layer 2 projects?
>
> Based on the things shared by 'aj' in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html it is possible for an attacker to use a different RBF policy with some nodes, 10% hash power and affect the security of different projects that rely on default RBF policy in latest Bitcoin Core.
>
> There was even a CVE in which RBF policy not being documented according to the implementation could affect the security of LN:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>
> 1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple RBF policies being used?
>
> 2.With recent discussion to change things in default RBF policy used by Core, will we have multiple versions using different policies? Are users and especially miners incentivized to use different versions and policies? Do they have freedom to use different RBF policy?
>
> 3.Are the recent improvements suggested for RBF policy only focused on Lightning Network and its security which will anyway remain same or become worse with multiple RBF policies?
>
> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can readily choose whatever policy *they* want.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220213/45f656e7/attachment-0001.html>

2023-06-07 23:03:12

- reply

📅 Original date posted:2022-02-05
📝 Original message:Thanks for this Bastien (and Gloria for initially posting about this).
I sympathetically skimmed the eclair PR (https://github.com/ACINQ/eclair/pull/2113) dealing with replaceable transactions fee bumping.
There will continue to be a (hopefully) friendly tug of war on this probably for the rest of Bitcoin's existence. I am sure people like Luke, Prayank etc will (rightfully) continue to raise that Lightning and other second layer protocols shouldn't demand that policy rules be changed if there is a reason (e.g. DoS vector) for those rules on the base network. But if there are rules that have no upside, introduce unnecessary complexity for no reason and make Lightning implementers like Bastien's life miserable attempting to deal with them I really hope we can make progress on removing or simplifying them.
This is why I think it is important to understand the rationales for introducing the rules in the first place (and why it is safe to remove them if indeed it is) and being as rigorous as possible on the rationales for introducing additional rules. It sounds like from Gloria's initial post we are still at a brainstorming phase (which is fine) but knowing what we know today I really hope we can learn from the mistakes of the original BIP 125, namely the Core implementation not matching the BIP and the sparse rationales for the rules. As Bastien says this is not criticizing the original BIP 125 authors, 7 years is a long time especially in Bitcoin world and they probably weren't thinking about Bastien sitting down to write an eclair PR in late 2021 (and reviewers of that PR) when they wrote the BIP in 2015.
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Monday, January 31st, 2022 at 3:57 PM, Bastien TEINTURIER via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Gloria,
>
> Many thanks for raising awareness on these issues and constantly pushing
> towards finding a better model. This work will highly improve the
> security of any multi-party contract trying to build on top of bitcoin
> (because most multi-party contracts will need to have timeout conditions
> and participants will need to make some transactions confirm before a
> timeout happens - otherwise they may lose funds).
>
> For starters, let me quickly explain why the current rules are hard to
> work with in the context of lightning (but I believe most L2 protocols
> will have the same issues). Feel free to skip this part if you are
> already convinced.
>
> ## Motivation
>
> The biggest pain point is BIP 125 rule 2.
> If I need to increase the fees of a time-sensitive transaction because
> the feerate has been rising since I broadcast it, I may need to also pay
> high fees just to produce a confirmed utxo that I can use. I'm actually
> paying a high fee twice instead of once (and needlessly using on-chain
> space, our scarcest asset, because we could have avoided that additional
> transaction!).
>
> It also has some annoying "non-determinism".
> Imagine that my transaction has been evicted from my mempool because its
> feerate was too low. I could think "Great, that means I don't have to
> apply BIP 125 restrictions, I can just fund this transaction as if it
> were a new one!". But actually I do, because my transaction could still
> be in miner's mempools and I have no way of knowing it...this means that
> whenever I have broadcast a transaction, I must assume that I will
> always need to abide by whatever replacement rules the network applies.
>
> Fortunately, as far as I understand it, this rule only exists because of
> a previous implementation detail of bitcoin core, so there's simply no
> good reason to keep it.
>
> The second biggest pain point is rule 3. It prevents me from efficiently
> using my capital while it's unconfirmed. Whenever I'm using a big utxo
> to fund a transaction, I will get a big change output, and it would
> really be a waste to be unable to use that change output to fund other
> transactions. In order to be capital-efficient, I will end up creating
> descendant trees for my time-sensitive transactions. But as Gloria
> explained, replacing all my children will cost me an absurdly large
> amount of fees. So what I'm actually planning to do instead is to RBF
> one of the descendants high enough to get the whole tree confirmed.
> But if those descendants' timeouts were far in the future, that's a
> waste, I paid a lot more fees for them than I should have. I'd like to
> just replace my transaction and republish the invalidated children
> independently.
>
> Rule 4 doesn't hurt as much as the two previous ones, I don't have too
> much to say about it.
>
> To be fair to the BIP 125 authors, all of these scenarios were very hard
> to forecast at the time this BIP was created. We needed years to build
> on those rules to get a better understanding of their limitations and if
> the rationale behind them made sense in the long term.
>
> ## Proposals
>
> I believe that now is a good time to re-think those, and I really like
> Gloria's categorization of the design constraints.
>
> I'd like to propose a different way of looking at descendants that makes
> it easier to design the new rules. The way I understand it, limiting the
> impact on descendant transactions is only important for DoS protection,
> not for incentive compatibility. I would argue that after evictions,
> descendant transactions will be submitted again (because they represent
> transactions that people actually want to make), so evicting them does
> not have a negative impact on mining incentives (in a world where blocks
> are full most of the time).
>
> I'm curious to hear other people's thoughts on that. If it makes sense,
> I would propose the following very simple rules:
>
> 1. The transaction's ancestor absolute fees must be X% higher than the
> previous transaction's ancestor fees
> 2. The transaction's ancestor feerate must be Y% higher than the
> previous transaction's ancestor feerate
>
> I believe it's completely ok to require increasing both the fees and
> feerate if we don't take descendants into account, because you control
> your ancestor set - whereas the descendant set may be completely out of
> your control.
>
> This is very easy to use by wallets, because the ancestor set is easy to
> obtain. And an important point is that the ancestor set is the same in
> every mempool, whereas the descendant set is not (your mempool may have
> rejected the last descendants, while other people's mempools may still
> contain them).
>
> Because of that reason, I'd like to avoid having a rule that relies on
> some size of the replaced descendant set: it may be valid in your
> mempool but invalid in someone else's, which makes it exploitable for
> pinning attacks.
>
> I believe these rules are incentive compatible (again, if you accept
> the fact that the descendants will be re-submitted and mined as well,
> so their fees aren't lost).
>
> Can we choose X and Y so that these two rules are also DoS-resistant?
> Unfortunately I'm not sure, so maybe we'll need to add a third rule to
> address that. But before we do, can someone detail what it costs for a
> node to evict a descendant tree? Given that bitcoin core doesn't allow
> chains of more than 25 transactions, the maximum number of transactions
> being replaced will be bounded by 25 * N (where N is the number of
> outputs of the transaction being replaced). If it's just O(n) pruning of
> a graph, maybe that's ok? Or maybe we make X or Y depend on the number
> of outputs of the transaction being replaced (this would need very
> careful thoughts)?
>
> If you made it this far, thanks for reading!
> A couple of comments on the previous messages:
>
>> Currently, if we see a transaction
>> that has the same txid as one in the mempool, we reject it as a
>> duplicate, even if the feerate is much higher. It's unclear to me if
>> we have a very strong reason to change this, but noting it as a
>> limitation of our current replacement policy.
>
> I don't see a strong reason from an L2 protocol's point of view yet, but
> there are many unkown unknowns. But from a miner incentive's point of
> view, we should keep the transaction with the higher feerate, shouldn't
> we? In that case it's also a more efficient use of on-chain space, which
> is a win, right?
>
>> We might have a more-or-less long transition period during which we support both...
>
> Yes, this is a long term thing.
> Even if bitcoin core releases a new version with updated RBF rules, as a
> wallet you'll need to keep using the old rules for a long time if you
> want to be safe.
>
> But it's all the more reason to try to ship this as soon as possible,
> this way maybe our grand-children will be able to benefit from it ;)
> (just kidding on the timespan obviously).
>
> Cheers,
> Bastien
>
> Le lun. 31 janv. 2022 à 00:11, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
>> Hi Gloria,
>>
>> Thanks for this RBF sum up. Few thoughts and more context comments if it can help other readers.
>>
>>> For starters, the absolute fee pinning attack is especially
>>> problematic if we apply the same rules (i.e. Rule #3 and #4) in
>>> Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
>>> LN channel. The mempool is rather full, so their pre-negotiated
>>> commitment transactions' feerates would not be considered high
>>> priority by miners. Bob broadcasts his commitment transaction and
>>> attaches a very large child (100KvB with 100,000sat in fees) to his
>>> anchor output. Alice broadcasts her commitment transaction with a
>>> fee-bumping child (200vB with 50,000sat fees which is a generous
>>> 250sat/vB), but this does not meet the absolute fee requirement. She
>>> would need to add another 50,000sat to replace Bob's commitment
>>> transaction.
>>
>> Solving LN pinning attacks, what we're aiming for is enabling a fair feerate bid between the counterparties, thus either forcing the adversary to overbid or to disengage from the confirmation competition. If the replace-by-feerate rule is adopted, there shouldn't be an incentive for Bob to
>> pick up the first option. Though if he does, that's a winning outcome for Alice, as one of the commitment transactions confirms and her time-sensitive second-stage HTLC can be subsequently confirmed.
>>
>>> It's unclear to me if
>>> we have a very strong reason to change this, but noting it as a
>>> limitation of our current replacement policy. See [#24007][12].
>>
>> Deployment of Taproot opens interesting possibilities in the vaults/payment channels design space, where the tapscripts can commit to different set of timelocks/quorum of keys. Even if the pre-signed states stay symmetric, whoever is the publisher, the feerate cost to spend can fluctuate.
>>
>>> While this isn't completely broken, and the user interface is
>>> secondary to the safety of the mempool policy
>>
>> I think with L2s transaction broadcast backend, the stability and clarity of the RBF user interface is primary. What we could be worried about is a too-much complex interface easing the way for an attacker to trigger your L2 node to issue policy-invalid chain of transactions. Especially, when we consider that an attacker might have leverage on chain of transactions composition ("force broadcast of commitment A then commitment B, knowing they will share a CPFP") or even transactions size ("overload commitment A with HTLCs").
>>
>>> * If the original transaction is in the top {0.75MvB, 1MvB} of the
>>> mempool, apply the current rules (absolute fees must increase and
>>> pay for the replacement transaction's new bandwidth). Otherwise, use a
>>> feerate-only rule.
>>
>> How this new replacement rule would behave if you have a parent in the "replace-by-feerate" half but the child is in the "replace-by-fee" one ?
>>
>> If we allow the replacement of the parent based on the feerate, we might decrease the top block absolute fees.
>>
>> If we block the replacement of the parent based on the feerate because the replacement absolute fees aren't above the replaced package, we still preclude a pinning vector. The child might be low-feerate junk and even attached to a low ancestor-score branch.
>>
>> If I'm correct on this limitation, maybe we could turn off the "replace-by-fee" behavior as soon as the mempool is fulfilled with a few blocks ?
>>
>>> * Rate-limit how many replacements we allow per prevout.
>>
>> Depending on how it is implemented, though I would be concerned it introduces a new pinning vector in the context of shared-utxo. If it's a hardcoded constant, it could be exhausted by an adversary starting at the lowest acceptable feerate then slowly increasing while still not reaching
>> the top of the mempool. Same if it's time-based or block-based, no guarantee the replacement slot is honestly used by your counterparty.
>>
>> Further, an above-the-average replacement frequency might just be the reflection of your confirmation strategy reacting to block schedule or mempools historical data. As long as the feerate penalty is paid, I lean to allow replacement.
>> (One solution could be to associate per-user "tag" to the LN transactions, where each "tag" would have its own replacement slots, but privacy?)
>>
>>> * Rate-limit transaction validation in general, per peer.
>>
>> I think we could improve on the Core's new transaction requester logic. Maybe we could bind the peer announced flow based on the feerate score (modulo validation time) of the previously validated transactions from that peer ? That said, while related to RBF, it sounds to me that enhancing Core's rate-limiting transaction strategy is a whole discussion in itself [0]. Especially ensuring it's tolerant to the specific requirements of LN & consorts.
>>
>>> What should they be? We can do some arithmetic to see what happens if
>>> you start with the biggest/lowest feerate transaction and do a bunch
>>> of replacements. Maybe we end up with values that are high enough to
>>> prevent abuse and make sense for applications/users that do RBF.
>>
>> That's a good question.
>>
>> One observation is that the attacker can always renew the set of DoSy utxos to pursue the attack. So maybe we could pick up constants scaled on the block size ? That way an attacker would have to burn fees, thus deterring them from launching an attack. Even if the attackers are miners, they have to renounce their income to acquire new DoSy utxos. If a low-fee period, we could scale up the constants ?
>>
>> Overall, I think there is the deployment issue to warn of. Moving to a new set of RBF rules implies for a lot of Bitcoin applications to rewrite their RBF logics. We might have a more-or-less long transition period during which we support both...
>>
>> Cheers,
>> Antoine
>>
>> [0] https://github.com/bitcoin/bitcoin/pull/21224
>>
>> Le jeu. 27 janv. 2022 à 09:10, Gloria Zhao via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> a écrit :
>>
>>> Hi everyone,
>>>
>>> This post discusses limitations of current Bitcoin Core RBF policy and
>>> attempts to start a conversation about how we can improve it,
>>> summarizing some ideas that have been discussed. Please reply if you
>>> have any new input on issues to be solved and ideas for improvement!
>>>
>>> Just in case I've screwed up the text wrapping again, another copy can be
>>> found here: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff
>>>
>>> ## Background
>>>
>>> Please feel free to skip this section if you are already familiar
>>> with RBF.
>>>
>>> Nodes may receive *conflicting* unconfirmed transactions, aka
>>> "double spends" of the same inputs. Instead of always keeping the
>>> first transaction, since v0.12, Bitcoin Core mempool policy has
>>> included a set of Replace-by-Fee (RBF) criteria that allows the second
>>> transaction to replace the first one and any descendants it may have.
>>>
>>> Bitcoin Core RBF policy was previously documented as BIP 125.
>>> The current RBF policy is documented [here][1]. In summary:
>>>
>>> 1. The directly conflicting transactions all signal replaceability
>>> explicitly.
>>>
>>> 2. The replacement transaction only includes an unconfirmed input if
>>> that input was included in one of the directly conflicting
>>> transactions.
>>>
>>> 3. The replacement transaction pays an absolute fee of at least the
>>> sum paid by the original transactions.
>>>
>>> 4. The additional fees pays for the replacement transaction's
>>> bandwidth at or above the rate set by the node's *incremental relay
>>> feerate*.
>>>
>>> 5. The sum of all directly conflicting transactions' descendant counts
>>> (number of transactions inclusive of itself and its descendants)
>>> does not exceed 100.
>>>
>>> We can split these rules into 3 categories/goals:
>>>
>>> - **Allow Opting Out**: Some applications/businesses are unable to
>>> handle transactions that are replaceable (e.g. merchants that use
>>> zero-confirmation transactions). We (try to) help these businesses by
>>> honoring BIP125 signaling; we won't replace transactions that have not
>>> opted in.
>>>
>>> - **Incentive Compatibility**: Ensure that our RBF policy would not
>>> accept replacement transactions which would decrease fee profits
>>> of a miner. In general, if our mempool policy deviates from what is
>>> economically rational, it's likely that the transactions in our
>>> mempool will not match the ones in miners' mempools, making our
>>> fee estimation, compact block relay, and other mempool-dependent
>>> functions unreliable. Incentive-incompatible policy may also
>>> encourage transaction submission through routes other than the p2p
>>> network, harming censorship-resistance and privacy of Bitcoin payments.
>>>
>>> - **DoS Protection**: Limit two types of DoS attacks on the node's
>>> mempool: (1) the number of times a transaction can be replaced and
>>> (2) the volume of transactions that can be evicted during a
>>> replacement.
>>>
>>> Even more abstract: our goal is to make a replacement policy that
>>> results in a useful interface for users and safe policy for
>>> node operators.
>>>
>>> ## Motivation
>>>
>>> There are a number of known problems with the current RBF policy.
>>> Many of these shortcomings exist due to mempool limitations at the
>>> time RBF was implemented or result from new types of Bitcoin usage;
>>> they are not criticisms of the original design.
>>>
>>> ### Pinning Attacks
>>>
>>> The most pressing concern is that attackers may take advantage of
>>> limitations in RBF policy to prevent other users' transactions from
>>> being mined or getting accepted as a replacement.
>>>
>>> #### SIGHASH_ANYONECANPAY Pinning
>>>
>>> BIP125#2 can be bypassed by creating intermediary transactions to be
>>> replaced together. Anyone can simply split a 1-input 1-output
>>> transaction off from the replacement transaction, then broadcast the
>>> transaction as is. This can always be done, and quite cheaply. More
>>> details in [this comment][2].
>>>
>>> In general, if a transaction is signed with SIGHASH\_ANYONECANPAY,
>>> anybody can just attach a low feerate parent to this transaction and
>>> lower its ancestor feerate. Even if you require SIGHASH\_ALL which
>>> prevents an attacker from changing any outputs, the input can be a
>>> very low amount (e.g. just above the dust limit) from a low-fee
>>> ancestor and still bring down the ancestor feerate of the transaction.
>>>
>>> TLDR: if your transaction is signed with SIGHASH\_ANYONECANPAY and
>>> signals replaceability, regardless of the feerate you broadcast at, an
>>> attacker can lower its mining priority by adding an ancestor.
>>>
>>> #### Absolute Fee
>>>
>>> The restriction of requiring replacement transactions to increase the
>>> absolute fee of the mempool has been described as "bonkers." If the
>>> original transaction has a very large descendant that pays a large
>>> amount of fees, even if it has a low feerate, the replacement
>>> transaction must now pay those fees in order to meet Rule #3.
>>>
>>> #### Package RBF
>>>
>>> There are a number of reasons why, in order to enable Package RBF, we
>>> cannot use the same criteria.
>>>
>>> For starters, the absolute fee pinning attack is especially
>>> problematic if we apply the same rules (i.e. Rule #3 and #4) in
>>> Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
>>> LN channel. The mempool is rather full, so their pre-negotiated
>>> commitment transactions' feerates would not be considered high
>>> priority by miners. Bob broadcasts his commitment transaction and
>>> attaches a very large child (100KvB with 100,000sat in fees) to his
>>> anchor output. Alice broadcasts her commitment transaction with a
>>> fee-bumping child (200vB with 50,000sat fees which is a generous
>>> 250sat/vB), but this does not meet the absolute fee requirement. She
>>> would need to add another 50,000sat to replace Bob's commitment
>>> transaction.
>>>
>>> Disallowing new unconfirmed inputs (Rule #2) in Package RBF would be
>>> broken for packages containing transactions already in the mempool,
>>> explained [here][7].
>>>
>>> Note: I originally [proposed][6] Package RBF using the same Rule #3
>>> and #4 before I realized how significant this pinning attack is. I'm
>>> retracting that proposal, and a new set of Package RBF rules would
>>> follow from whatever the new individual RBF rules end up being.
>>>
>>> #### Same Txid Different Witness
>>>
>>> Two transactions with the same non-witness data but different
>>> witnesses have the same txid but different wtxid, and the same fee but
>>> not necessarily the same feerate. Currently, if we see a transaction
>>> that has the same txid as one in the mempool, we reject it as a
>>> duplicate, even if the feerate is much higher. It's unclear to me if
>>> we have a very strong reason to change this, but noting it as a
>>> limitation of our current replacement policy. See [#24007][12].
>>>
>>> ### User Interface
>>>
>>> #### Using Unconfirmed UTXOs to Fund Replacements
>>>
>>> The restriction of only allowing confirmed UTXOs for funding a
>>> fee-bump (Rule #2) can hurt users trying to fee-bump their
>>> transactions and complicate wallet implementations. If the original
>>> transaction's output value isn't sufficient to fund a fee-bump and/or
>>> all of the user's other UTXOs are unconfirmed, they might not be able
>>> to fund a replacement transaction. Wallet developers also need to
>>> treat self-owned unconfirmed UTXOs as unusable for fee-bumping, which
>>> adds complexity to wallet logic. For example, see BDK issues [#144][4]
>>> and [#414][5].
>>>
>>> #### Interface Not Suitable for Coin Selection
>>>
>>> Currently, a user cannot simply create a replacement transaction
>>> targeting a specific feerate or meeting a minimum fee amount and
>>> expect to meet the RBF criteria. The fee amount depends on the size of
>>> the replacement transaction, and feerate is almost irrelevant.
>>>
>>> Bitcoin Core's `bumpfee` doesn't use the RBF rules when funding the
>>> replacement. It [estimates][13] a feerate which is "wallet incremental
>>> relay fee" (a conservative overestimation of the node's incremental
>>> relay fee) higher than the original transaction, selects coins for
>>> that feerate, and hopes that it meets the RBF rules. It never fails
>>> Rule #3 and #4 because it uses all original inputs and refuses to
>>> bump a transaction with mempool descendants.
>>>
>>> This is suboptimal, but is designed to work with the coin selection
>>> engine: select a feerate first, and then add fees to cover it.
>>> Following the exact RBF rules would require working the other way
>>> around: based on how much fees we've added to the transaction and its
>>> current size, calculate the feerate to see if we meet Rule #4.
>>>
>>> While this isn't completely broken, and the user interface is
>>> secondary to the safety of the mempool policy, we can do much better.
>>> A much more user-friendly interface would depend *only* on the
>>> fee and size of the original transactions.
>>>
>>> ### Updates to Mempool and Mining
>>>
>>> Since RBF was first implemented, a number of improvements have been
>>> made to mempool and mining logic. For example, we now use ancestor
>>> feerates in mining (allowing CPFP), and keep track of ancestor
>>> packages in the mempool.
>>>
>>> ## Ideas for Improvements
>>>
>>> ### Goals
>>>
>>> To summarize, these seem to be desired changes, in order of priority:
>>>
>>> 1. Remove Rule #3. The replacement should not be *required* to pay
>>> higher absolute fees.
>>>
>>> 2. Make it impossible for a replacement transaction to have a lower
>>> mining score than the original transaction(s). This would eliminate
>>> the `SIGHASH\_ANYONECANPAY` pinning attack.
>>>
>>> 3. Remove Rule #2. Adding new unconfirmed inputs should be allowed.
>>>
>>> 4. Create a more helpful interface that helps wallet fund replacement
>>> transactions that aim for a feerate and fee.
>>>
>>> ### A Different Model for Fees
>>>
>>> For incentive compatibility, I believe there are different
>>> formulations we should consider. Most importantly, if we want to get
>>> rid of the absolute fee rule, we can no longer think of it as "the
>>> transaction needs to pay for its own bandwidth," since we won't always
>>> be getting additional fees. That means we need a new method of
>>> rate-limiting replacements that doesn't require additional fees every
>>> time.
>>>
>>> While it makes sense to think about monetary costs when launching a
>>> specific type of attack, given that the fees are paid to the miner and
>>> not to the mempool operators, maybe it doesn't make much sense to
>>> think about "paying for bandwidth". Maybe we should implement
>>> transaction validation rate-limiting differently, e.g. building it
>>> into the P2P layer instead of the mempool policy layer.
>>>
>>> Recently, Suhas gave a [formulation][8] for incentive compatibility
>>> that made sense to me: "are the fees expected to be paid in the next
>>> (N?) blocks higher or lower if we process this transaction?"
>>>
>>> I started by thinking about this where N=1 or `1 + p`.
>>> Here, a rational miner is looking at what fees they would
>>> collect in the next block, and then some proportion `p` of the rest of
>>> the blocks based on their hashrate. We're assuming `p` isn't *so high*
>>> that they would be okay with lower absolute fees in the next 1 block.
>>> We're also assuming `p` isn't *so low* that the miner doesn't care
>>> about what's left of the mempool after this block.
>>>
>>> A tweak to this formulation is "if we process this transaction, would
>>> the fees in the next 1 block higher or lower, and is the feerate
>>> density of the rest of the mempool higher or lower?" This is pretty
>>> similar, where N=1, but we consider the rest of the mempool by feerate
>>> rather than fees.
>>>
>>> ### Mining Score of a Mempool Transaction
>>>
>>> We are often interested in finding out what
>>> the "mining score" of a transaction in the mempool is. That is, when
>>> the transaction is considered in block template building, what is the
>>> feerate it is considered at?
>>>
>>> Obviously, it's not the transaction's individual feerate. Bitcoin Core
>>> [mining code sorts][14] transactions by their ancestor feerate and
>>> includes them packages at a time, keeping track of how this affects the
>>> package feerates of remaining transactions in the mempool.
>>>
>>> *ancestor feerate*: Ancestor feerate is easily accessible information,
>>> but it's not accurate either, because it doesn't take into account the
>>> fact that subsets of a transaction's ancestor set can be included
>>> without it. For example, ancestors may have high feerates on their own
>>> or we may have [high feerate siblings][8].
>>>
>>> TLDR: *Looking at the current ancestor feerate of a transaction is
>>> insufficient to tell us what feerate it will be considered at when
>>> building a block template in the future.*
>>>
>>> *min(individual feerate, ancestor feerate)*: Another
>>> heuristic that is simple to calculate based on current mempool tooling
>>> is to use the [minimum of a transaction's individual score and its
>>> ancestor score][10] as a conservative measure. But this can
>>> overestimate as well (see the example below).
>>>
>>> *min ancestor feerate(tx + possible ancestor subsets)* We can also
>>> take the minimum of every possible ancestor subset, but this can be
>>> computationally expensive since there can be lots and lots of ancestor
>>> subsets.
>>>
>>> *max ancestor feerate(tx + possible descendant subsets)*: Another idea
>>> is to use the [maximum ancestor score of the transaction + each of its
>>> descendants][9]. This doesn't work either; it has the same blindspot
>>> of ancestor subsets being mined on their own.
>>>
>>> #### Mining Score Example
>>>
>>> Here's an example illustrating why mining score is tricky to
>>> efficiently calculate for mempool transactions:
>>>
>>> Let's say you have same-size transactions A (21sat/vB), B (1sat/vB),
>>> C(9sat/vB), D(5sat/vB).
>>> The layout is: grandparent A, parent B, and two children C and D.
>>>
>>> ```
>>> A
>>> ^
>>> B
>>> ^ ^
>>> C D
>>> ```
>>>
>>> A miner using ancestor packages to build block templates will first
>>> include A with a mining score of 21. Next, the miner will include B and
>>> C with a mining score of 6. This leaves D, with a mining score of 5.
>>>
>>> Note: in this case, mining by ancestor feerate results in the most
>>> rational decisions, but [a candidate set-based approach][10] which
>>> makes ancestor feerate much less relevant could
>>> be more advantageous in other situations.
>>>
>>> Here is a chart showing the "true" mining score alongside the values
>>> calculating using imperfect heuristics described above. All of them
>>> can overestimate or underestimate.
>>>
>>> ```
>>> A B C D
>>> mining score | 21 | 6 | 6 | 5 |
>>> ancestor feerate | 21 | 11 | 10.3 | 9 |
>>> min(individual, ancestor) | 21 | 1 | 9 | 5 |
>>> min(tx + ancestor subsets) | 21 | 1 | 5 | 3 |
>>> max(tx + descendants subsets) | 21 | 9 | 9 | 5 |
>>>
>>> ```
>>>
>>> Possibly the best solution for finding the "mining score" of a
>>> transaction is to build a block template, see what feerate each
>>> package is included at. Perhaps at some cutoff, remaining mempool
>>> transactions can be estimated using some heuristic that leans
>>> {overestimating, underestimating} depending on the situation.
>>>
>>> Mining score seems to be relevant in multiple places: Murch and I
>>> recently [found][3] that it would be very important in
>>> "ancestor-aware" funding of transactions (the wallet doesn't
>>> incorporate ancestor fees when using unconfirmed transactions in coin
>>> selection, which is a bug we want to fix).
>>>
>>> In general, it would be nice to know the exact mining priority of
>>> one's unconfirmed transaction is. I can think of a few block/mempool
>>> explorers who might want to display this information for users.
>>>
>>> ### RBF Improvement Proposals
>>>
>>> After speaking to quite a few people, here are some suggestions
>>> for improvements that I have heard:
>>>
>>> * The ancestor score of the replacement must be {5, 10, N}% higher
>>> than that of every original transaction.
>>>
>>> * The ancestor score of the replacement must be 1sat/vB higher than
>>> that of every original transaction.
>>>
>>> * If the original transaction is in the top {0.75MvB, 1MvB} of the
>>> mempool, apply the current rules (absolute fees must increase and
>>> pay for the replacement transaction's new bandwidth). Otherwise, use a
>>> feerate-only rule.
>>>
>>> * If fees don't increase, the size of the replacement transaction must
>>> decrease by at least N%.
>>>
>>> * Rate-limit how many replacements we allow per prevout.
>>>
>>> * Rate-limit transaction validation in general, per peer.
>>>
>>> Perhaps some others on the mailing list can chime in to throw other
>>> ideas into the ring and/or combine some of these rules into a sensible
>>> policy.
>>>
>>> #### Replace by Feerate Only
>>>
>>> I don't think there's going to be a single-line feerate-based
>>> rule that can incorporate everything we need.
>>> On one hand, a feerate-only approach helps eliminate the issues
>>> associated with Rule #3. On the other hand, I believe the main concern
>>> with a feerate-only approach is how to rate limit replacements. We
>>> don't want to enable an attack such as:
>>>
>>> 1. Attacker broadcasts large, low-feerate transaction, and attaches a
>>> chain of descendants.
>>>
>>> 2. The attacker replaces the transaction with a smaller but higher
>>> feerate transaction, attaching a new chain of descendants.
>>>
>>> 3. Repeat 1000 times.
>>>
>>> #### Fees in Next Block and Feerate for the Rest of the Mempool
>>>
>>> Perhaps we can look at replacements like this:
>>>
>>> 1. Calculate the directly conflicting transactions and, with their
>>> descendants, the original transactions. Check signaling. Limit the
>>> total volume (e.g. can't be more than 100 total or 1MvB or something).
>>>
>>> 2. Find which original transactions would be in the next ~1 block. The
>>> replacement must pay at least this amount + X% in absolute fees. This
>>> guarantees that the fees of the next block doesn't decrease.
>>>
>>> 3. Find which transactions would be left in the mempool after that ~1
>>> block. The replacement's feerate must be Y% higher than the maximum
>>> mining score of these transactions. This guarantees that you now have
>>> only *better* candidates in your after-this-block mempool than you did
>>> before, even if the size and fees the transactions decrease.
>>>
>>> 4. Now you have two numbers: a minimum absolute fee amount and a
>>> minimum feerate. Check to see if the replacement(s) meet these
>>> minimums. Also, a wallet would be able to ask the node "What fee and
>>> feerate would I need to put on a transaction replacing this?" and use
>>> this information to fund a replacement transaction, without needing to
>>> guess or overshoot.
>>>
>>> Obviously, there are some magic numbers missing here. X and Y are
>>> TBD constants to ensure we have some kind of rate limiting for the
>>> number of replacements allowed using some set of fees.
>>>
>>> What should they be? We can do some arithmetic to see what happens if
>>> you start with the biggest/lowest feerate transaction and do a bunch
>>> of replacements. Maybe we end up with values that are high enough to
>>> prevent abuse and make sense for applications/users that do RBF.
>>>
>>> ### Mempool Changes Need for Implementation
>>>
>>> As described in the mining score section above,
>>> we may want additional tooling to more accurately assess
>>> the economic gain of replacing transactions in our mempool.
>>>
>>> A few options have been discussed:
>>>
>>> * Calculate block templates on the fly when we need to consider a
>>> replacement. However, since replacements are [quite common][11]
>>> and the information might be useful for other things as well,
>>> it may be worth it to cache a block template.
>>>
>>> * Keep a persistent block template so that we know what transactions
>>> we would put in the next block. We need to remember the feerate
>>> at which each transaction was included in the template, because an
>>> ancestor package may be included in the same block template in
>>> multiple subsets. Transactions included earlier alter the ancestor
>>> feerate of the remaining transactions in the package. We also need
>>> to keep track of the new feerates of transactions left over.
>>>
>>> * Divide the mempool into two layers, "high feerate" and "low
>>> feerate." The high feerate layer contains ~1 block of packages with
>>> the highest ancestor feerates, and the low feerate layer contains
>>> everything else. At the edge of a block, we have a Knapsacky problem
>>> where the next highest ancestor feerate package might not fit, so we
>>> would probably want the high feerate layer ~2MvB or something to avoid
>>> underestimating the fees.
>>>
>>> ## Acknowledgements
>>>
>>> Thank you to everyone whose RBF-related suggestions, grievances,
>>> criticisms and ideas were incorporated in this document:
>>> Andrew Chow, Matt Corallo, Suhas Daftuar, Christian Decker,
>>> Mark Erhardt, Lloyd Fournier, Lisa Neigut, John Newbery,
>>> Antoine Poinsot, Antoine Riard, Larry Ruane,
>>>
>>> S3RK and Bastien Teinturier.
>>>
>>> Thanks for reading!
>>>
>>> Best,
>>> Gloria
>>> [1]: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
>>> [2]: https://github.com/bitcoin/bitcoin/pull/23121#issuecomment-929475999
>>> [3]: https://github.com/Xekyo/bitcoin/commit/d754b0242ec69d42c570418aebf9c1335af0b8ea
>>> [4]: https://github.com/bitcoindevkit/bdk/issues/144
>>> [5]: https://github.com/bitcoindevkit/bdk/issues/414
>>> [6]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
>>> [7]: https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#new-unconfirmed-inputs-rule-2
>>> [8]: https://github.com/bitcoin/bitcoin/pull/23121#discussion_r777131366
>>> [9]: https://github.com/bitcoin/bitcoin/pull/22290#issuecomment-865887922
>>> [10]: https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
>>> [11]: https://github.com/bitcoin/bitcoin/pull/22539#issuecomment-885763670
>>> [12]: https://github.com/bitcoin/bitcoin/pull/24007
>>> [13]: https://github.com/bitcoin/bitcoin/blob/1a369f006fd0bec373b95001ed84b480e852f191/src/wallet/feebumper.cpp#L114
>>>
>>> [14]: https://github.com/bitcoin/bitcoin/blob/cf5bb048e80d4cde8828787b266b7f5f2e3b6d7b/src/node/miner.cpp#L310-L320
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220205/3641f38d/attachment-0001.html>

2023-06-07 23:02:54

- reply

📅 Original date posted:2022-01-28
📝 Original message:> Even if we were to adopt something like TXHASH, how long is it going to take to develop, test, and release? My guess is "a while" - in the meantime, users of Bitcoin are without a vault strategy that doesn't require either presigning transactions with ephemeral keys (operationally difficult) or multisig configurations that would make Rube Goldberg blush (operationally difficult and precarious).
To me this seems to be jumping ahead a number of steps from where we are at the current time. If the ecosystem was widely using all the tools available to them at the current time (MuSig(2), Taproot trees to embed complex scripts, Miniscript etc), was testing out upcoming available tools like threshold key aggregation schemes (e.g. FROST) on signets and the final missing piece was a covenant opcode to avoid the deleted key requirement then the argument for urgency would be stronger. I would still share the concerns I and many others have repeated over rushing soft forks and treating mainnet as a testbed for new use cases rather than the final destination for changes that will stand the test of time. But I would be a lot more sympathetic to that argument.
This isn't a criticism of the ecosystem or individual vault projects like Revault, it is clearly still very early. darosior (Revault) is working on getting a first version of Miniscript finalized and in Core [0] and I'm assuming will be part of the effort to get Taproot support in Miniscript assuming that initial effort succeeds. Murch is tracking basic send and receive to the P2TR addresses (not complex scripts, multisig, MuSig(2), merely single key spends) in the ecosystem [1] and there is still a long way to go there.
There are a bunch of covenant opcodes that have been enabled on Liquid [2] that I haven't heard yet of anyone building vault prototypes with. It would be good to get others (TLUV, TXHASH) in future. There is not even a custom signet with CTV (as far as I know) for those who subscribe to the view that we must rush to get CTV activated on mainnet as soon as possible with no thought to what opcodes might follow.
When this discussion focuses on the pros and cons of various proposals and how they are being tested and used in prototypes on signets, sidechains I think it is really productive. But when it gets onto urgency (or worse activation speculation) I am just perplexed. That viewpoint seems to completely ignore where we are currently with Taproot use and tooling (on which most vault designs will presumably build) and even more perplexingly where we are with vault prototypes on signets, sidechains.
I am sure at some point in the future we will have various vault prototypes on signets, sidechains making use of Taproot, Miniscript, MuSig(2), FROST etc and crying out for a covenant opcode or sighash flag to go into production on mainnet. But we seem miles away from that at the present time.
[0]: https://github.com/bitcoin/bitcoin/pull/24147
[1]: https://en.bitcoin.it/wiki/Bech32_adoption
[2]: https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, January 28th, 2022 at 12:18 AM, James O'Beirne via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> I don't think implementing a CTV opcode that we expect to largely be obsoleted by a TXHASH at a later date is yielding good value from a soft fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it). You're presenting a novel idea that, as far as I know, hasn't had much time to bake in public. Like Jeremy, I'm concerned by the combinatorial growth of flags and the implications that has for testing. Caching for something like TXHASH looks to me like a whole different ballgame relative to CTV, which has a single kind of hash.
>
> Even if we were to adopt something like TXHASH, how long is it going to take to develop, test, and release? My guess is "a while" - in the meantime, users of Bitcoin are without a vault strategy that doesn't require either presigning transactions with ephemeral keys (operationally difficult) or multisig configurations that would make Rube Goldberg blush (operationally difficult and precarious). The utility of vaulting seems underappreciated among consensus devs and it's something I'd like to write about soon in a separate post.
>
>> The strongest argument I can make in favour of CTV would be something like: "We definitely want bare CTV and if we are going to add CTV to legacy script (since we cannot use TXHASH in legacy script), then it is actually easier not to exclude it from tapscript, even if we plan to add TXHASH to tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its simplicity - it's relatively easy to reason about and, at this point, pretty well understood. It seems like a low-risk change relative to some of the other covenant proposals, nearly all of which elicit a good deal of headscratching (at least from me) and seem to require not only larger on-chain footprints but sizable code changes.
>
>> I am sensitive to technical debt and soft fork processes
>
> If OP_CTV ends up being the most practical approach for vaulting - among other things - in terms of weight (which it seems to be at the moment) I don't think "technical debt" is an applicable term.
>
> On Thu, Jan 27, 2022 at 5:20 PM Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I am sensitive to technical debt and soft fork processes, and I don't believe I'm unordinary particular about these issues. Once implemented, opcodes must be supported and maintained indefinitely. Some opcodes are easier to maintain than others. These particular opcodes involve caching of hash computations and, for that reason, I would judge them to be of moderate complexity.
>>
>> But more importantly, soft-forks are inherently a risky process, so we should be getting as much value out of them as we reasonably can. I don't think implementing a CTV opcode that we expect to largely be obsoleted by a TXHASH at a later date is yielding good value from a soft fork process.
>>
>> The strongest argument I can make in favour of CTV would be something like: "We definitely want bare CTV and if we are going to add CTV to legacy script (since we cannot use TXHASH in legacy script), then it is actually easier not to exclude it from tapscript, even if we plan to add TXHASH to tapscript as well."
>>
>> But that argument basically rests the entire value of CTV on the shoulders of bare CTV. As I understand, the argument for why we want bare CTV, instead of just letting people use tapscript, involves the finer details of weight calculations, and I haven't really reviewed that aspect yet. I think it would need to be pretty compelling to make it worthwhile to add CTV for that one use case.
>>
>> Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full' set of things needed", I totally agree we will want more things such as CAT, rolling SHA256 opcodes, wider arithmetic, pushing amounts onto the stack, some kind of tapleaf manipulation and/or TWEAKVERIFY. For now, I only want to argue TXHASH+CSFSV is better than CTV+APO because it gives us more value, namely oracle signature verification. In particular, I want to argue that TXHASH's push semantics is better that CTV's verify semantics because it composes better by not needing to carry an extra 32-bytes (per instance) in the witness data. I expect that in a world of full recursive covenants, TXHASH would still be useful as a fast and cheap way to verify the "payload" of these covenants, i.e. that a transaction is paying a certain, possibly large, set of addresses certain specific amounts of money. And even if not, TXHASH+CSFSV would still be the way that eltoo would be implemented under this proposal.
>>
>> On Wed, Jan 26, 2022 at 5:16 PM Jeremy <jlrubin at mit.edu> wrote:
>>
>>> Hi Russell,
>>>
>>> Thanks for this email, it's great to see this approach described.
>>>
>>> A few preliminary notes of feedback:
>>>
>>> 1) a Verify approach can be made to work for OP_TXHASH (even with CTV as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash flag to read the hash at stack[-2], then the hash can be passed in instead of put on the stack. This has the disadvantage of larger witnesses, but the advantage of allowing undefined sighash flags to pass for any hash type.
>>> 2) using the internal key for APO covenants is not an option because it makes transaction construction interactive and precludes contracts with a NUMS point taproot key. Instead, if you want similar savings, you should advocate an OP_GENERATOR which puts G on the stack. Further, an untagged APO variant which has split R and S values would permit something like <sig> OP_GENERATOR OP_GENERATOR CHECKSIGAPO, which would be only 2 more bytes than CTV.
>>> 3) I count something like 20 different flags in your proposal. As long as flags are under 40 bytes (and 32 assuming we want it to be easy) without upgrading math this should be feasible to manipulate on the stack programmatically. This is ignoring some of the more flexible additions you mention about picking which outputs/inputs are included. However, 20 flags means that for testing we would want comprehensive tests and understanding for ~1 million different flag combos and the behaviors they expose. I think this necessitates a formal model of scripting and transaction validity properties. Are there any combinations that might be undesirable?
>>> 4) Just hashing or not hashing isn't actually that flexible, because it doesn't natively let you do things like (for example) TLUV. You really do need tx operations for directly manipulating the data on the stack to construct the hash if you want more flexible covenants. This happens to be compatible with either a Verify or Push approach, since you either destructure a pushed hash or build up a hash for a verify.
>>> 5) Flexible hashing has the potential for quadratic hashing bugs. The fields you propose seem to be within similar range to work you could cause with a regular OP_HASH256, although you'd want to be careful with some of the proposed extensions that you don't create risk of quadratic hashing, which seems possible with an output selecting opcode unless you cache properly (which might be tricky to do). Overall for the fields explicitly mentioned, seems safe, the "possibles" seem to have some more complex interactions. E.g., CTV with the ability to pick a subset of outputs would be exposed to quadratic hashing.
>>> 6) Missing field: covering the annex or some sub-range of the annex (quadratic hashing issues on the latter)
>>> 7) It seems simpler to, for many of these fields, push values directly (as in OP_PUSHTXDATA from Johnson Lau) because the combo of flags to push the hash of a single output's amount to emulate OP_AMOUNT looks 'general but annoying'. It may make more sense to do the OP_PUSHTXDATA style opcode instead. This also makes it simpler to think about the combinations of flags, since it's really N independent multi-byte opcodes.
>>>
>>> Ultimately if we had OP_TXHASH available "tomorrow", I would be able to build out the use cases I care about for CTV (and more). So I don't have an opposition on it with regards to lack of function.
>>>
>>> However, if one finds the TXHASH approach acceptable, then you should also be relatively fine doing APO, CTV, CSFS, TXHASH acceptable in any order (whenever "ready"), unless you are particularly sensitive to "technical debt" and "soft fork processes". The only costs of doing something for CTV or APO given an eventual TXHASH is perhaps a wasted key version or the 32 byte argument of a NOP opcode and some code to maintain.
>>>
>>> Are there other costs I am missing?
>>>
>>> However, as it pertains to actual rollout:
>>>
>>> - OP_TXHASH+CSFSV doesn't seem to be the "full" set of things needed (we still need e.g. OP_CAT, Upgraded >=64 bit Math, TLUV or OP_TWEAK OP_TAPBRANCH OP_MANIPULATETAPTREE, and more) to full realize covenanting power it intends to introduce.
>>> - What sort of timeline would it take to ready something like TXHASH (and desired friends) given greater scope of testing and analysis (standalone + compared to CTV)?
>>> - Is there opposition from the community to this degree of general/recursive covenants?
>>> - Does it make "more sense" to invest the research and development effort that would go into proving TXHASH safe, for example, into Simplicity instead?
>>>
>>> Overall, my opinion is that:
>>>
>>> - TXHASH is an acceptable theoretical approach, and I am happy to put more thought into it and maybe draft a prototype of it.
>>> - I prefer CTV as a first step for pragmatic engineering and availability timeline reasons.
>>> - If TXHASH were to take, optimistically, 2 years to develop and review, and then 1 year to activate, the "path dependence of software" would put Bitcoin in a much better place were we to have CTV within 1 year and applications (that are to be a subset of TXHASH later) being built over the next few years enhanced in the future by TXHASH's availability.
>>> - There is an element of expediency meritted for something like CTV insofar as it provides primitives to tackle time sensitive issues around privacy, scalability, self custody, and decentralization. The aforementioned properties may be difficult to reclaim once given away (with the exception of perhaps scalability).
>>> - Bringing CTV to an implemented state of near-unanimous "we could do this, technically" is good for concretely driving the process of review for any covenant proposals forward, irrespective of if we ultimately activate. (I.e., if there were a reason we could not do CTV safely, it would likely have implications for any other future covenant)
>>>
>>> Concretely, I'm not going to stop advocating for CTV based on the above, but I'm very happy to have something new in the mix to consider!
>>>
>>> Best,
>>>
>>> Jeremy
>>>
>>> --
>>> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
>>>
>>> On Wed, Jan 26, 2022 at 9:23 AM Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Recapping the relationship between CTV and ANYPREVOUT::
>>>>
>>>> It is known that there is a significant amount of overlap in the applications that are enabled by the CTV and ANYPREVOUT proposals despite the fact that their primary applications (congestion control for CTV and eltoo lightning channels for ANYPREVOUT) are quite distinct.
>>>> In particular, ANYPREVOUT can enable most of the applications of CTV, albeit with a higher cost. The primary functionality of CTV is to allow a scriptPubKey to make a commitment to its spending transaction's hash with the input's TXID excluded from the hash. This exclusion is necessary because the scriptPubKey is hashed into the input's TXID, and including the TXID would cause a cycle of hash commitments, which is impossible to construct. On the other hand, ANYPREVOUT defines a signature hash mode that similarly excludes the inputs TXID for its purpose of rebindable signatures.
>>>>
>>>> This means that ANYPREVOUT can mimic most of the properties of CTV by committing both a public key along with an ANYPREVOUT signature inside scriptPubKey. In fact, the only reason Bitcoin doesn't have covenants today is due to this cycle between scriptPubKeys and the TXIDs that occur in all the sighash modes.
>>>>
>>>> The major differences between simulating CTV via ANYPREVOUT and the actual CTV proposal is: (1) The cost of simulating CTV. With CTV the spending transaction is committed using a hash of 32 bytes, while simulating it with ANYPREVOUT requires 64 bytes for a signature, and 32 bytes for some public key, plus a few more bytes for various flags. Some of that cost could be reduced by using the inner public key (1 byte representation) and, if we had CAT, maybe by assembling the signature from reusable pieces (i.e. setting the nonce of the commited signature equal to the public key).
>>>>
>>>> The other major difference is: (2) CTV's transaction hash covers values such as the number of inputs in the transaction and their sequence numbers, which ANYPREVOUT does not cover. CTV's hash contains enough information so that when combined with the missing TXIDs, you can compute the TXID of the spending transaction. In particular if the number of inputs is committed to being 1, once the scriptpubkey's transaction id is known and committed to the blockchain, the TXID of its spending transaction is deducible. And if that transaction has outputs that have CTV commitments in them, you can deduce their spending TXIDs in turn. While this is a pretty neat feature, something that ANYPREVOUT cannot mimic, the main application for it is listed as using congestion control to fund lightning channels, fixing their TXIDs in advance of them being placed on chain. However, if ANYPREVOUT were used to mimic CTV, then likely it would be eltoo channels that would be funded, and it isn't necessary to know the TXIDs of eltoo channels in advance in order to use them.
>>>>
>>>> An Alternative Proposal::
>>>>
>>>> Given the overlap in functionality between CTV and ANYPREVOUT, I think it makes sense to decompose their operations into their constituent pieces and reassemble their behaviour programmatically. To this end, I'd like to instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.
>>>>
>>>> OP_TXHASH would pop a txhash flag from the stack and compute a (tagged) txhash in accordance with that flag, and push the resulting hash onto the stack.
>>>> OP_CHECKSIGFROMSTACKVERIFY would pop a pubkey, message, and signature from the stack and fail if the signature does not verify on that message.
>>>>
>>>> CTV and TXHASH have roughly equivalent functionality. 'CTV DROP' can be simulated by '<ctv_style_flag> TXHASH EQUALVERIFY'. The reverse is also true where '<ctv_style_flag> TXHASH' can be simulated by CTV by '<ctv-result-from-witness-stack> CTV', however, as you can see, simulating TXHASH from CTV is much more expensive than the other way around, because the resulting 32-byte hash result must be included as part of the witness stack.
>>>>
>>>> '<anyprevout-pubkey> CHECKSIGVERIFY can be simulated by '<apo_style_flag> TXHASH <pubkey> CHECKSIGFROMSTACKVERIFY'. Here we see the advantage of pushing the hash value onto the stack. APO can be simulated without needing to include a copy of the resulting txhash inside the witness data.
>>>>
>>>> In addition to the CTV and ANYPREVOUT applications, with CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages signed by oracles for oracle applications. This is where we see the benefit of decomposing operations into primitive pieces. By giving users the ability to program their own use cases from components, we get more applications out of fewer op codes!
>>>>
>>>> Caveats::
>>>>
>>>> First, I acknowledge that replicating the behaviour of CTV and ANYPREVOUT does cost a few more bytes than using the custom purpose built proposals themselves. That is the price to be paid when we choose the ability to program solutions from pieces. But we get to reap the advantages of being able to build more applications from these pieces.
>>>>
>>>> Unlike CTV, TXHASH is not NOP-compatable and can only be implemented within tapscript. In particular, bare CTV isn't possible with this proposal. However, this proposal doesn't preclude the possibility of having CTV added to legacy script in while having TXHASH added to tapscript.
>>>>
>>>> For similar reasons, TXHASH is not amenable to extending the set of txflags at a later date. In theory, one could have TXHASH abort-with-success when encountering an unknown set of flags. However, this would make analyzing tapscript much more difficult. Tapscripts would then be able to abort with success or failure depending on the order script fragments are assembled and executed, and getting the order incorrect would be catastrophic. This behavior is manifestly different from the current batch of OP_SUCCESS opcodes that abort-with-success just by their mere presence, whether they would be executed or not.
>>>>
>>>> I believe the difficulties with upgrading TXHASH can be mitigated by designing a robust set of TXHASH flags from the start. For example having bits to control whether (1) the version is covered; (2) the locktime is covered; (3) txids are covered; (4) sequence numbers are covered; (5) input amounts are covered; (6) input scriptpubkeys are covered; (7) number of inputs is covered; (8) output amounts are covered; (9) output scriptpubkeys are covered; (10) number of outputs is covered; (11) the tapbranch is covered; (12) the tapleaf is covered; (13) the opseparator value is covered; (14) whether all, one, or no inputs are covered; (15) whether all, one or no outputs are covered; (16) whether the one input position is covered; (17) whether the one output position is covered; (18) whether the sighash flags are covered or not (note: whether or not the sighash flags are or are not covered must itself be covered). Possibly specifying which input or output position is covered in the single case and whether the position is relative to the input's position or is an absolute position.
>>>>
>>>> That all said, even if other txhash flag modes are needed in the future, adding TXHASH2 always remains an option.
>>>>
>>>> Interactions with potential future opcodes::
>>>>
>>>> We should give some consideration on how these opcodes may interact with future opcodes such as CAT, rolling SHA256 opcodes, or how it might interface with other covenant opcodes that may do things like, directly push input or output amounts onto the stack for computation purposes, opcodes which have been added to the Elements project.
>>>>
>>>> With CAT and/or rolling SHA256 opcodes and/or existing SHA256 opcodes, the CHECKSIGFROMSTACKVERIFY could verify signatures on programmatically assembled messages. Also, in combination with multiple calls to TXHASH, could be used to create signatures that commit to complex subsets of transaction data.
>>>>
>>>> If new opcodes are added to push parts of the transaction data direction onto the stack, e.g. OP_INSPECTOUTPUTVALUE, there is perhaps concern that they would obsolete TXHASH, since, in the presence of rolling SHA256 opcodes, TXHASH could be simulated. However, given that TXHASH can compactly create a hash of large portions of transaction data, it seems unlikely that TXHASH would fall into disuse. Also, a combination of TXHASH and transaction introspection opcodes can be used to build "subtractive covenants".
>>>>
>>>> The usual way of building a covenant, which we will call "additive covenants", is to push all the parts of the transaction data you would like to fix onto the stack, hash it all together, and verify the resulting hash matches a fixed value. Another way of building covenants, which we will call "subtractive covenants", is to push all the parts of the transaction data you would like to remain free onto the stack. Then use rolling SHA256 opcodes starting from a fixed midstate that commits to a prefix of the transaction hash data. The free parts are hashed into that midstate. Finally, the resulting hash value is verified to match a value returned by TXHASH. The ability to nicely build subtractive covenants depends on the details of how the TXHASH hash value is constructed, something that I'm told CTV has given consideration to.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220128/4df9e5b2/attachment-0001.html>

2023-06-07 23:02:37

- reply

📅 Original date posted:2022-01-20
📝 Original message:Hi
I'd just like to bring some attention to this blog post from the Suredbits team who when implementing Taproot in bitcoin-s found a mainnet output that did not conform to the BIP 340 specification [0] (invalid x coordinate) and hence were burned.
https://suredbits.com/taproot-funds-burned-on-the-bitcoin-blockchain/
To be clear this is was an error made by an unknown developer rather than a bug in the Taproot BIPs or Core implementation.
I'd certainly encourage the community to share with this list mistakes they make or things they find confusing (i.e. stump them for long periods of time) when re-implementing Taproot or supporting Taproot in wallets. I suspect things like eliminating the key path [1] or eliminating the script path [2] will end up being common sources of confusion for wallets.
I'm also open to ideas on how there can be greater information sharing so Taproot implementers don't end up making the same mistakes or spending hours confused over the same things.
I've heard some feedback on a number of occasions now that the Taproot BIPs although thorough and exhaustive aren't geared directly towards implementers and adopters. We discussed this at an online Socratic last year [3] with Craig Raw an early Taproot adopter with Sparrow Wallet. The transcript of that links to a bunch of existing resources (StackExchange posts, the Optech series "Preparing for Taproot", Optech workshop etc) that may be useful for implementers.
wumpus also suggested that a new informational BIP might be a good idea as a first port of call for Taproot implementers who find BIP 340-342 dense and difficult to parse. This is certainly something we can do once it becomes clearer what that informational BIP should contain.
Of course the Libera IRC channels #bitcoin-dev (for general Bitcoin development) and #bitcoin-core-dev (for Core related development) are there for discussion and questions. And as many will already know Murch is tracking P2TR support on the Bitcoin wiki [4].
Thanks
Michael
[0]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
[1]: https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path
[2]: https://bitcoin.stackexchange.com/questions/99325/how-do-i-construct-a-p2tr-address-if-i-just-want-to-use-the-key-path
[3]: https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/
[4]: https://en.bitcoin.it/wiki/Bech32_adoption
-- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220120/3e6a6d5a/attachment.html>

2023-06-07 23:02:32

- reply

📅 Original date posted:2022-01-19
📝 Original message:Eric, Luke
Can I request that you don't discuss activation methods for future soft forks on a thread for CTV BIP review? I (and a number of others [0]) do not support an upcoming activation attempt of standalone OP_CTV. If you want to discuss activation methods for soft forks generally it would be much better if you set up a separate thread. OP_CTV is not the only current soft fork proposal and there will likely be more.
The activation discussion for Taproot was deliberately kept separate from the review of the Taproot BIPs and implementation. It only commenced once there was overwhelming community consensus for the soft fork to be activated (months after in fact). Though you are free to discuss whatever topics you wish (obviously) discussing soft fork activation methods on a OP_CTV thread might give the mistaken impression that OP_CTV is the next soft fork to be activated which is mere speculation at this point. In an ideal world the promoters of OP_CTV would follow the strong precedent set by the authors and contributors to the Taproot BIPs but regrettably that seems to have gone out the window at this point.
Thanks
Michael
[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----Original Message-----
>
> From: Luke Dashjr luke at dashjr.org
>
> Sent: Tuesday, January 18, 2022 2:10 PM
>
> To: eric at voskuil.org
>
> Cc: 'Bitcoin Protocol Discussion' bitcoin-dev at lists.linuxfoundation.org
>
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 eric at voskuil.org wrote:
>
> > The only material distinction between BIP9 and BIP8 is that the latter
> >
> > may activate without signaled support of hash power enforcement.
> >
> > As unenforced soft forks are not "backward compatible" they produce a
> >
> > chain split.
>
> Enforcement of the Bitcoin consensus protocol is by users, not miners.
Given that I stated "hash power enforcement" it is quite clear that this is
in fact only produced by mining. You are misrepresenting my statement to
make an emotional appeal. Without "hash power enforcement", a soft fork is
NOT backward compatible.
"[enforcement of] consensus protocol" is of course by merchants, but that is
not the question at hand. The question is explicitly compatibility. Anyone
can activate a soft fork at any time, but without "hash power enforcement"
soft forks are NOT backward compatible.
> Softforks never produce a chain split. Miners can, and might try to do it
to cause disruption in retaliation, but the softfork itself does not.
Maybe you are trying to split hairs given the fact that blocks are produced
only by miners, so only miners can "cause" a split.
But through not intention ("disruption in retaliation") whatsoever by
mining, a soft fork will result in those activating the rule being split off
the original chain unless majority hash power enforces the rule. The fact
that doing nothing apart from deploying the rule will result in a split is
the very definition of NOT compatible.
I assume you will argue that the original chain is not "valid" and therefore
irrelevant (as if no chain split occurred). But again the point is about
compatibility. The appearance of multiple chains, which appear valid
according to either the previous or new rules, is obviously the
incompatibility.
I shouldn't have to point this out, but observed chain splits have occurred
in more the one large scale soft fork deployment. These splits have only
been resolved through hash power enforcement. In 2010 it took 51 blocks
before the current chain took the lead. In 2012 minority chains persisted
for months. The deployment of soft forks caused these splits, NOT the
actions of miners. And unless majority hash power eventually enforces it,
the soft fork branch necessarily dies.
> > It was for this reason alone that BIP8 never gained sufficient
> >
> > support.
>
> BIP 8 in fact achieved consensus for Taproot activation.
Please define "achieved consensus", because by any definition I can imagine,
this is simply untrue.
> > This is one of the most misleading statements I've seen here. It's not
> >
> > technically a lie, because it states what "should" happen. But it is
> >
> > clearly intended to lead people to believe that BIP8 was actually used
> >
> > ("again") - it was not. ST was some technical tweaks to BIP9.
>
> BIP 8 was used to activate Taproot.
No, it wasn't. I find it hard to imaging how you rationalize such grossly
misleading statements.
> > The outright deception around this one topic has led to significant
> >
> > unnecessary conflict in the community. Make your argument, but make it
> >
> > honestly.
>
> You are the one attempting to deceive here.
That is for others to decide. I appreciate your responses above, since they
certainly help clarify what is happening here.
e
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:02:02

- reply

📅 Original date posted:2022-01-04
📝 Original message:You are working on a use case of OP_CTV now? Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements. Regardless stick with it and build out more than a rudimentary proof of concept. That is one of the things that is severely lacking at this point for OP_CTV.
> TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
I would hope you weren't against Miniscript because Sapio is built on top of it :) But whatever have fun, I can't do this all day.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 4th, 2022 at 3:06 PM, Prayank <prayank at tutanota.de> wrote:
> What I have done related to OP_CTV?
>
> https://twitter.com/prayankgahlot/status/1456643891885592579
>
> What am I currently working on that is not shared publicly and will do in next few weeks?
>
> Review pull request 21702 and write contracts using Sapio based on few ideas that I already have.
>
> What is this assessment based on?
>
> A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed.
>
>> you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones)
>
> I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others.
>
>> A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>
> TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
>
> I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork.
>
>> It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>
> I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced.
>
>> You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>
> I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin.
>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>
> I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things.
>
>> I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point.
>
> If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
> Jan 4, 2022, 19:45 by michaelfolkson at protonmail.com:
>
>>> It should be ready to go in a few months IMO
>>
>> What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>>
>> You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>>
>> I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>>
>>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>
>> Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.
>>
>>>> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>
>>> Because its not ready?
>>
>> As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.
>>
>> I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.
>>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>>
>> [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>>
>> --
>>
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Michael,
>>>
>>>> If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>>>
>>> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>>>
>>>> It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>>>
>>> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>>>
>>>> It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>>>
>>> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>>>
>>>> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>>
>>> Because its not ready?
>>>
>>>> Similar work has not been done for any of the speculated use cases of OP_CTV.
>>>
>>> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>>>
>>> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>>>
>>>> Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>>>
>>> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>>>
>>>> This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>>>
>>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>>
>>>> I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>>>
>>> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>>>
>>>> I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>>>
>>> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>>>
>>>> Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>>>
>>> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220104/db180a35/attachment-0001.html>