[bitcoin-dev] Default Signet, Custom Signets and Resetting Testnet
Hi all Signet has been announced and discussed previously on the mailing list so I won't repeat what Signet is and its motivation. (For more background we recently had a Socratic Seminar with Kalle Alm and AJ Towns on Signet. Transcript, reading list and video are available.) https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-08-19-socratic-seminar-signet/ The first (of multiple) Signet PR 18267 in Bitcoin Core is at an advanced stage of review and certainly additional code review and testing of that PR is encouraged. https://github.com/bitcoin/bitcoin/pull/18267 However there are some meta questions around Signet(s) that are best discussed outside of the Bitcoin Core repo and it would be good to ensure everyone's testing needs are being met. I will put forward my initial thoughts on some of these questions. These thoughts seem to be aligned with Kalle's and AJ's initial views but they have not reviewed this post and they can chime in if they feel I am misrepresenting their perspectives. 1) Should there be one "default" Signet that we use for specific purpose(s) or should we "let a thousand ships sail"? To be clear there will be multiple custom Signets. Even if we wanted to prevent them we couldn't. But is there an argument for having a "default" Signet with a network effect? A Signet that a large proportion of the community is drawn to using with tooling and support? I would say yes. Especially if we see Signet as a staging ground for testing proposed soft fork(s). Otherwise there will be lots of splintered Signet networks all with different combinations of proposed soft forks enabled and no network effect around a particular Signet. I think this would be bewildering for say Taproot testers to have to choose between Person A's Signet with Taproot enabled and Person B's Signet with Taproot enabled. For this to work there would have to be a formal understanding of at what stage a proposed soft fork should be enabled on "default" Signet. It would have to be at a sufficiently mature stage (e.g. BIP number allocated, BIP drafted and under review, PR open in Bitcoin Core repo under review etc) but early enough so that it can be tested on Signet well in advance of being considered for activation on mainnet. This does present challenges if soft forks are enabled on Signet and then change/get updated. However there are approaches that AJ in particular is working on to deal with this, one of which I have described below. https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining 2) Assuming there is a "default" Signet how many people and who should have keys to sign each new "default" Signet block? If one of these keys is lost or stolen should we reset Signet? Should we plan to reset "default" Signet at regular intervals anyway (say every two years)? Currently it is a 1-of-2 multisig with Kalle Alm and AJ Towns having keys. It was suggested on IRC that there should be at least one additional key present in the EU/US timezone so blocks can continue to be mined during an Asia-Pacific outage. (Kalle and AJ are both in the Asia-Pacific region). Kalle believes we should keep Signet running indefinitely unless we encounter specific problems and personally I think this makes sense. https://github.com/bitcoin/bitcoin/issues/19787#issuecomment-679160691 3) Kalle has also experienced concern from some in the community that testnet will somehow be replaced by Signet. This is not the case. As long as someone out there is mining testnet blocks testnet will continue. However, there is the question of whether testnet needs to be reset. It was last reset in 2012 and there are differing accounts on whether this is presenting a problem for users of testnet. Assuming Signet is successful there will be less testing on testnet but what testing use cases will still prefer testnet? It has been argued that testnet should be a large chain to stress test certain IBD, P2P scenarios in which case it may be the case that we don't want to reset testnet. All other testing use cases would not be impacted by the downsides of a large chain as they would gravitate towards Signet regardless. https://bitcoin.stackexchange.com/questions/98579/will-there-be-a-testnet4-or-do-we-not-need-a-testnet-reset-once-we-have-signet/ If you have thoughts, feedback, questions it would be great to hear them. Certainly we should seek to make sure everybody's testing needs are being considered. There is a closed issue on the Bitcoin Core repo if you seek to review some of the prior conversation. Ideally though we would have discussion that isn't directly impacting Bitcoin Core here on the mailing list or on IRC rather than in the Bitcoin Core repo. https://github.com/bitcoin/bitcoin/issues/19787 Thanks Michael -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
[bitcoin-dev] Taproot activation meeting on IRC - Tuesday 2nd February 19:00 UTC
There has been an incredible community effort to make progress towards consensus on an activation method for the proposed Taproot soft fork. Special mentions go to David Harding, AJ Towns, Aaron van Wirdum, Jonathan Bier, Ben Carman, Alejandro De La Torre whose resources are linked below but there have been many others, too many to name, who have all made an impact on moving the needle in recent months. Taproot activation proposals: https://en.bitcoin.it/wiki/Taproot_activation_proposals Activating Soft Forks in Bitcoin: http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin BIP 8, BIP 9 or Modern Soft Fork Activation: How Bitcoin Could Upgrade Next: https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next Bitcoin Softfork Activation Methodology: https://blog.bitmex.com/bitcoin-softfork-activation-methodology/ Activating Taproot: https://suredbits.com/activating-taproot/ Taproot activation website: https://taprootactivation.com/ In an effort to get this closer to the finish line we are organizing a meeting on IRC on the ##taproot-activation channel on Tuesday 2nd February at 19:00 UTC. The primary objective will be to finalize the revised BIP 8 activation method but general questions or discussion on Taproot activation are welcome too. There is lots of prior context so please do sufficient pre-reading in advance of attending if you would like to participate. The relevant pull requests relating to revised BIP 8 are: Replace unused BIP 9 logic with draft BIP 8 (Bitcoin Core PR) https://github.com/bitcoin/bitcoin/pull/19573 BIP 8: Make signalling during LOCKED_IN recommended rather than mandatory (BIP PR) https://github.com/bitcoin/bips/pull/1020 BIP 8: allow some MUST_SIGNAL blocks to not signal (BIP PR) https://github.com/bitcoin/bips/pull/1021 Feel free to post comments or questions at any time on the ##taproot-activation channel IRC in advance or following the meeting. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Yesterday's Taproot activation meeting on IRC
Yesterday (February 2nd) we held a relatively unstructured meeting on Taproot activation on IRC which was open to all. The conversation log is here: http://gnusha.org/taproot-activation/2021-02-02.log The meeting was previously announced here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html I will summarize what was discussed as best I can. Please revert to the conversation log if you have the time as any summary is going to be imperfect. Any errors or biases are my own and corrections will be gratefully accepted. I’ll start with Rusty Russell’s takeaways (many thanks to our Asia Pacific representatives for joining in the middle of the night by the way) on Mastodon: 1. Unanimous support for BIP 8. RIP BIP 9. 2. Overwhelming consensus that 1 year is the correct timeout value (it’s actually defined in blocks, so 26x2016 or maybe 87600). 3. Majority consensus for lockinontimeout false, though Luke Dashjr strongly opposed. 4. No decision I could see on start time, but 2 months was done for SegWit and that didn’t seem too objectionable. https://bitcoinhackers.org/@rusty/105664386728806153 I personally think this is a solid summary though I do want to point out it wasn’t only Luke that opposed lockinontimeout=false. There were other individuals who also opposed lockinontimeout=false but at least from my reading that was the minority opinion. Luke concluded there wasn’t clear consensus on it and that even if lockinontimeout=false was eventually chosen as a Bitcoin Core default he would be running lockinontimeout=true on his node. In terms of the PRs, the following BIP 8 PRs were merged following the meeting. https://github.com/bitcoin/bips/pull/1020 https://github.com/bitcoin/bips/pull/1021 The latter was merged due to an observation from Jonas Nick in the PR comments and during the meeting that without it nodes could end up on the wrong chain in a scenario where they run lockinontimeout=true with most nodes running lockinontimeout=false. The Bitcoin Core PR #19573 requires additional work from its author and further review before it can be considered for merging. I do want to thank the large number of participants for engaging in the discussion in the spirit of wanting to make progress on Taproot activation and for gracefully allowing me to interrupt them and keep the discussion on topic. The vast majority of the time this level of bluntness (and pushing away slightly off topic questions) is not desired or required in Bitcoin technical meetings. I hope those who were interrupted during this meeting will return and ask their questions now a meeting of that sheer size is over. We are in the process of attempting to organize a follow up more closely following the format of John Newbery’s Bitcoin Core PR review club which will be lower level, technical and focused on the Bitcoin Core PR #19573. The Bitcoin Core PR review club is also open to all but given its more technical nature it shouldn’t present the same challenges as yesterday’s meeting. Thanks to Alejandro De La Torre for providing an update on his website ( taprootactivation.com) following the meeting. Chun Wang (co-founder of F2Pool, ~ 16 percent of global hash rate) has decided to support BIP 8(false,1 year). -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC
A summary of the first Taproot activation meeting (February 3rd) is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html It appears there is one (hopefully) last stumbling block before we are ready to propose Taproot activation parameters to the mailing list. Hence we are organizing a follow up meeting on IRC on the ##taproot-activation channel on Tuesday 16th February at 19:00 UTC. As I said in the summary of the first Taproot activation meeting whether lockinontimeout (LOT) is set to true or false in a Bitcoin Core release attracted discussion during the meeting and has continued to attract discussion afterwards. I will weigh up the arguments I have seen for both true and false here. I won’t comment on the strength of the arguments, merely attempt to summarize them. Any errors are my own. Arguments for setting lockinontimeout (LOT) to true in a Core release T1) This entirely eradicates the possibility (however unlikely) that Taproot fails to activate within a year. Although approximately 90 percent of mining pools have already pledged to activate Taproot there is no reason to open the door to possible delays and political shenanigans for no reason, however unlikely. T2) Given users can change LOT=true at any point (and some have declared they will be setting LOT=true regardless), setting LOT=false in Core opens up edge case scenarios where different proportions of users on the network change to LOT=true at different points in time in an uncoordinated fashion. Given the end state we all want is Taproot activated it doesn’t make sense to open the door to these edge cases. Setting LOT=true in Core would mean there is no motivation for users to change LOT in the software they are running. T3) We should not be putting users in a place where they feel they need to change LOT. The urge to change LOT will be strong if miners delay for an unreasonable period. We are then in a situation where a decision has to be made on whether Core releases a new version with LOT=true and this whole discussion kicks off again. We should definitely seek to avoid the need to rehash this discussion later in the year. T4) LOT is only relevant if miners fail to activate. It doesn’t make sense to set it to false as that is essentially saying if miners fail to activate early, LOT should also let them not activate. T5) Activation should only be attempted once community consensus for the soft fork has been reached. Miner signaling is not voting for the changes, it is signaling readiness. There is no reasonable rationale for not being ready within a year. T6) An argument belcher outlined on IRC. If LOT was set to true and a chain split happened then the Taproot chain doesn’t have wipeout risk so there’s a really strong incentive to be on the Taproot activating LOT=true chain and therefore using LOT=true means the risk of a chain split is actually lower. Arguments for setting lockinontimeout (LOT) to false in a Core release F1) The probability of Taproot not being activated by miners is small. This is not 2017, this is not SegWit, there is no need to worry. F2) The worst case scenario is we have to wait over a year for Taproot to be activated. Even the worst case scenario is not a disaster. F3) If in the unlikely scenario miners did not activate Taproot for a year for no apparent reason we would never set LOT to false again for any potential future soft fork. If miners fail to activate Taproot despite pledging support and there being overwhelming community consensus for it, it would set a precedent that miners cannot be relied upon *at all* to activate soft forks. F4) If in the highly unlikely scenario that a bug or some problem with the Taproot implementation was found during the signaling period miners could choose not to activate it which is cleaner than needing an emergency Core release. Then some additional arguments nullc posted on Reddit https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/ F5) LOT = false is more similar to what was done previously (unless you go way back to the earliest soft forks which were more similar to LOT = true) F6) It is more important that no rules that harm users are deployed than it is that new useful rules are deployed quickly. If there is a choice between “faster” and “more clear that this isn’t a mechanism to force bad things on users” we should prefer the latter. Plenty of people just don’t like LOT=true very much absent evidence that miners are blocking deployment. To some it just feels needlessly antagonistic and distrusting towards part of our community. There are some additional parameters other than LOT we will discuss in this meeting such as activation threshold, start time etc but personally I don’t think they will attract the same discussion as LOT. As I’ve stated before please continue to engage productively and in good faith. I can see arguments with merit on both sides of t
[bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Yesterday (February 16th) we held a second meeting on Taproot activation on IRC which again was open to all. Despite what appeared to be majority support for LOT=false over LOT=true in the first meeting I (and others) thought the arguments had not been explored in depth and that we should have a follow up meeting almost entirely focused on whether LOT (lockinontimeout) should be set to true or false. The meeting was announced here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html In that mailing list post I outlined the arguments for LOT=true (T1 to T6) and arguments for LOT=false (F1 to F6) in their strongest form I could. David Harding responded with an additional argument for LOT=false (F7) here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html These meetings are very challenging given they are open to all, you don’t know who will attend and you don’t know most people’s views in advance. I tried to give time for both the LOT=true arguments and the LOT=false arguments to be discussed as I knew there was support for both. We only tried evaluating which had more support and which had more strong opposition towards the end of the meeting. The conversation log is here: http://gnusha.org/taproot-activation/2021-02-16.log (If you are so inclined you can watch a video of the meeting here. Thanks to the YouTube account “Bitcoin” for setting up the livestream: https://www.youtube.com/watch?v=vpl5q1ovMLM) A summary of the meeting was provided by Luke Dashjr on Mastodon here: https://bitcoinhackers.org/@lukedashjr/105742918779234566 Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we did manage to come to consensus on everything but LockinOnTimeout. Activation height range: 693504-745920 MASF threshold: 1815/2016 blocks (90%) Keep in mind only ~100 people showed for the meetings, hardly representative of the entire community. So, these details remain JUST a proposal for now. It seems inevitable that there won't be consensus on LOT. Everyone will have to choose for himself. :/ Personally I agree with most of this. I agree that there wasn’t overwhelming consensus for either LOT=true or LOT=false. However, from my perspective there was clearly more strong opposition (what would usually be deemed a NACK in Bitcoin Core review terminology) from Bitcoin Core contributors, Lightning developers and other community members against LOT=true than there was for LOT=false. Andrew Chow tried to summarize views from the meeting in this analysis: https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c I am also aware of other current and previous Bitcoin Core contributors and Lightning developers who didn’t attend the meeting in person who are opposed to LOT=true. I don’t want to put them in the spotlight for no reason but if you go through the conversation logs of not only the meeting but the weeks of discussion prior to this meeting you will see their views evaluated on the ##taproot-activation channel. In addition, on taprootactivation.com some mining pools expressed a preference for lot=false though I don’t know how strong that preference was. I am only one voice but it is my current assessment that if we are to attempt to finalize Taproot activation parameters and propose them to the community at this time our only option is to propose LOT=false. Any further delay appears to me counterproductive in our collective aim to get the Taproot soft fork activated as early as possible. Obviously others are free to disagree with that assessment and continue discussions but personally I will be attempting to avoid those discussions unless prominent new information comes to light or various specific individuals change their minds. Next week we are planning a code review of the Bitcoin Core PR #19573 which was initially delayed because of this LOT discussion. As I’ve said previously that will be loosely following the format of the Bitcoin Core PR review club and will be lower level and more technical. That is planned for Tuesday February 23rd at 19:00 UTC on the IRC channel ##taproot-activation. Thanks to the meeting participants (and those who joined the discussion on the channel prior and post the meeting) for engaging productively and in good faith. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
e humble about what users must or > must not run. > > Does no one realize that it is a very possible outcome that if LOT=true is > released there may be only a handful of people that begin running it while > everyone else delays their upgrade (with the very good reason of not > getting involved in politics) and a year later those handful of people just > become stuck at the moment of MUST_SIGNAL, unable to mine new blocks? Or > attracting a minority of miners, activating, and forking off into a > minority fork. Then a lot=false could be started that ends up activating > the feature now that the stubborn option has ran its course. > The result: a wasted year of waiting and a minority of people who didn't > want to be lenient with miners by default. The chains could be called > BitcoinLenient and BitcoinStubborn. > How is that strictly safer or more coordinated? > > I may be in the minority, or maybe a silent majority, or maybe a majority > that just hasn't considered this as a choice but honestly if there is > contention about whether we're going to be stubborn or lenient with miners > for Taproot and in the future then I prefer to just not activate anything > at all. I'm fine for calling bitcoin ossified, accepting that segwit is > Bitcoin's last network upgrade. Taproot is amazing but no new feature is > worth a network split down the middle. > > Maybe in 10 or 20 years, when other blockchains implement features like > Taproot and many more, we will become envious enough to put aside our > differences on how to behave towards miners and finally activate Taproot. > > An activation mechanism is a consensus change like any other change, can > be contentious like any other change, and we must resolve it like any other > change. Otherwise we risk arriving at the darkest timeline. > > Cheers > Ariel Lorenzo-Luaces > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> Yesterday (February 16th) we held a second meeting on Taproot >> activation on IRC which again was open to all. Despite what appeared >> to be majority support for LOT=false over LOT=true in the first >> meeting I (and others) thought the arguments had not been explored in >> depth and that we should have a follow up meeting almost entirely >> focused on whether LOT (lockinontimeout) should be set to true or >> false. >> >> The meeting was announced here: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html >> >> In that mailing list post I outlined the arguments for LOT=true (T1 to >> T6) and arguments for LOT=false (F1 to F6) in their strongest form I >> could. David Harding responded with an additional argument for >> LOT=false (F7) here: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html >> >> These meetings are very challenging given they are open to all, you >> don’t know who will attend and you don’t know most people’s views in >> advance. I tried to give time for both the LOT=true arguments and the >> LOT=false arguments to be discussed as I knew there was support for >> both. We only tried evaluating which had more support and which had >> more strong opposition towards the end of the meeting. >> >> The conversation log is here: >> http://gnusha.org/taproot-activation/2021-02-16.log >> >> (If you are so inclined you can watch a video of the meeting here. >> Thanks to the YouTube account “Bitcoin” for setting up the livestream: >> https://www.youtube.com/watch?v=vpl5q1ovMLM) >> >> A summary of the meeting was provided by Luke Dashjr on Mastodon here: >> https://bitcoinhackers.org/@lukedashjr/105742918779234566 >> >> Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we >> did manage to come to consensus on everything but LockinOnTimeout. >> >> Activation height range: 693504-745920 >> >> MASF threshold: 1815/2016 blocks (90%) >> >> Keep in mind only ~100 people showed for the meetings, hardly >> representative of the entire community. >> >> So, these details remain JUST a proposal for now. >> >> It seems inevitable that there won't be consensus on LOT. >> >> Everyone will have to choose for himself. :/ >> >> Personally I agree with most of this. I agree that there wasn’t >> overwhelming consensus for either LOT=true or LOT=false. However, from >> my perspective there was clearly more strong opposition (what would >> usually be deemed a NACK in Bitcoin Core review terminology) from >> Bitcoin Core contributors, Lightni
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think users should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core. My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots. On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj wrote: > Good morning all, > > > "An activation mechanism is a consensus change like any other change, > can be contentious like any other change, and we must resolve it like any > other change. Otherwise we risk arriving at the darkest timeline." > > > > Who's we here? > > > > Release both and let the network decide. > > A thing that could be done, without mandating either LOT=true or > LOT=false, would be to have a release that requires a `taprootlot=1` or > `taprootlot=0` and refuses to start if the parameter is not set. > > This assures everyone that neither choice is being forced on users, and > instead what is being forced on users, is for users to make that choice > themselves. > > Regards, > ZmnSCPxj > > > > > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > Thanks for your response Ariel. It would be useful if you responded to > specific points I have made in the mailing list post or at least quote > these ephemeral "people" you speak of. I don't know if you're responding to > conversation on the IRC channel or on social media etc. > > > > > > > The argument comes from a naive assumption that users MUST upgrade > to the choice that is submitted into code. But in fact this isn't true and > some voices in this discussion need to be more humble about what users must > or must not run. > > > > > > I personally have never made this assumption. Of course users aren't > forced to run any particular software version, quite the opposite. Defaults > set in software versions matter though as many users won't change them. > > > > > > > Does no one realize that it is a very possible outcome that if > LOT=true is released there may be only a handful of people that begin > running it while everyone else delays their upgrade (with the very good > reason of not getting involved in politics) and a year later those handful > of people just become stuck at the moment of MUST_SIGNAL, unable to mine > new blocks? > > > > > > It is a possible outcome but the likely outcome is that miners > activate Taproot before LOT is even relevant. I think it is prudent to > prepare for the unlikely but possible outcome that miners fail to activate > and hence have this discussion now rather than be unprepared for that > eventuality. If LOT is set to false in a software release there is the > possibility (T2 in > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html) > of individuals or a proportion of the community changing LOT to true. In > that sense setting LOT=false in a software release appears to be no more > safe than LOT=true. > > > > > > > The result: a wasted year of waiting and a minority of people who > didn't want to be lenient with miners by default. > > > > > > There is the (unlikely but possible) possibility of a wasted year if > LOT is set to false and miners fail to activate. I'm not convinced by this > perception that LOT=true is antagonistic to miners. I actually think it > offers them clarity on what will happen over a year time period and removes > the need for coordinated or uncoordinated community UASF efforts on top of > LOT=false. > > > > > > > An activation mechanism is a consensus change like any other change, > can be contentious like any other change, and we must resolve it like any > other change. Otherwise we risk arriving at the darkest timeline. > > > > > > I don't know what you are recommending here to avoid "this darkest > timeline". Open discussions have occurred and are continuing and in my > mailing list post that you responded to **I recommended we propose > LOT=false be set in protocol implementations such as Bitcoin Core**. I do > think this apocalyptic language isn't particularly helpful. In an open > consensus system discussion is healthy, we should prepare for bad or worst > case scenarios in advance and doing so is not antagonistic or destructive. > Mining poo
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft forks, all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot. You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades such as Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain splits I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever again on this mailing list that wouldn't stop soft fork attempts from other people in future. I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point though I'm open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to (though admittedly you have a much better understanding than me of what happened in 2017). The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and wouldn't kill Bitcoin long term. On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo wrote: > If the eventual outcome is that different implementations (that have > material *transaction processing* userbases, and I’m not sure to what > extent that’s true with Knots) ship different consensus rules, we should > stop here and not activate Taproot. Seriously. > > Bitcoin is a consensus system. The absolute worst outcome at all possible > is to have it fall out of consensus. > > Matt > > On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Right, that is one option. Personally I would prefer a Bitcoin Core > release sets LOT=false (based on what I have heard from Bitcoin Core > contributors) and a community effort releases a version with LOT=true. I > don't think users should be forced to choose something they may have no > context on before they are allowed to use Bitcoin Core. > > My current understanding is that roasbeef is planning to set LOT=false on > btcd (an alternative protocol implementation to Bitcoin Core) and Luke > Dashjr hasn't yet decided on Bitcoin Knots. > > > > On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj wrote: > >> Good morning all, >> >> > "An activation mechanism is a consensus change like any other change, >> can be contentious like any other change, and we must resolve it like any >> other change. Otherwise we risk arriving at the darkest timeline." >> > >> > Who's we here? >> > >> > Release both and let the network decide. >> >> A thing that could be done, without mandating either LOT=true or >> LOT=false, would be to have a release that requires a `taprootlot=1` or >> `taprootlot=0` and refuses to start if the parameter is not set. >> >> This assures everyone that neither choice is being forced on users, and >> instead what is being forced on users, is for users to make that choice >> themselves. >> >> Regards, >> ZmnSCPxj >> >> > >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> > > Thanks for your response Ariel. It would be useful if you responded >> to specific points I have made in the mailing list post or at least quote >> these ephemeral "people" you speak of. I don't know if you're responding to >> conversation on the IRC channel or on social media etc. >> > > >> > > > The argument comes from a naive assumption that users MUST upgrade >> to the choice that is submitted into code. But in fact this isn't true and >> some voices in this discussion need to be more humble about what users must >> or must not run. >> > > >> > > I personally have never made this assumption. Of course users aren't >> forced to run any particular software version, quite the opposite. Defaults >> set in software versions matter though as many users won't change them. >> > > >> > > > Does no one realize that it is a very possible outcome that if >> LOT=true is released there may be only a handful of people that begin >> running it while everyone else delays their upgrade (with the very good >> reason of not getting involved in politics) and a year later those handful >> of people just become stuck at the moment of MUST_SIGNAL, unable to mine >> n
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
> getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an exchange losing millions would be worse than having Taproot is good. We are at the point where an upgrade that confers significant long term benefits for the whole ecosystem is not as important as bad short term PR? That is a depressing outlook if that is what you believe. Even in that worst case scenario exchanges should not lose money if they are competent and are able to manage that risk. On Thu, Feb 18, 2021 at 2:42 PM Matt Corallo wrote: > We've had several softforks in Bitcoin which, through the course of their > activation, had a several-block reorg. That > should be indication enough that we need to very carefully consider > activation to ensure we reduce the risk of that as > much as absolutely possible. Again, while I think Taproot is a huge > improvement and am looking forward to being able to > use it, getting unlucky and hitting a 4-block reorg that happens to > include a double-spend and some PR around an > exchange losing millions would be worse than having Taproot is good. > > Matt > > On 2/18/21 09:26, Michael Folkson wrote: > > Thanks for your response Matt. It is a fair challenge. There is always > going to be an element of risk with soft forks, > > all we can do is attempt to minimize that risk. I would argue that risk > has been minimized for Taproot. > > > > You know (better than I do in fact) that Bitcoin (and layers built on > top of it) greatly benefit from upgrades such as > > Taproot. To say we shouldn't do Taproot or any future soft forks because > there is a small but real risk of chain splits > > I think is shortsighted. Indeed I think even if we collectively decided > not to do any future soft fork upgrades ever > > again on this mailing list that wouldn't stop soft fork attempts from > other people in future. > > > > I don't think there is anything else we can do to minimize that risk for > the Taproot soft fork at this point though I'm > > open to ideas. To reiterate that risk will never be zero. I don't think > I see Bitcoin as fragile as you seem to (though > > admittedly you have a much better understanding than me of what happened > in 2017). > > > > The likely scenario for the Taproot soft fork is LOT turns out to be > entirely irrelevant and miners activate Taproot > > before it becomes relevant. And even the unlikely worst case scenario > would only cause short term disruption and > > wouldn't kill Bitcoin long term. > > > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <mailto:lf-li...@mattcorallo.com>> wrote: > > > > If the eventual outcome is that different implementations (that have > material *transaction processing* userbases, > > and I’m not sure to what extent that’s true with Knots) ship > different consensus rules, we should stop here and not > > activate Taproot. Seriously. > > > > Bitcoin is a consensus system. The absolute worst outcome at all > possible is to have it fall out of consensus. > > > > Matt > > > >> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org > >> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > >> > >> > >> Right, that is one option. Personally I would prefer a Bitcoin Core > release sets LOT=false (based on what I have > >> heard from Bitcoin Core contributors) and a community effort > releases a version with LOT=true. I don't think users > >> should be forced to choose something they may have no context on > before they are allowed to use Bitcoin Core. > >> > >> My current understanding is that roasbeef is planning to set > LOT=false on btcd (an alternative protocol > >> implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided > on Bitcoin Knots. > >> > >> > >> > >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <mailto:zmnsc...@protonmail.com>> wrote: > >> > >> Good morning all, > >> > >> > "An activation mechanism is a consensus change like any other > change, can be contentious like any other > >> change, and we must resolve it like any other change. Otherwise > we risk arriving at the darkest timeline." > >> > > >> > Who's we here? > >> > > >> > Release both and let the network decide. > >> > >> A thing that could be done, w
[bitcoin-dev] Taproot activation facts on lockinontimeout (LOT)
I just want to lay out some facts as I see them because frankly I feel any personal opinion is irrelevant at this point and without agreement on facts we are going round in circles. I end with a personal opinion which you can feel free to ignore. 1) There is a long list of current and past Core contributors who have said they effectively NACK setting a default of lot=true in Core. There are a small number of current and past Core contributors who have said they effectively NACK setting a default of lot=false in Core. If Core sets a default (barring an incredible transformation in views) the only default that is possible at this stage is lot=false. 2) Core forcing users to choose lot=true or lot=false before they can use the software is not viable, nor is it a good idea. This suggestion was withdrawn by ZmnSCPxj. 3) There has been an idea floated (by Rusty and Greg amongst others) of setting a config option such that users could (easily or with greater difficulty) change the default set in Core to their preferred option. Nobody as far as I'm aware is coding this up and intending to open a PR to do this currently. Bitcoin Core pull requests are open to anybody and this may change. 4) There is a non-Core project (https://github.com/BitcoinActivation/bitcoin) that plans to release lot=true as a default. If this is coded up and anyone runs this software there will be lot=true nodes on the network regardless of what Core does. 5) Core could (in theory) not release any activation code, either because there is no consensus on the lot default or out of concern for a (possible but unlikely) chain split if miners failed to activate for a year. If Core chooses to not release anything Taproot will only activate if users and miners run non-Core software. **Personal opinion (feel free to ignore)** Assuming these facts (feel free to correct me if you think any of the above aren't facts) I will put forward a personal opinion. Core releasing nothing and putting all users (including miners) in a position where the only way they can activate Taproot is to run non-Core software seems to me to be highly suboptimal. I do appreciate that if Core releases a default of lot=false that there is a small but non-zero risk of a chain split *if and only if* miners fail to activate within a year. Soft forks are not 100 percent risk free. If the community's appetite for risk and disruption is literally zero we should not attempt to activate Taproot. I would argue the long term benefits for the ecosystem of Taproot *significantly* outweigh that non-zero downside risk. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] UASF (LOT=true) kick off meeting - Tuesday March 2nd 19:00 UTC on ##uasf IRC channel
It is approximately 8 months since Steve Lee formally kicked off the Taproot activation discussion by setting up the ##taproot-activation IRC channel. Obviously there was discussion that considerably predates that but that was the first recognition that there needed to be a focus towards a solution rather than endless circular debates. Eight months on it appears there are some who think there is a philosopher’s stone still out there that will garner 100 percent consensus and contain zero chain split risk in the worst case scenario. A philosopher’s stone that us mere mortals have failed to find in these 8 months. While I would be delighted if this philosopher’s stone is found (and all are free to continue looking) I think it is prudent at this point to step away from the circular arguments and build on the progress we have made in these last 8 months. We have effectively achieved overwhelming consensus on the activation mechanism (BIP 8) and all of the parameters apart from one (lockinontimeout or LOT). Again I’d like to thank the people who have put hours of work into getting to this point. It is thankless work and it is probably the last thing any of us want to be doing. At this point it is unclear whether Bitcoin Core will be able to release any activation code whatsoever due to disagreement logjams. Personally I hope they do but again it is prudent to prepare for the scenario where Core is unable to. Hence I and others have assessed that our energies are better spent working on a community release implementing LOT=true in a similar spirit to 2017’s UASF effort. I say similar as this time there really is no need for any antagonism. Approximately 90 percent of mining pools (taprootactivation.com) have declared support and there is overwhelming community consensus to activate Taproot. In the absence of a Core release with activation code I hope and expect all users (including miners) to consider supporting this UASF release and consider running it to activate Taproot. TL;DR Tomorrow (Tuesday) we are holding a kick off meeting for this UASF (LOT=true) effort on the ##uasf IRC channel at 19:00 UTC. Please consider attending and supporting this effort to get Taproot activated. It would be great to get users from the 2017 effort involved in addition to recent Taproot proponents from all parts of our community. The future of Bitcoin’s scalability and privacy depends on, as it always has, on you the user. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting
Yesterday we held a UASF (LOT=true) kick off meeting on the ##uasf IRC channel. The conversation log is here: http://gnusha.org/uasf/2021-03-02.log It was announced (at short notice admittedly) here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html It is clear frustration is building but it is also clear that this isn’t a conducive environment for development and review. The high level activation discussion has been done to death. Barring a miracle the only thing Core will ship is BIP 8 (1 year, LOT=false). The alternative appears Core ships nothing. At this point in time it also appears the greatest risk to Taproot dying a slow death is a small group of developers who think talking in conservative tones and talking about endless philosophy makes Bitcoin a conservative system. (It doesn’t, it just makes it a dying, decaying one). We have a trillion dollar industry (all signed up to this upgrade) wasting time monitoring these arguments rather than preparing for an upgrade and preparing for the small but manageable risks that any such upgrade entails later in the year. Development projects on hold because there is no end in sight for Taproot activation. We need to give miners and users the ability to activate this year (2021). If we fail to do that through whatever means (Core, UASF release) etc I personally will assume Taproot will never activate. I will also assume Bitcoin is not a project for the incredibly able people who have designed and shipped a complex upgrade (Taproot) that miraculously has overwhelming consensus amongst the entire community. Failing to ship activation code (a very small code change in comparison) is a joke. We need to get this done this year. A UASF (LOT=true) project needs to be ready to assemble just like it was in 2017 to make sure a small group of individuals don’t block progress. But Core also needs to be given the opportunity to ship a BIP 8(1 year, LOT=false) activation that can be used to activate this year that is as well reviewed and well tested as any other Core consensus code change. Once things have calmed down I think we should revisit what progress has been made and take it from there. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Yesterday’s UASF (LOT=true) kick off meeting
Hi Ariel > I think Bitcoin is fine staying as is until that minority forks off with their own alt-node A quick UASF fork allows for an early LOT=false activation. I think you misunderstand BIP 8 (LOT=true). Although no timetable has been finalized as of yet (and hence we are in the realm of speculation rather than facts), the earliest the MUST_SIGNAL period would kick in is around July 2022. That doesn't sound very quick to me if you seek a LOT=false release after a LOT=true release has failed to activate. > The current risk to taproot and all future activations is a loud minority of users who are threatening to co-opt a LOT=false activation by switching the parameter As I've said in previous emails to this list, some people are determined to ignore the discussion and (open to all) meetings of recent weeks and block progress until they find their philosopher's stone. They seek to ignore all the work people have done laying out the options, communicating those options to the community and narrowing them down. Instead they bring up alternative proposals which were discussed and rejected weeks or months ago. With this mindset we'll still be arguing about Taproot activation in 2030. I get that there isn't overwhelming consensus on the LOT parameter, this is a fact. But there won't be overwhelming consensus on any activation mechanism, that has become clear. I am of the view that consensus on one parameter of an activation mechanism does not need to be as high as it is on the actual soft fork that is being activated (which does have overwhelming consensus). And of course if and when a LOT=true (UASF) version is released you are absolutely free not to run it. I hope (and suspect) you would reconsider if July 2022 (or later) was approaching and it was the only way to activate Taproot. Thanks Michael On Thu, Mar 4, 2021 at 2:18 AM Ariel Luaces wrote: > On Wed, Mar 3, 2021 at 12:25 PM Michael Folkson via bitcoin-dev > wrote: > > > > At this point in time it also appears the greatest risk to Taproot > > dying a slow death is a small group of developers who think talking in > > conservative tones and talking about endless philosophy makes Bitcoin > > a conservative system. (It doesn’t, it just makes it a dying, decaying > > one). > > The current risk to taproot and all future activations is a loud > minority of users who are threatening to co-opt a LOT=false activation > by switching the parameter and organizing a marketing blitz that could > end in a fork if things don't go well. > As long as that threat persists consensus won't be reached. Then an > activation client probably won't be released because I don't expect > many devs will have an appetite for writing code that either doesn't > have consensus or code that will be manipulated into creating > consensus conflicts. > I think Bitcoin is fine staying as is until that minority forks off > with their own alt-node. If the UASF minority is dead set on creating > the alt-node then I only hope it's released quickly so the deadlock > can break. A quick UASF fork allows for an early LOT=false activation. > > Cheers > Ariel Lorenzo-Luaces > > > -- > > Michael Folkson > > Email: michaelfolk...@gmail.com > > Keybase: michaelfolkson > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
Hi Matt > I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split the network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make a lot of noise around such an effort, given BIP 148 was organized and reached its peak within a similar such window. I'm not sure either. I can't control anyone other than myself. I think (and Luke has also stated on IRC) that trying a UASF (LOT=true) during a "Speedy Trial" deployment would be crazy. I would certainly recommend no one tries that but I can't stop anyone. I'll repeat that soft forks have and always will contain some limited chain split risk regardless of activation mechanism. I think you are well intentioned but I'm not sure if you've fully grasped that yet. Maybe you have and I'm missing something. > Worse, because the obvious alternative after a three month activation failure is a significant delay prior to activation, the vocal UASF minority may be encouraged to pursue such a route to avoid such a delay. Again I can only speak for myself but I wouldn't support a UASF until this "fail fast" Speedy Trial has completed and failed. Luke agrees with that and other people (eg proofofkeags) on the ##uasf IRC channel have also supported this "Speedy Trial" proposal. If you want me (or anyone else for that matter) to guarantee there won't be an attempted UASF during a Speedy Trial deployment obviously nobody can do that. All I can say is that personally I won't support one. > One alternative may be to reduce the signaling windows involved and start slightly later. Instead of the likelihood of failure growing on the horizon, simply have two signaling windows (maybe two weeks, maybe a moth each?). In order to ensure success remains likely, begin them somewhat later after software release to give pools and miners a chance to configure their mining software in advance. The parameters for Speedy Trial are being hammered out on IRC as we speak. I'd encourage you to engage with those discussions. I'd really like to avoid a scenario where we have broad consensus on the details of Speedy Trial and then you come out the woodwork weeks later with either an alternative proposal or a criticism for how the details of Speedy Trial were finalized. I've read your email as you're concerned about a UASF during a Speedy Trial deployment. Other than that I think (?) you support it and you are free to join the discussion on IRC if you have particular views on parameters. Personally I don't think those parameters should be chosen assuming there will be a UASF during the deployment but you can argue that case on IRC if you wish. All proposals you have personally put forward suffer from chain split risk in the face of a competing incompatible activation mechanism. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Measuring the support (or lack of support) for Speedy Trial
I have set up a document (a gist) to measure the support (or lack of support) for the Speedy Trial activation proposal. Please contribute a ACK or NACK (with a qualification or additional context if necessary) https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f This is not a vote as a vote is easily sybillable. But it does provide some data (especially if GitHub pseudonyms are associated with particular individuals) Personally I welcome any efforts to collect community feedback on this proposal. I do not need to be the only individual doing this nor does this gist need to be the only collection method. This is merely my personal attempt to collect that feedback. Please try your own and report back to this mailing list or to the ##taproot-activation IRC channel. Alternatively please distribute this gist to all online discussion forums that you personally use. Thank you for your help. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"
> I don't think we should have a followup deployment start so close to to timeout of ST. I think it would be better to schedule the followup around ST, especially since the details around that are fuzzier and dependent on the results of ST itself. Until Core pull request(s) are merged I don't think we can finalize startheight (and hence the timeout) for Speedy Trial either. Speedy Trial seems to have the most community consensus of any activation proposal thus far and I'm confident it will at some point in the near future it will be merged into Core. Community feedback: https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f Therefore I think the onus is on any UASF release to fit around a Speedy Trial deployment in Core. I haven't thought enough about what my preference would be assuming activation fails with Speedy Trial re a follow up deployment in Core and/or a UASF release. However, I would be 100 percent opposed to any UASF release that conflicts or is not compatible with a Speedy Trial deployment in Core. On 3/14/21 10:51 PM, Luke Dashjr wrote: > The last period before timeoutheight here overlaps with the current BIP8(True) > deployment plan. So if this period specifically were to reach 90% signalling, > nodes would activate Taproot at height 697536, but ST-only nodes would still > wait until 709632 instead. > > Probably the best solution is to just move this ST window 1 period earlier? > > Luke -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] (Recurring) Taproot activation meeting on IRC - Tuesday 23rd March 19:00 UTC + every fortnight
Thanks for organizing this Jeremy, agenda looks great. I do think we are now at the time where Taproot activation becomes a priority for all those with a stake in Taproot activation. Although these parameters haven't yet been finalized the proposed (approximate) startheight is May 1st which is less than 6 weeks away. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018594.html Therefore I encourage everyone with a stake in Taproot activation to attend this meeting tomorrow (Tuesday 19:00 UTC) and raise any specific concerns with block height vs MTP and proposed timetables as Jeremy suggests before the meeting. Personally I think we should avoid the min activation height dragging into December. November (current proposed is November 13th) seems ideal as to avoid (admittedly Western) holidays in December and January. Other than that I think we have some (limited) wiggle room with regards to the exact timetable to ensure the optimal code is merged. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
Thanks for this Jeremy. I agree with the vast majority of this. For those that missed yesterday's meeting the meeting log is here: http://gnusha.org/taproot-activation/2021-03-23.log Jeremy also livestreamed the meeting on his Twitch channel: https://www.twitch.tv/videos/960346848 On the choice between using block heights consistently or using a weird mix of both block heights and MTP in the same activation mechanism you can put me down for a NACK for the latter also. In addition I documented here the preferences for a consistent use of block height: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 If it was a direct choice between entirely block height or entirely MTP then I probably wouldn't NACK either. But using a mix of both makes no sense to me. The two arguments in favor of using a weird mix of block heights and MTP appear to be: 1) "additional review required to ensure height based activation" 2) To prevent a "marketed push to launch a UASF client." On 1) I would argue that the additional review required is not excessive by any means and we have the time to review a consistent use of block height (especially if people spent their time reviewing a PR with a consistent use of block height rather than arguing for a mix). On 2) if we are making technical decisions based on speculating on the marketing strategies of other projects Bitcoin Core is a very different project to the project I thought it was. I personally would find it much easier to reason about timings and time intervals of the different activation phases if block heights are used consistently across the activation mechanism rather than a weird mix of both block heights and MTP. Other than that, I agree it was an excellent meeting and thanks for your efforts organizing and hosting the meeting. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
> Your response strikes me as ingenuine with regards to "other projects" as it > is a project I understand you to be one of the parties spearheading. I think > it's misleading to not clarify that in your response. I support Taproot activation and any project that can help bring that about. As I have said many times I am 100 percent against an incompatible UASF release with a Core ST release. However a UASF project is well within its rights to work around finalized ST parameters in Core to prepare for a possible (but unlikely) failed ST deployment, *especially* in the case that Core is unable to. > As you would ACK either full MTP or full height, but nacking "mixed, seems to > be a fallacy of the excluded middle. I just prefer consistency. If you prefer inconsistency that is your right. Although "I have a preference for fully height based design, correct" is another of your direct quotes from 6 days ago. So NACKing that same approach 6 days later is a touch bizarre. https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191 > I further find your logic around point 2, 'To prevent a "marketed push to > launch a UASF client."', to more aptly apply to ST with height. "marketed push to launch a UASF client" is a direct quote from your email. What marketing has to do with anything I have no idea. As I said in my original response I would prefer not to make technical decisions based on speculation for the marketing strategy of an alternative project. That leads down a very dark road of merging in PRs in response to "world computers" and "Turing completeness" marketing. Thanks Michael On Wed, Mar 24, 2021 at 6:10 PM Jeremy wrote: > > Michael, > > Your response strikes me as ingenuine with regards to "other projects" as it > is a project I understand you to be one of the parties spearheading. I think > it's misleading to not clarify that in your response. > > Your NACK on MTP based ST does not have any merit. The only argument you made > for nacking MTP based ST is it is "weird". "Weird" is not a technical > argument, it's a normative statement. > > As you would ACK either full MTP or full height, but nacking "mixed, seems to > be a fallacy of the excluded middle. > > AJ's note on this where it is technically justified to use MTP w/ min active > height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221, > as such it is not a weird choice at all. In fact, without further patching, > if I understand correctly, you wouldn't want to use pure MTP without > additional logic. > > I further find your logic around point 2, 'To prevent a "marketed push to > launch a UASF client."', to more aptly apply to ST with height. > > > Pushing for height based ST is causing additional review burden on > contributors in service of enabling a fringe group's side project. That is > actually making a technical decision on another project's marketing strategy, > and is precisely why I NACK'd it. > > Even more outrageously, MTP based ST is easily compatible with a height based > BIP8 LOT=true + minactiveheight client, so there really is not a good reason > for the fuss. Note -- in general UASF is not the fringe group here -- it's > the group trying to preempt the release of an ST client with a UASF client > which is the fringe sentiment. > > For you to flip the exact argument that I made for rejecting ST Height onto > ST MTP is no more than a "I know you are but what am I" argument, which I do > not think holds water. > > Best, > > Jeremy > > > > -- > @JeremyRubin > > > On Wed, Mar 24, 2021 at 4:24 AM Michael Folkson > wrote: >> >> Thanks for this Jeremy. I agree with the vast majority of this. >> >> For those that missed yesterday's meeting the meeting log is here: >> http://gnusha.org/taproot-activation/2021-03-23.log >> >> Jeremy also livestreamed the meeting on his Twitch channel: >> https://www.twitch.tv/videos/960346848 >> >> On the choice between using block heights consistently or using a >> weird mix of both block heights and MTP in the same activation >> mechanism you can put me down for a NACK for the latter also. >> >> In addition I documented here the preferences for a consistent use of >> block height: >> https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 >> >> If it was a direct choice between entirely block height or entirely >> MTP then I probably wouldn't NACK either. But using a mix of both >> makes no sense to me. >> >> The two arguments in favor of using a weird mix of block heights and >> MTP appear to be: >> 1) "additional review required to ensure height based activation" >> 2) To prevent a "marketed push to launch a UASF client." >> >> On 1) I would argue that the additional review required is not >> excessive by any means and we have the time to review a consistent use >> of block height (especially if people spent their time reviewing a PR >> with a consistent use of block height rather than arguing for a mix). >> On 2) if we are making
[bitcoin-dev] Announcing a new standard for soft fork activation
There have been a vast number of proposals for soft fork activation in recent months and it is important that all these important ideas don’t go to waste. Hence I propose a new standard for soft fork activation incorporating all the ideas into one standard. I appreciate this standard has come too late for Taproot activation but it should be ready for any future soft forks. It is a multi phase, multi year standard. No soft fork can activate unless and until it has successfully passed through all of the different 14 phases. This will demonstrate Bitcoin’s ultimate conservatism. Phase 1) Let’s See What Happens - BIP 8 (false, 0.25 years). The shortest phase just to whet appetites. Phase 2) Start now, improve later - BIP 8(false, 1 year) A confusing name, it starts but it doesn't improve later Phase 3) BIP 9 equivalent - BIP 8(false, 1 year) Phase 4) Gently discourage apathy - BIP 8(true, 1 year) Forced signaling at the end of this phase but obviously there are still many phases before the soft fork can actually activate. Phase 5) BIP 91 (1 year). As a nod to our SegWit history we have a BIP 91 activation phase. Phase 6) BIP 148 (1 year). Some people disagree that BIP 91 activated SegWit so we do a BIP 148 activation phase to keep those people happy. Again forced signaling doesn’t actually mean activation. There are still many more phases to pass through. Phase 7) Speedy Trial (using block height, 0.5 years) on mainnet Phase 8) Speedy Trial (using MTP, 0.5 years) on mainnet Phase 9) Speedy Trial on the default signet (0.5 years) Phase 10) Speedy Trial on a combination of three different custom signets in parallel (0.5 years) Phase 11) Speedy Trial on testnet and a custom signet in parallel (0.5 years) Phase 12) Modern Soft Fork Activation (3.5 years) This is the longest phase of the soft fork activation standard. It is itself multi phase and multi year so this can be considered a nested activation phase within this standard. Phase 13) UASF BIP 8 (LOT=true, 1 year). Forced miner signaling at the end of this phase but ultimately the soft fork doesn’t yet activate as there is one final additional phase the activation must pass through. This gives Samson the opportunity to sell some hats. We are close now. The natives are getting restless. Phase 14) Second flag day (1 year) We don’t want those pesky users actually activating a soft fork on their own so an additional flag day is added just so we can tell users that we prevented a chain split. Assuming a soft fork activation has successfully passed through all these 14 phases it should activate. It will take a minimum of 13 years. However, if it fails during any one of these phases it has to start from Phase 1 again. We should take Bitcoin’s conservatism very seriously. If a soft fork activation can’t pass successfully through all these phases it shouldn’t activate. Ultimately we don’t really mind what is in the soft fork (any idiot can design consensus changes and write secure bug free C++ code) that is very much secondary in importance to *how* the soft fork is activated. The activation design absolutely must be conservative. I expect this rigorous standard for soft fork activation will get a BIP number. If you are going to propose a future soft fork I recommend you plan for activation in approximately 13 years from the point the soft fork code is merged into Core. I am happy to settle the soft fork activation question once and for all for the community. I expect in time my contribution will be recognized in the annals of history with Satoshi Nakamoto and Hal Finney. Addendum: Although all future soft forks will ultimately use this standard, this standard is copyrighted. Every time it is used royalties must be paid into this quantum secure Bitcoin vanity address 1quantumsecureaddress -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Update on "Speedy" Trial
(The email last week was an April Fools. I did my best to make light of the situation...) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018724.html I'd like to give the list an update on where we are with Speedy Trial because it is just as absurd as it looks to an outside observer. As a reminder of the timeline: February 2nd: Community meeting (100+ attendees including Core contributors) where there was broad consensus that BIP 9 was "dead" in favor of BIP 8. BIP 8 (which uses block heights) was revised to be a BIP 9 replacement. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html March 6th: With no clear community consensus on whether the LOT parameter should be set to true or false in BIP 8, Russell O'Connor proposed "Speedy Trial". Taking an excerpt from David Harding's mailing list post "Speedy Trial is a way to generate fast progress" and can "fail fast". https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html April 6th: There are two open PRs in Bitcoin Core. PR #21377 from AJ Towns which attempts to bring BIP 9 back to life and use MTP over block height because MTP is better for test networks. (Apparently mainnet is a test network for testnet and signet these days) And PR #21392 from Andrew Chow which uses BIP 8 and block height as discussed in those first community meetings. BIP 8 has been revised to incorporate Speedy Trial while BIP 9 hasn't. I think we are fast approaching a time where we are in exactly the same situation as we were with the LOT parameter. Bitcoin Core is unable to merge anything because of limited opposition to using block height of all things. I do encourage everyone to look at this and understand which individuals are making this situation absurd. They will most likely be the same individuals that decry the dangers of a future UASF having made "Speedy" Trial a total oxymoron. I won't be attending the meeting later, I'd rather pull teeth. If people are in agreement with me on no further progress being possible in Core I think we will need to restart the UASF discussions. Luke warned that these kinds of shenanigans could happen but I really lacked imagination on the tricks some people could pull. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
I will continue to update the list on the latest developments as I see them. That's all I can do. So the latest circus act is apparently a technical decision made by a coin toss. The rationale being that this discussion on using block height vs a mix of block height and MTP was bikeshedding all along. Here's a short abridged timeline on the views on block height vs MTP of the organizer (Jeremy Rubin) of that coin toss: March 8th: "I have a preference for fully height based design, correct." https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191 March 24th: "There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against height.” https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html April 6th: "The following folks in the meeting agreed to abide by the flip jeremyrubin" https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018742.html April 7th: "So @achow101 is correct that it is not the coin flip which made the decision." https://github.com/bitcoin/bitcoin/pull/21393#issuecomment-815388126 Please note on March 24th the only person NACKing block height in that meeting was Jeremy Rubin. He has gone from preferring block height, to NACKing block height, to thinking this discussion all along was bikeshedding and worthy of a coin flip to admitting the coin flip was theater. All of this makes me extremely uncomfortable and I dread to think what individuals and businesses all over the world who have plans to utilize and build on Taproot are making of all of this. As an individual I would like to distance myself from this circus. I will try to keep the mailing list informed though of further developments re Speedy Trial in Core or progress on an alternative client. There are two StackExchange answers here on block height vs MTP, one by David Harding and one by myself for those that are interested in the technical considerations. https://bitcoin.stackexchange.com/questions/103854/should-block-height-or-mtp-or-a-mixture-of-both-be-used-in-a-soft-fork-activatio -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
I have no problem with coin tosses to decide for example shed colors (an illustrative example discussed by copumpkin, roasbeef on IRC). In this kind of example everyone should recognize it doesn't matter and Approach ACK two competing PRs. No one should be NACKing or Approach NACKing a PR based on shed color. If the maintainers don't care about the shed color either then they are free to use a coin toss to decide which PR to merge. In this example there shouldn't be any NACKs, Approach NACKs or technical opposition from regular Core reviewers. NACKs are not meant to be used for shed colors. However, in this example the organizer of the coin toss had previously NACKed one of the options (block height, though his position seems to change by the day) and others have NACKed MTP. I think you have consistently said it doesn't matter too much although you did previously express a preference for block height. I don't want to belabor the point but can we avoid even suggesting using coin tosses on consensus code decisions in future please? It makes a mockery of those who spent time understanding the technical considerations and have spent months or years working on soft fork activations. Even in the shed color example, leave it to the maintainers to decide whether a coin toss is appropriate rather than creating a circus around a coin toss in a public meeting where the PR authors weren't present and no Core maintainers were present. I understand the frustration and I understand the desire to break deadlocks. But if the coin toss organizer hadn't previously NACKed one of the options (block height) we may have avoided getting into this deadlock in the first place. Your recent review notes of PR #21377 look great and are proving very helpful to me as I look at the PR. https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40 Thanks Michael On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote: > > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev > wrote: > > So the latest circus act is apparently a technical decision made by a > > coin toss [organized by] Jeremy Rubin > > Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2], > and is the same method I've been using in Bitcoin-related discussions > for over seven years[3] to help people transition from ancillary arguments > back to working on the things they really think are important. > > I proposed the coin toss because I understood that both the MTP and the > height approaches required tradeoffs that were, to a certain degree, > unresolvable to the best of our current knowledge. MTP is harder to > analyze for unexpected edge cases; heights would create extra work for > seasoned developers working on post-taproot soft forks. MTP would > require developers of currently-planned UASF software either do extra > work or wait to release their software; heights don't guarantee a > minimum amount of time for a large number of economic full nodes to > upgrade. > > Different people gave different weights to the different tradeoffs. In > cases like this where there's no known way to eliminate the tradeoffs > and no way to objectively rank them, I think it's better to begin > working on something concrete than it is to try to persuade everyone to > adopt the same subjective ranking of the tradeoffs---or, as the IETF > published in RFC7282: > > "There are times where the result of [an informal open-ended > conversation] is a pretty even split. In practical terms, that > means it doesn't matter where the chair starts the discussion. And > in fact, we've had working groups where a coin flip decided which > proposal to start with. That doesn't mean that the coin flip > determined the outcome; if a fatal technical flaw was found in the > solution that won the coin flip, it is still incumbent upon the > group to address the issue raised or abandon that solution and find > another. Rough consensus on the technical points, in the end, is > always required. Any way to find a place to start, be it the hum or > the coin flip, is only getting to the beginning of the discussion, > not the end." > > As Jeremy wrote, in this occassion, we didn't actually need the coin > toss. The authors of the two PRs we were considering found a compromise > solution that seems to be good enough for both of them and which so far > seems to be good enough for the handful of people who agreed to the coin > toss (plus, it seems, several others who didn't agree to the toss). > > In short, I think the coin toss was a good attempt. Although we didn't > use its results this time, I think it's something we should keep in our > toolkit for the futur
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
In my previous email in response to David Harding I said: "I think you have consistently said it doesn't matter too much although you did previously express a preference for block height." This was based on: "My preference would be for whatever solution is most preferred by reviewers." March 7th https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792220340 With a greater number of PR comments preferring block height at this point I concluded that this equated to a preference for block height. I'm happy to correct my previous statement having spoken to David. This did not equate to a preference and David was entirely neutral. For the sake of the mailing list (even though David didn't do so) expressing preferences on a PR is absolutely fine. It is fine to say "This is my preference" without NACKing a PR or NACKing a technical decision. I (and many others) have done this. Maintainers can look through the PR, read the rationales for the preferences and still consider merging the PR. However, well reasoned NACKs (e.g. Concept, Approach NACKs) make it difficult for maintainers to merge a PR especially if they are from long term contributors. If you oscillate from a preference one way to a full on NACK the other way to "Let's coin flip it" with minimal rationale you are making maintainers' jobs even more difficult. You are also wasting the time of reviewers who don't know which PR to review and which PR stands a better chance of being merged. You are also (unintentionally) increasing the risk of bugs not being caught because the PR that eventually gets merged hasn't received the review it could have. I have been criticized on IRC for the tone of my emails. To be clear I take Taproot activation seriously, I take the Core review process seriously and I take keeping the community informed of the likely timetable seriously. I'm not impressed by people wasting my time and I'm doubly not impressed by people wasting other Core reviewers' time and maintainers' time. If that informs my tone so be it. This is not directed towards David who has worked hard to make progress with Taproot activation, hasn't wasted anyone's time and I have a huge amount of respect for. In terms of the latest state of play with Core, there is an open Core PR for Speedy Trial (#21377) that appears to be our best chance of getting activation code merged into Core. The more testing and code review this Core PR receives the better. If it continues to make progress the discussion will then need to move onto a timetable. On Fri, Apr 9, 2021 at 12:19 PM Michael Folkson wrote: > > I have no problem with coin tosses to decide for example shed colors > (an illustrative example discussed by copumpkin, roasbeef on IRC). In > this kind of example everyone should recognize it doesn't matter and > Approach ACK two competing PRs. No one should be NACKing or Approach > NACKing a PR based on shed color. If the maintainers don't care about > the shed color either then they are free to use a coin toss to decide > which PR to merge. In this example there shouldn't be any NACKs, > Approach NACKs or technical opposition from regular Core reviewers. > NACKs are not meant to be used for shed colors. > > However, in this example the organizer of the coin toss had previously > NACKed one of the options (block height, though his position seems to > change by the day) and others have NACKed MTP. I think you have > consistently said it doesn't matter too much although you did > previously express a preference for block height. > > I don't want to belabor the point but can we avoid even suggesting > using coin tosses on consensus code decisions in future please? It > makes a mockery of those who spent time understanding the technical > considerations and have spent months or years working on soft fork > activations. Even in the shed color example, leave it to the > maintainers to decide whether a coin toss is appropriate rather than > creating a circus around a coin toss in a public meeting where the PR > authors weren't present and no Core maintainers were present. > > I understand the frustration and I understand the desire to break > deadlocks. But if the coin toss organizer hadn't previously NACKed one > of the options (block height) we may have avoided getting into this > deadlock in the first place. > > Your recent review notes of PR #21377 look great and are proving very > helpful to me as I look at the PR. > https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40 > > Thanks > Michael > > On Thu, Apr 8, 2021 at 10:57 PM David A. Harding wrote: > > > > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev > > wrote: > > > So the latest circus
Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC
Hi Bitcoin Mechanic I will attend but I will be looking at Core PR #21377 over the next couple of days and I would encourage other reviewers to review that PR too. If that PR is merged into Core I would strongly recommend any alternative release be fully compatible with the activation parameters in Core. We can discuss in the meeting what we think the cut off date should be for when Core should no longer be a consideration. Personally I think (and hope) we will see progress on #21377 in the coming days. For the sake of the mailing list Bitcoin Mechanic has set up a meeting to discuss an alternative release to Core with Taproot activation code. Thanks Michael > Taproot activation meeting on IRC - Tuesday 13th April 19:00 UTC > The focus of the meeting will be ratifying the Taproot activation plan > previously discussed at the March 16th meeting (aka 2021-03 Plan Y as > summarized here): https://docs.google.com/spreadsheets/d/1K3pmH09yXLTHGV3wqFZGR3ei7QVwtdEwo0PjI2NHD3w/edit#gid=0 > While there was never any consensus reached on the LOT parameter, there > appears to be consensus on BIP8 and the remaining parameters, and more than > sufficient support for LOT=True to proceed safely. > Miners will have 18 months in which to signal and accelerate activation. If > not, taproot will activate regardless. > With a majority of the economy running this it will guarantee eventual > lock-in of taproot with the smallest chance of a chain split. > As a reminder, the channel is also open for ongoing discussion 24/7, and > there is a web chat client here: > https://webchat.freenode.net/?channel=##taproot-activation > Best, > Bitcoin Mechanic > Sent with [ProtonMail](https://protonmail.com/) Secure Email. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Yesterday's Taproot activation meeting on IRC
Yesterday there was a Taproot activation meeting on the ##taproot-activation Freenode channel. The agenda was posted in advance to the mailing list by BitcoinMechanic. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018769.html The conversation log is here: http://gnusha.org/taproot-activation/2021-04-13.log Discussion focused on an alternative release to Bitcoin Core with the naming of the release not yet finalized. Some participants expressed concern of having "Bitcoin Core" in the name e.g. "Bitcoin Core + Taproot" as it would be confusing to users and give them the mistaken impression that it had been signed off by Bitcoin Core maintainers. The activation mechanism(s) for this alternative release is Speedy Trial (BIP 8, consistent use of block height) followed by BIP 8 (1 year, LOT=true). The BIP 8 (1 year, LOT=true) is only started assuming Taproot hasn't activated during the Speedy Trial deployment. Draft release notes for this alternative release are here: https://docs.google.com/document/d/1Uhn1SEDMAqQkzkPZ4B5lPTSjUFEXKPndt_oBI4eUm7A/edit?usp=sharing The GitHub repo for this alternative release is here: https://github.com/BitcoinActivation/bitcoin To compare this to the most likely activation mechanism(s) in Bitcoin Core at this point. If the Core PR #21377 is merged in its current form then the activation mechanism in Bitcoin Core will be Speedy Trial (BIP to be decided, mix of block height and MTP). The starttime and timeout will use MTP and the activation point will use block height. The Core PR #21377 is here: https://github.com/bitcoin/bitcoin/pull/21377 In addition a BIP PR for the Core release has been opened here with suggested finalized parameters: https://github.com/bitcoin/bips/pull/1104 If these plans continue as is Bitcoin Core and this alternative release won't be entirely compatible due to startheight and timeout being defined according to MTP and block height respectively. In the majority of cases they should both activate at the same block height (or not activate) but there are unlikely edge cases where one activates and one doesn't (in addition to a possible timewarp attack on MTP). The use of MTP in Speedy Trial for Bitcoin Core has been discussed extensively and reviewers' opinions are summarized here: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277 >From this point on I will try to stay as neutral as I can and just summarize the facts to keep this list informed but anyone can review my past mailing list posts to get my personal views if you are interested. As a reminder anyone can host a meeting on the ##taproot-activation channel. All they need to do is contact me to book a time slot and ideally post an agenda to this mailing list in advance of the meeting. That meeting host will have the ability to issue warnings and if necessary kick participants if the meeting host feels they are disrupting the meeting or diverting conversation from the agenda. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Update on Taproot activation releases
I discussed in the last Taproot activation meeting notes the plans for an alternative release to Bitcoin Core with the Speedy Trial activation mechanism (BIP 8, consistent use of block height) followed by a BIP 8(1 year, LOT=true). This has now been released (version 0.1) under the name "Bitcoin Core 0.21.0-based Taproot Client". The build is available from https://bitcointaproot.cc/ and the GitHub repo is here: https://github.com/BitcoinActivation/bitcoin Luke Dashjr (Bitcoin Core contributor, Bitcoin Knots, UASF) is contributing to this release but there are a number of other pseudonymous individuals contributing to it too. In my attempted neutral stance I would say that it is not as thoroughly reviewed as an upcoming Bitcoin Core release will be but if you support a consistent use of block height (BIP 8 Speedy Trial) followed by a BIP 8 (1 year, LOT=true) I would encourage you to review and test it. Of course there may well be future version releases of "Bitcoin Core 0.21.0-based Taproot Client". If you are unable to review the code yourself but you support this effort it may be worth waiting for a future version before running it or ensuring you update to the latest version when it is released. Moving onto Bitcoin Core and other alternative Bitcoin implementations. As expected Bitcoin Core is proceeding with Speedy Trial (mix of MTP and block height, BIP to be decided). If Speedy Trial fails to activate on this Core release there is no follow up activation mechanism. That is not to say there will never be one in a Core release later in the year but as it stands there is no follow up. Bitcoin Core PR 21377 has been merged and the activation parameters (Bitcoin Core PR 21686) have also been merged. As discussed in my previous email you would expect Speedy Trial to activate (or not activate) on both Bitcoin Core and Bitcoin Core 0.21.0-based Taproot Client. However, there is a small possibility it activates on one but not the other. This is due to Bitcoin Core going with a mix of MTP and block height and Bitcoin Core 0.21.0-based Taproot Client going with consistent block height. Assuming they both activate due to Speedy Trial they share the same activation block height of 709632 (approximately November 12th 2021). If Speedy Trial fails to activate Bitcoin Core 0.21.0-based Taproot Client will attempt to enforce miner signaling in November 2022 (approximately, it is defined by block height). To be clear that is November **2022**. There are of course alternative Bitcoin implementations to Bitcoin Core. Jeremy Rubin has attempted to inform the maintainers of some alternative Bitcoin implementations of the finalized activation parameters in Core: https://github.com/bitcoin/bips/pull/1104#issuecomment-820011540 At the time of writing Laolu Osuntokun (roasbeef, maintainer of btcd) has ACKed the parameters and stated "I think we'll be able to get everything reviewed+tested (likely adding signet support along the way) by November." Piotr Narewski (maintainer of Gocoin) has also notified that he's seen the parameters. In terms of future meetings on the ##taproot-activation Freenode channel there is only one meeting currently booked. That is on Tuesday April 20th at 19:00 UTC and the meeting host will be Jeremy Rubin. The mailing list has yet to receive an agenda but I suspect it will be sent at some point in advance of the meeting. As always if there are any errors or perceived bias in my attempts to inform please respond. Ideally I would like all users to be informed of the facts so they can make up their mind on what to run and what they spend time reviewing and testing. Of course tensions are running higher than normal but that is not an excuse to spread factual inaccuracies. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
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: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages
I don't want to divert from the topic of this thread ("Waiting
SIGHASH_ANYPREVOUT and Packing Packages"), we can set up a separate
thread if we want to discuss this further. But just a couple of
things.
> Browsing quickly through Greg's piece, a lot of the reasoning is based on
> FOSS experience from Linux/Juniper, which to the best of my knowledge are
> centralized software projects ?
That is Greg's point. If Linux doesn't look further than the current
version and the next version with a BDFL (Linus) a decentralized
project like Bitcoin Core is going to struggle even more with longer
term roadmaps.
I think it is important to discuss what order changes should be
attempted but I agree with David that putting specific future version
numbers on changes is speculative at best and misleading at worst. The
record of previous predictions of what will be included in particular
future versions is not strong :)
> What was making sense when you had like ~20 Bitcoin dev with 90% of the
> technical knowledge doesn't scale when you have multiple second-layers
> specifications
It is great that we have a larger set of contributors in the ecosystem
today than back in say pre 2017. But today that set of contributors is
spread widely across a number of different projects that didn't exist
pre 2017. Changes to Core are (generally) likely to be implemented and
reviewed by current Core contributors as Lightning implementation
developers (generally) seem to have their hands full with their own
implementations.
I think we can get the balance right by making progress on this
(important) discussion whilst also maintaining humility that we don't
know exact timelines and that getting things merged into Core relies
on a number of people who have varying levels of interest and
understanding of L2 protocols.
On Mon, Jun 21, 2021 at 9:13 AM Antoine Riard wrote:
>
> Hi Dave,
>
> > That might work for current LN-penalty, but I'm not sure it works for
> eltoo.
>
> Well, we have not settled yet on the eltoo design but if we take the later
> proposal in date [0], signing the update transaction with SIGHGASH_ANYPREVOUT
> lets you attach non-interactively a single-party controlled input at
> broadcast-time. Providing the input amount is high enough to bump the
> transaction feerate over network mempools, it should allow the tx to
> propagate across network mempools and that way solve the pre-signed feerate
> problem as defined in the post ?
>
> > If Bitcoin Core can rewrite the blind CPFP fee bump transaction
> > to refer to any prevout, that implies anyone else can do the same.
> > Miners who were aware of two or more states from an eltoo channel 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 i
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Hey Billy No, fee sensitive timelocks weren't discussed at any length in the workshop. The workshops are obviously time limited but if they spur future discussion and drafted proposals (whether they need soft forks or not) outside of the workshops that would be great. This idea was raised in the meeting by Ruben Somsen so maybe Ruben has given them some thought. Making timelocks conditional on the current fee rate seems challenging to me (where is the current network fee rate obtained from and how is it fed into the script?) but I haven't sketched out exactly how they would work. A reminder that the second workshop (on package relay and fee bumping) starts at 19:00 UTC today (30 minutes after I've sent this, there may be a delay before it is published to the mailing list). Thanks Michael On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wrote: > > Thanks for the Summary Michael! > > It seems like fee-sensitive timelocks weren't discussed too much in the > workshop, unless I'm missing something. I also don't see any downside to it > discussed (other than that it needs a soft-fork). It seems like that would be > a great way to substantially increase the resilience of the LN to temporary > periods of fee congestion, even potentially long-running periods that last > weeks. It might even help in non-temporary fee market increases by giving > participants extra time to use some fee-bumping technique to close or > restructure their channels to compensate for the elevated fee market. > > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev > wrote: >> >> 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 transa
Re: [bitcoin-dev] Tuesday’s IRC workshop on L2 onchain support
Sure, feel free to continue on this thread for discussion of fee sensitive timelocks. I'll start a new thread for a summary of today's second workshop. On Tue, Jun 22, 2021 at 7:26 PM Billy Tetrud wrote: > > > where is the current network fee rate obtained from and how is it fed into > > the script? > > It could be obtained as something like the median transaction fee rate over a > window of X blocks. Its something any full node could easily keep track of. > And as long as hour-level or day-level granularity is acceptable, I wouldn't > think there'd be any need to incorporate mempool information (if that were > even possible without introducing new attack vectors). Let me know if this > isn't an appropriate thread to discuss this in. > > On Tue, Jun 22, 2021 at 11:21 AM Michael Folkson > wrote: >> >> Hey Billy >> >> No, fee sensitive timelocks weren't discussed at any length in the >> workshop. The workshops are obviously time limited but if they spur >> future discussion and drafted proposals (whether they need soft forks >> or not) outside of the workshops that would be great. This idea was >> raised in the meeting by Ruben Somsen so maybe Ruben has given them >> some thought. Making timelocks conditional on the current fee rate >> seems challenging to me (where is the current network fee rate >> obtained from and how is it fed into the script?) but I haven't >> sketched out exactly how they would work. >> >> A reminder that the second workshop (on package relay and fee bumping) >> starts at 19:00 UTC today (30 minutes after I've sent this, there may >> be a delay before it is published to the mailing list). >> >> Thanks >> Michael >> >> On Tue, Jun 22, 2021 at 7:02 PM Billy Tetrud wrote: >> > >> > Thanks for the Summary Michael! >> > >> > It seems like fee-sensitive timelocks weren't discussed too much in the >> > workshop, unless I'm missing something. I also don't see any downside to >> > it discussed (other than that it needs a soft-fork). It seems like that >> > would be a great way to substantially increase the resilience of the LN to >> > temporary periods of fee congestion, even potentially long-running periods >> > that last weeks. It might even help in non-temporary fee market increases >> > by giving participants extra time to use some fee-bumping technique to >> > close or restructure their channels to compensate for the elevated fee >> > market. >> > >> > On Thu, Jun 17, 2021 at 1:16 PM Michael Folkson via bitcoin-dev >> > wrote: >> >> >> >> 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 >> >&
[bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up
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
[bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC
Hi There is an online Zoom call (also livestreamed on YouTube) on Tuesday July 20th at 17:15 UTC discussing Taproot roll out post activation in November. It will be focused at developers and so discussion will be technical but all are welcome to attend/watch. Murch has this wiki page monitoring planned ecosystem support of P2TR addresses and it would be great to hear from projects and businesses that have Taproot support on their medium/long term development roadmap or are considering it: https://en.bitcoin.it/wiki/Bech32_adoption Meetup link (Zoom link will be announced here): https://www.meetup.com/BitDevsLDN/events/279041693/ Draft pre-reading link (will be finalized before Tuesday): https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254 Thanks Michael -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Last week's second IRC workshop on L2 onchain support and wrap up
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
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
Re: [bitcoin-dev] Online discussion on Taproot roll out - Tuesday July 20th 17:15 UTC
Please find below the video and transcript from the online discussion on Taproot roll out that was held on July 20th. Video: https://www.youtube.com/watch?v=GAkLuZNsZzw Transcript: https://btctranscripts.com/london-bitcoin-devs/2021-07-20-socratic-seminar-taproot-rollout/ Reading list: https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254 On Sat, Jul 17, 2021 at 2:16 PM Michael Folkson wrote: > > Hi > > There is an online Zoom call (also livestreamed on YouTube) on Tuesday > July 20th at 17:15 UTC discussing Taproot roll out post activation in > November. It will be focused at developers and so discussion will be > technical but all are welcome to attend/watch. > > Murch has this wiki page monitoring planned ecosystem support of P2TR > addresses and it would be great to hear from projects and businesses > that have Taproot support on their medium/long term development > roadmap or are considering it: > https://en.bitcoin.it/wiki/Bech32_adoption > > Meetup link (Zoom link will be announced here): > https://www.meetup.com/BitDevsLDN/events/279041693/ > > Draft pre-reading link (will be finalized before Tuesday): > https://gist.github.com/michaelfolkson/0803271754f851530fe8242087859254 > > Thanks > Michael > > -- > Michael Folkson > Email: michaelfolk...@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?
The "No Taproot" section of the Sapio docs need updating :) What are your plans to take advantage of Taproot with Sapio? It would have been interesting to see what a Taproot emulator would have looked like, although no need for it now. It seems to me Taproot would have been harder to emulate than CTV though I could be wrong. https://learn.sapio-lang.org/ch05-02-taproot.html Also there have been a number of people asking questions about Sapio and CTV on the Libera equivalents of Freenode channels #sapio and ##ctv-bip-review over the past months. Do you plan to join and claim those channels? Date: Thu, 26 Aug 2021 03:26:23 -0700 From: Jeremy To: Andrew Poelstra , Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script? Message-ID: Content-Type: text/plain; charset="utf-8" This has actually never been true (Sapio assumes extensions). If the extensions are not present, you can stub them out with a signing federation instead, configurable as flags, and you can also write many contracts that do not use the ctv based components at all. The protocol for emulation is a bit clever (if I do say so myself) since it ensures that contract compilation is completely offline and the oracles are completely stateless. Relevant links: https://learn.sapio-lang.org/ch05-01-ctv-emulator.html https://learn.sapio-lang.org/ch03-02-finish.html Cheers, Jeremy -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
With a new BIP editor (Kalle Alm) in place and Taproot activation locked in it is probably/possibly as good time as any to revisit the BIP process and see if we can bolster it, improve it or at least inform why certain things operate the way they do. Hence two IRC meetings are being organized, one on Tuesday September 14th (23:00 UTC) and one on Wednesday September 29th (23:00 UTC), both on the Libera IRC channel #bitcoin-dev. Possible discussion topics range from the relatively mundane (should BIP champions need to ACK basic spelling change PRs) to the possibly contentious (what role if any do the BIPs have in informing the community of soft fork activation parameters). At the very least it would be good to address some common misunderstandings and subtleties of the BIP process that many (including myself) are lacking context on. So if you are interested in the BIP process or certainly if you have experienced frustrations with the BIP process in the past as a BIP champion or BIP contributor please attend and we’ll see what progress we can make. There is a BIP process wishlist that some have already contributed ideas too: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist And of course BIP 2 outlines the current BIP process: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki This is being organized in the spirit of seeking to improve a process and a resource that we as a community all rely on so please engage in the spirit that is intended. I will keep the mailing list informed of anything that comes out of the meetings and the #bitcoin-dev channel is open for discussion outside of the meetings. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> I see zero reason whatsoever to not simply reorg ~every block, or as often as > is practical. If users opt in to wanting to test with reorgs, they should be > able to test with reorgs, not wait a day to test with reorgs. One of the goals of the default Signet was to make the default Signet resemble mainnet as much as possible. (You can do whatever you want on a custom signet you set up yourself including manufacturing a re-org every block if you wish.) Hence I'm a bit wary of making the behavior on the default Signet deviate significantly from what you might experience on mainnet. Given re-orgs don't occur that often on mainnet I can see the argument for making them more regular (every 8 hours seems reasonable to me) on the default Signet but every block seems excessive. It makes the default Signet into an environment for purely testing whether your application can withstand various flavors of edge case re-orgs. You may want to test whether your application can withstand normal mainnet behavior (no re-orgs for long periods of time) first before you concern yourself with re-orgs. > Why bother with a version bit? This seems substantially more complicated than > the original proposal that surfaced many times before signet launched to just > have a different reorg signing key. Thus, users who wish to follow reorgs can > use a 1-of-2 (or higher multisig) and users who wish to not follow reorgs > would use a 1-of-1 (or higher multisig), simply marking the reorg blocks as > invalid without touching any header bits that non-full clients will ever see. If I understand this correctly this is introducing a need for users to sign blocks when currently with the default Signet the user does not need to concern themselves with signing blocks. That is entirely left to the network block signers of the default Signet (who were AJ and Kalle last time I checked). Again I don't think this additional complexity is needed on the default Signet when you can set up your own custom Signet if you want to test edge case scenarios that deviate significantly from what you are likely to experience on mainnet. A flag set via a configuration argument (the AJ, 0xB10C proposal) with no-reorgs (or 8 hour re-orgs) as the default seems to me like it would introduce no additional complexity to the casual (or alpha stage) tester experience though of course it introduces implementation complexity. To move the default Signet in the direction of resembling mainnet even closer would be to randomly generate batches of transactions to fill up blocks and create a fee market. It would be great to be able to test features like RBF and Lightning unhappy paths (justice transactions, perhaps even pinning attacks etc) on the default Signet in future. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> Huh? Why would the goal be to match mainnet? The goal, as I understand it, is > to allow software to use SigNet without modification *to make testing simpler* - keep the header format the same to let SPV clients function without (significant) modification, etc. The point of the whole thing is to make testing as easy as possible, why would we do otherwise. I guess Kalle (and AJ) can answer this question better than me but my understanding is that the motivation for Signet was that testnet deviated erratically from mainnet behavior (e.g. long delays before any blocks were mined followed by a multitude of blocks mined in a short period of time) which meant it wasn't conducive to normal testing of applications. Why would you want a mainnet like chain? To check if your application works on a mainnet like chain without risking any actual value before moving to mainnet. The same purpose as testnet but more reliably resembling mainnet behavior. You are well within your rights to demand more than that but my preference would be to push some of those demands to custom signets rather than the default Signet. Testing out proposed soft forks in advance of them being considered for activation would already be introducing a dimension of complexity that is going to be hard to manage [0]. I'm generally of the view that if you are going to introduce a complexity dimension, keep the other dimensions as vanilla as possible. Otherwise you are battling complexity in multiple different dimensions and it becomes hard or impossible to maintain it and meet your initial objectives. But if this feature of extremely regular re-orgs is an in demand feature for testers I think the question then becomes what the default be (I would suggest re-orgs every 8 hours rather than no re-orgs at all) and then the alternative which you can switch to, re-orgs every block or every 6 blocks or whatever. > I believe my suggestion was not correctly understood. I'm not suggesting > *users* sign blocks or otherwise do anything manually here, only that the existing block producers each generate a new key, and we then only sign reorgs with *those* keys. Users will be able to set a flag to indicate "I want to accept sigs from either sets of keys, and see reorgs" or "I only want sigs from the non-reorg keys, and will consider the reorg keys-signed blocks invalid" Ah I did misunderstand, yes this makes more sense. Thanks for the correction. [0] https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining On Fri, Sep 10, 2021 at 7:24 PM Matt Corallo wrote: > > > > On 9/10/21 06:05, Michael Folkson wrote: > >> I see zero reason whatsoever to not simply reorg ~every block, or as often > >> as is practical. If users opt in to wanting to test with reorgs, they > >> should be able to test with reorgs, not wait a day to test with reorgs. > > > > One of the goals of the default Signet was to make the default Signet > > resemble mainnet as much as possible. (You can do whatever you want on > > a custom signet you set up yourself including manufacturing a re-org > > every block if you wish.) Hence I'm a bit wary of making the behavior > > on the default Signet deviate significantly from what you might > > experience on mainnet. Given re-orgs don't occur that often on mainnet > > I can see the argument for making them more regular (every 8 hours > > seems reasonable to me) on the default Signet but every block seems > > excessive. It makes the default Signet into an environment for purely > > testing whether your application can withstand various flavors of edge > > case re-orgs. You may want to test whether your application can > > withstand normal mainnet behavior (no re-orgs for long periods of > > time) first before you concern yourself with re-orgs. > > Huh? Why would the goal be to match mainnet? The goal, as I understand it, is > to allow software to > use SigNet without modification *to make testing simpler* - keep the header > format the same to let > SPV clients function without (significant) modification, etc. The point of > the whole thing is to > make testing as easy as possible, why would we do otherwise. > > Further, because one goal here is to enable clients to opt in or out of the > reorg chain at will > (presumably by just changing one config flag in bitcoin.conf), why would we > worry about making it > "similar to mainnet". If users want an experience "similar to mainnet", they > can simply turn off > reorgs and they'll see a consistent chain moving forward which never reorgs, > similar to the > practical experience of mainnet. > > Once you've opted into reorgs, you almost certainly are looking to *test* > reorgs - you just > restarted Bitcoin Core with the reorg flag set, waiting around for a reorg > after doing that seems > like the experience of testnet3 today, and the whole reason why we wanted > signet to begin with - > things happen sporadically and in
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
> Can you explain the motivation for this? From where I sit, as far as I know, > I should basically be > a prime example of the target market for public > signet - someone developing bitcoin applications > with regular requirements > to test those applications with other developers without > jumping through hoops to configure software the same across the globe and set > up miners. > With blocks > being slow and irregular, I’m basically not benefited at all by > signet and will > stick with testnet3/mainnet testing, which both suck. On testnet3 you can realistically go days without blocks being found (and conversely thousands of blocks can be found in a day), the block discovery time variance is huge. Of course this is probabilistically possible on mainnet too but the probability of this happening is close to zero. Here[0] is an example of 16,000 blocks being found in a day on testnet3. On signet block discovery time variance mirrors mainnet. On mainnet you are risking Bitcoin with actual monetary value. If you don't mind doing this then you don't need testnet3, signet or anything else. In addition proposed soft forks may be activated on signet (and could also be on testnet3) well before they are considered for activation on mainnet for testing and experimentation purposes. [0] https://web.archive.org/web/20160910173004/https://blog.blocktrail.com/2015/04/in-the-darkest-depths-of-testnet3-16k-blocks-were-found-in-1-day/ -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
Hey Prayank Thanks for the suggestions. > bitcoin-dev mailing list link can be considered a BIP and saved in a BIP > directory. Anyone can create such directories. So BIP is nothing but a > proposal shared on bitcoin-dev mailing list. A mailing list post is static and a BIP will go normally go through multiple edits and revisions so you do need to take advantage of the Git version control system. It gets quite unwieldy to attempt to do that via a mailing list with every minor suggested edit getting sent to all subscribers. Also allowing the entire global population (billions of people) to be able to create a directory doesn't sound like a good idea to me :) > This will avoid the 'bitcoin/bips' repository being considered as some BIP > authority that approves BIPs and proposals can improve Bitcoin without using > the repository. Repository will only be helpful in documenting BIP correctly. I can only speak for myself here but I am not particularly concerned about this perception of authority. We need a central repo that we can all refer to (rather than BIPs being distributed across a large number of repos) and that central repo needs to managed and maintained by somebody (in this case the two BIP editors Kalle and Luke). In the same way as there are limits on the ability of Core maintainers to unilaterally merge in contentious code changes there are similar limits on the ability of BIP editors. Ultimately anyone merging a PR has to consider process/consensus and concerns can (and have been in the past) be raised on this mailing list or elsewhere. > 2. Bot in `bitcoin/bips` repository that notifies about pull requests based > on different things. This will help maintainer(s) and contributors. I'm not sure where you are suggesting a bot should be. On IRC? There is a BIP merges bot on Mastodon[0] that I'm aware of and obviously you can subscribe to GitHub repo notification emails. > 3. BIP Gallery: I tried sharing things in a different way so that newbies can > understand importance of BIPs in Bitcoin and relate to it: > https://prayank23.github.io/BIPsGallery/ however couldn't complete it with > all the BIPs because not many people considered it helpful. There were few > suggestions to improve it by adding some text for each BIP and better image > gallery. Maybe someone else can create a better project. This looks cool. I think we can definitely do better in encouraging more people to engage with the BIP process especially as the ideas start flowing in post Taproot activation brainstorming what should be in the "next soft fork" (trademark!). Some of the BIPs (e.g. the Taproot BIPs 340-342) are quite technically dense so someone on IRC suggested making greater use of informational BIPs to supplement the standard BIPs for new implementers or even casual readers. [0] https://x0f.org/@bipmerges On Tue, Sep 14, 2021 at 1:17 PM Prayank wrote: > > Hi Michael, > > Thanks for sharing the details about the meeting. > > Wishlist has some interesting points. I would like to suggest few things: > > 1.BIP process: > > A. Plan and document a proposal > > B. Open PR in https://github.com/bitcoin/bips and edit everything properly > > C. BIP is assigned a number and merged > > D. Share the proposal on bitcoin dev mailing list > > bitcoin-dev mailing list link can be considered a BIP and saved in a BIP > directory. Anyone can create such directories. So BIP is nothing but a > proposal shared on bitcoin-dev mailing list. > > Who implements the BIP? When is it implemented? How is it implemented? > Opinions on proposal etc. will be different for each BIP. This will avoid the > 'bitcoin/bips' repository being considered as some BIP authority that > approves BIPs and proposals can improve Bitcoin without using the repository. > Repository will only be helpful in documenting BIP correctly. > > 2. Bot in `bitcoin/bips` repository that notifies about pull requests based > on different things. This will help maintainer(s) and contributors. > > 3. BIP Gallery: I tried sharing things in a different way so that newbies can > understand importance of BIPs in Bitcoin and relate to it: > https://prayank23.github.io/BIPsGallery/ however couldn't complete it with > all the BIPs because not many people considered it helpful. There were few > suggestions to improve it by adding some text for each BIP and better image > gallery. Maybe someone else can create a better project. > > > -- > Prayank > > A3B1 E430 2298 178F -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
>> I can only speak for myself here but I am not particularly concerned about >> this perception of authority. > This perception affects Bitcoin. Personally I would rather have an optimal process that provides clarity and helps us build better software than be sensitive to inaccurate perceptions that hinder that ultimate goal. > Bitcoin Core is an implementation (used by most of the nodes right now). BIPs > are proposals for Bitcoin. Indeed, thanks for pointing this out. I take it as a given that everyone knows this but yeah when making such a comparison it is good to make this clear. > Using same organization on GitHub and such comparisons can be misleading for > many. I think there's an argument that BIPs could be under a different GitHub organization but it would be pretty low on my list or priorities. There is a clear divide between the group of Core maintainers and the group of BIP editors and in the absence of a reason to change that I would rather maintain the status quo. > I don't think we need ACKs/NACKs in BIPs repository and I feel weird to be a > part of discussions, ACKing this pull request: > https://github.com/bitcoin/bips/pull/1104. With BIP champions having more latitude in getting their BIP PR merged than they would for example getting their Core PR merged I agree ACK/NACKs on BIP PRs are less relevant. However, I still think some BIP champions would like to have their changes reviewed especially by subject matter experts. And if there are strong disagreements over the changes made an alternative BIP is always an option. I don't see the harm in having discussion with reviewers on BIP PRs and reviewers registering an ACK/NACK as long as we are all clear on what the BIP process is. > Not sure any Bitcoin project needs a pull request merged in this repository > to implement a proposal. I agree it is optional for some/many Bitcoin projects whether they are BIPed or not. Would you be comfortable with a soft fork/consensus code change going into Bitcoin Core without a BIP? I personally wouldn't. We should probably leave it at that to ensure we are not spamming the email list but hope to see you at the meeting later :) On Tue, Sep 14, 2021 at 3:50 PM Prayank wrote: > > > A mailing list post is static and a BIP will go normally go through > > multiple edits and revisions so you do need to take advantage of the Git > > version control system. It gets quite unwieldy to attempt to do that via a > > mailing list with every minor suggested edit getting sent to all > > subscribers. > > Mailing list post will have the link to BIP documentation. Post itself > doesn't need to be updated but same link can be used to share updated > information. Example: > https://gist.github.com/prayank23/95b4804777fefd015d7cc4f847675d7f (Image can > be changed in gist when required or add new information) > > Mailing list post will help in reading discussions related to proposal. > > >Also allowing the entire global population > (billions of people) to be able to create a directory doesn't sound > like a good idea to me :) > > There is nothing to allow/disallow. That's the whole point. People are free > to save links and organize things which can be called a BIP directory. > > > I can only speak for myself here but I am not particularly concerned about > > this perception of authority. > > This perception affects Bitcoin. > > > In the same way as there are limits on the ability of Core maintainers to > > unilaterally merge in contentious code changes there are similar limits on > > the ability of BIP editors. Ultimately anyone merging a PR has to consider > > process/consensus and concerns can (and have been in the past) be raised on > > this mailing list or elsewhere. > > Bitcoin Core is an implementation (used by most of the nodes right now). BIPs > are proposals for Bitcoin. Using same organization on GitHub and such > comparisons can be misleading for many. I don't think we need ACKs/NACKs in > BIPs repository and I feel weird to be a part of discussions, ACKing this > pull request: https://github.com/bitcoin/bips/pull/1104. Not sure any Bitcoin > project needs a pull request merged in this repository to implement a > proposal. > > > I'm not sure where you are suggesting a bot should be. > > A bot similar to DrahtBot in Bitcoin Core repository. > > Few other developers had suggested similar thing earlier: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.html > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.html > > -- > Prayank > > A3B1 E430 2298 178F > > > > Sep 14, 2021, 19:37 by michaelfolk...@gmail.com: > > Hey Prayank > > Thanks for the suggestions. > > bitcoin-dev mailing list link can be considered a BIP and saved in a BIP > directory. Anyone can creat
[bitcoin-dev] Tuesday's BIP process meeting
Tuesday's BIP process meeting was announced previously here [0]. A conversation log of the meeting is available here [1]. It looks promising at this stage that we'll eventually have a bundle of changes to warrant a new proposed BIP (BIP 3) to replace the current BIP process that is described in BIP 2 [2]. Obviously there was only a very small group of attendees at this week's IRC meeting and so there should (and will) be ample time for the community (and this list) to review whatever changes are proposed before they are considered for merging into the BIPs repository and before they take effect. The following proposed changes were discussed: 1) An end to the 3 year rejection rule. In BIP 2 a BIP enters the "Rejected" state after 3 years if no progress had been made. The BIP champion then needs to address public criticism of the BIP to be able to leave the "Rejected" state. It is proposed instead that after 3 years the BIP would enter an "Inactive" state that only requires activity from the BIP champion to leave the "Inactive" state. 2) Currently BIP champions need to ACK pull requests with basic spelling/grammar changes before they can be merged. This is time consuming not only for the BIP editors who have to chase the BIP champions but it can be irritating for the BIP champions too especially if they champion multiple BIPs. It is proposed that BIP editors instead can use their judgment to merge in changes that don't impact the meaning of the BIP cc'ing the BIP champions and with reversions possible if the BIP champion is unhappy with the change. A single pull request making changes across multiple BIPs (e.g. spelling corrections) will not be considered for merging however. 3) BIP comments were introduced so that subject matter experts and informed critics of a proposal could make it clear to BIP readers and implementers of possible defects with the proposal. However, they have been rarely used and the few comments submitted on BIPs seem to have been widely ignored. Instead it is proposed that link(s) to bitcoin-dev mailing list post(s) with criticism or outlines of defects can be included within a BIP by the BIP editors such that the interested reader can easily be directed to the source of that information. 4) BIP champion(s) of soft fork BIPs containing consensus changes could theoretically include an activation method and parameters in their BIP unilaterally without consulting the broader community. (To be clear this is not necessarily what happened with Taproot activation parameters but there was confusion and disagreement about the role of BIPs and BIP editors in the perceived "finalization" of activation parameters.) This needs further discussion but proposed changes include sharpening the wording around activation parameters to make it clear that any parameters included are merely those recommended by the BIP champion(s) and don't necessarily have community consensus. Alternative proposals would be to not include activation methods or parameters within the BIP at all or to give BIP editors latitude to highlight concerns in a bitcoin-dev mailing list post and then include a link to that post within the BIP. For details of other changes discussed in the meeting please see the conversation log [1]. Kalle Alm has also sent an email [3] on BIP extensions to this list. The next meeting is on Wednesday September 29th (23:00 UTC) on the Libera IRC channel #bitcoin-dev. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://gist.github.com/michaelfolkson/f2870851bb812b4ac86006ea54ca78a2 [2]: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki [3]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html Michael Folkson Email: michaelfolk...@protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Reminder: Second BIP process meeting tomorrow at 23:00 UTC
As announced here [0] there is a second BIP process meeting tomorrow (Wednesday September 29th 23:00 UTC). For Asia Pacific this is the morning of September 30th. It will be held on the #bitcoin-dev Libera IRC channel. A summary from the first meeting is here [1]. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html Thanks Michael Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Wednesday’s second BIP process meeting
Wednesday’s second BIP process meeting was announced previously here [0]. A conversation log of the meeting is available here [1]. A summary of the first BIP process meeting is here [2]. The following is a summary of what was discussed. 1) The limits or possible downsides of pursuing maximal decentralization. Understandably there is a desire for greater decentralization as a central repo introduces bottlenecks and the need for maintainers or editors in the case of BIPs (prayank). However, zero filters creates a Ethereum style bewildering number of BIPs of varying quality that all need to be stored and maintained. The option of being able to store a BIP in any repo doesn’t appear to offer material upside (michaelfolkson). It still needs to get a BIP number from the BIP editors and if the alternative repo is deleted or the BIP champion becomes unresponsive there is the problem of changing the location of where the BIP is stored. It is much easier to monitor a single repo rather than an infinite number of repos that contain BIPs. 2) Past motivations for introducing alternative parallel processes to the BIPs (e.g. BOLTs, SLIPs). Anyone is free to set up a repo, add documentation to that repo or even set up a parallel process to the BIPs. However, if as a community we’d like to prevent unnecessary splintering it is good to understand why certain documents that should be BIPed aren’t being BIPed. Obviously not every document needs or should be BIPed. There are many docs that aren’t BIPs that are hugely valuable. One historical concern that was raised (ChristopherA) was regarding why BIP 48 didn’t happen and whether it was because it was coming from the wallet community and not a Bitcoin Core proposal. luke-jr said after the meeting that from recollection the reason it didn’t happen was merely that it was never written [3]. It was also discussed afterwards whether there was/is a rationale for Lightning BOLTs not being BIPs and whether they should be BIPs in future. 3) Kalle Alm’s proposal for BIP extensions [4] was discussed. Participants seemed to be in favor of the proposal though further clarity on when they would and wouldn’t be used was requested. A BIP extension for the bech32m update (BIP 350) to bech32 (BIP 173) seems like it would have been a good use case though further discussion is probably needed on whether they should be used for soft fork activation parameters. It was suggested that using dates and/or short extension names would be superior to extension numbers as numbers suggest an ordering (ChristopherA). The extension 2 may also be perceived as somehow replacing extension 1. Thanks to the participants of both BIP process meetings. Further discussion is welcome on the #bitcoin-dev Libera IRC channel and hopefully we will see progress in the coming weeks and months on a proposed BIP 3 [5] update. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://gist.github.com/michaelfolkson/84000ee3fe45c034ac12a7a54ff5fcdd [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html [3]: https://github.com/bitcoin/bips/pull/253 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html [5]: https://github.com/bitcoin/bips/pull/1015 -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] On the regularity of soft forks
I was hoping to delay this post as long as possible because there are so many interesting and important things to discuss other than soft forks and consensus changes that seem to have taken a backseat this year due to Taproot activation. In addition, there seems to be a world of opportunity to leverage the upcoming Taproot soft fork that risks getting drowned out by speculating on the next soft fork. There is clearly nothing wrong with some individuals continuously working on, designing and refining new possible consensus changes and whoever is interested is free to follow and participate in those discussions. This is Bitcoin, no one let alone me can decide what people should focus on. Indeed I intend to allocate a portion of my time to following and understanding the trade-offs of current and future soft fork proposals. However, in this post I will argue against frequent soft forks with a single or minimal set of features and instead argue for infrequent soft forks with batches of features. I fully understand the desire and motivation to get consensus changes into Bitcoin as quickly as possible when certain use cases depend on them. However, the robustness, security and ability to resist harmful or suboptimal changes to the system is clearly the ultimate priority. The more frequently soft forks are attempted the harder it is for the community to ensure harmful or suboptimal changes don’t creep into the consensus rules. I am well aware of how much community mindshare Taproot activation demanded this year. This is how it should be. The community should be informed and vigilant when the consensus rules are changed. Every full node will either immediately on activation or in future enforce these consensus rule changes and so it is in the interests of every full node operator that these changes have been subject to the ultimate levels of community review and rigorous testing. Attempting them frequently either requires continuous community monitoring or an acceptance that an unneeded or harmful consensus change could easily creep into Bitcoin. Neither of these options seem acceptable to me. It is not reasonable to ask all the different segments of the community to dedicate full time resources to stay on top of proposed consensus changes. Hence treating a pull request to a Bitcoin implementation that requires a soft fork like any other pull request is shortsighted. Merging soft fork code into a Bitcoin implementation The code for a soft fork should not be merged into a Bitcoin implementation, let alone activation parameters (discussed later), until the maintainers of that implementation are comfortable that the entirety of that soft fork has sufficient community consensus. This includes what many consider the reference implementation and dominant implementation on the network, Bitcoin Core. A soft fork pull request cannot and should not be treated like any other pull request which can be merged with anything from 1 to 10 ACKs from long term or newer contributors. The act of merging a pull request that is part of a proposed soft fork is an acknowledgement by the maintainer(s) of that implementation that they consider the entirety of that proposed soft fork to have community consensus. That includes what is included in that soft fork as well as what isn’t. If there is a prevailing view that the current design could be improved, could feasibly be replaced by something superior in future or merely hasn’t been subject to sufficient community review it should not be merged. Of course there is no ultimate authority to enforce that this happens, Bitcoin is an entirely voluntary system. A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. 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. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources. Soft fork activation Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork. Merging activation parameters or encouraging miner signaling before it is clear there is community consensus on the entirety of the soft fork is putting the c
Re: [bitcoin-dev] On the regularity of soft forks
> Interesting discussion.Correct me if I'm wrong: but putting too many features > together in one shot just can't make things harder to debug in production if > something very unexpected happens.It's a basic principle of software > engineering. Soft fork features can (and should) obviously be tested thoroughly on testnet, signet, custom signets, sidechains etc on a standalone basis and a bundled basis. But whether or not it is a basic principle of general software engineering kind of misses the point. Security critical software clearly isn't engineered in the same way as a new social media app. Bugs are easily reverted in a new social media app. A consensus change is extremely hard to revert and probably requires a hard fork, a level of central coordination we generally attempt to avoid and a speed of deployment that we also attempt to avoid. On top of that we aren't just dealing with security critical software. One of the most important objectives is to keep all the nodes on the network in consensus. Introducing a consensus change before we are comfortable there is community consensus for it is a massive effective bug in itself. The network can split in multiple ways e.g. part of the network disagrees on whether to activate the consensus change, part of the network disagrees on how to resist that consensus change, part of the network disagrees on how to activate that consensus change etc In addition, a social media app can experiment in production whether Feature A works, whether Feature B works or whether Feature A and B work best together. In Bitcoin if we activate consensus Feature A, later decide we want consensus Feature B but find out that by previously activating Feature A we can't have Feature B (it is now unsafe to activate it) or its design now has to be suboptimal because we have to ensure it can safely work in the presence of Feature A we have made a mistake by activating Feature A in the first place. Decentralized security critical consensus changes are an emerging field in itself and really can't be treated like any other software project. This will become universally understood I'm sure over time. -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ‐‐‐ Original Message ‐‐‐ On Friday, October 15th, 2021 at 1:43 AM, Felipe Micaroni Lalli via bitcoin-dev wrote: > Interesting discussion.Correct me if I'm wrong: but putting too many features > together in one shot just can't make things harder to debug in production if > something very unexpected happens. It's a basic principle of software > engineering. > > Change. Deploy. Nothing bad happened? Change it a little more. Deployment. > > Or:Change, change, change. Deploy. Did something bad happen? What change > caused the problem? > > On Thu, Oct 14, 2021 at 8:53 PM Anthony Towns via bitcoin-dev > wrote: > >> On Mon, Oct 11, 2021 at 12:12:58PM -0700, Jeremy via bitcoin-dev wrote: >>> > ... in this post I will argue against frequent soft forks with a single or >>> minimal >>> > set of features and instead argue for infrequent soft forks with batches >>> > of features. >>> I think this type of development has been discussed in the past and has been >>> rejected. >> >>> AJ: - improvements: changes might not make everyone better off, but we >>> don't want changes to screw anyone over either -- pareto >>> improvements in economics, "first, do no harm", etc. (if we get this >>> right, there's no need to make compromises and bundle multiple >>> flawed proposals so that everyone's an equal mix of happy and >>> miserable) >> >> I don't think your conclusion above matches my opinion, for what it's >> worth. >> >> If you've got two features, A and B, where the game theory is: >> >> If A happens, I'm +100, You're -50 >> If B happens, I'm -50, You're +100 >> >> then even though A+B is +50, +50, then I do think the answer should >> generally be "think harder and come up with better proposals" rather than >> "implement A+B as a bundle that makes us both +50". >> >> _But_ if the two features are more like: >> >> If C happens, I'm +100, You're +/- 0 >> If D happens, I'm +/- 0, You're +100 >> >> then I don't have a problem with bundling them together as a single >> simultaneous activation of both C and D. >> >> Also, you can have situations where things are better together, >> that is: >> >> If E happens, we're both at +100 >> If F happens, we're both at +50 >> If E+F both happen, we're both at +9000 >> >> In general, I think combining proposals when the combination is better >> than the individual proposals were is obviously good; and combining >> related proposals into a single activation can be good if it is easier >> to think about the ideas as a set. >> >> It's only when you'd be rejecting the proposal on its own merits that >> I think combining it with others is a bad idea in principle. >> >> For specific examples, we bundled
[bitcoin-dev] Taproot activates - A time/block line
I thought I would collect together the highlights from Taproot activating for those strange Bitcoin history buffs (including myself). If you’d rather watch in video form 0xB10C provided an excellent livestream [0] showing blocks and transactions in the run up to and directly after Taproot activating. Back in July [1] 0xB10C (with the help of F2Pool) spent from Taproot (P2TR) outputs months before Taproot activated. Taproot rules weren’t being enforced and hence these spends were treated as anyone-can-spend. Hence I won’t treat these as the “first” Taproot spends as they didn’t need to meet Taproot consensus rules. Block 709631: The last block before Taproot rules were enforced was mined by AntPool. By this point there were various P2TR outputs in blocks, some timelocked for higher than block 709631 but others not timelocked. These non-timelocked P2TR outputs were in effect anyone-can-spend like the ones 0xB10C spent from in July as Taproot rules were not yet being enforced. No P2TR outputs were spent immediately before activation as far as I can tell. Block 709632: The first block where full nodes started enforcing Taproot rules was mined by F2Pool. It seems [2] F2Pool wasn’t enforcing Taproot rules and did not include any Taproot spends (some with high fee rates) in this block. More seriously an invalid Taproot spend included in this block could have cost them the block reward and caused a re-org when full nodes (and miners) enforcing Taproot rules rejected this block. Given they didn’t include any attempted Taproot spends (valid or invalid) in the block this protected them from that but it does lead to discussions for a later time on whether Speedy Trial signaling was effective if some mining pools signaled readiness months previous but then did not enforce the new soft fork rules on activation. Block 709633: Mined by AntPool. Similar to F2Pool they didn’t include any Taproot spends in this block and one would assume that they also weren’t enforcing Taproot rules though this has not been confirmed. Block 709634: Also mined by AntPool. Block 709635: The first block which included (numerous) valid Taproot spends (and no invalid Taproot spends) was mined by Foundry USA. The first Taproot spend [3] was completed by bitbug42. It was a key path spend and the OP_RETURN in this first Taproot spend contained the message “I like Schnorr sigs and I cannot lie”. Andrew Chow had the second Taproot spend [4] but the first script path spend. He also spent from two Taproot vanity addresses beginning bc1ptapr00t which were presumably generated using his Rust Bitcoin Vanity Address Generator [5]. Pieter Wuille had the third Taproot spend [6]. He also had the bronze medal for SegWit spends on SegWit activation in 2017 [7], he was third then too. However, his vanity address game stepped up for Taproot. For SegWit he spent from one vanity address beginning 35Segwit. This time he spent from vanity addresses beginning bc1ptapr00tearly, bc1pay2tapr00t, bc1pmyusetapr00t, bc1partytaptap and this isn’t including all the vanity addresses that were sent to. He (with Greg Maxwell’s help) searched 2.4 quadrillion keys in a week [8]. BitGo had the fourth Taproot spend [9] and the first Taproot multisig spend via the script path. The script used OP_CHECKSIG and OP_CHECKSIGVERIFY which have been modified with the Taproot upgrade to check Schnorr signatures but it didn’t use the new opcode OP_CHECKSIGADD that has been introduced for threshold (and multi) signatures. It contained an OP_RETURN message with “Thx Satoshi! ∞/21mil First Taproot multisig spend -BitGo” jaoNoctus claimed the fifth Taproot spend and narcelio and ottosch claimed the sixth and seventh Taproot spends. The first use of OP_CHECKSIGADD on mainnet was completed [10] by Alekos Filini using modified code [11] from the BDK (Bitcoin Dev Kit) library. Any errors are my own and I will gladly correct. Thanks to 0xB10C, Greg Maxwell, Pieter Wuille, Murch, Andrew Chow, BitGo, Daniel McNally, Rearden Code, Alekos Filini, Chun, pinheadmz for highlighting these various events online. Thanks to the various block explorers (Esplora, mempool.space etc) that were very useful for monitoring Taproot activation. And thanks to the community as a whole for participating and engaging with this successful upgrade. Without participation and engagement these upgrades are meaningless and it is a great sign for Bitcoin’s future that there was so much interest and scrutiny of this upgrade. [0]: https://www.youtube.com/watch?v=1jijKVB1cNA, https://www.twitch.tv/0xb10c/video/1204909643 [1]: https://b10c.me/blog/007-spending-p2tr-pre-activation/ [2]: https://twitter.com/satofishi/status/1459868549674065926?s=20 [3]: 33e794d097969002ee05d336686fc03c9e15a597c1b9827669460fac98799036 [4]: 3defed8717c581b4c0509329550e344bdc14ac38f71fc050096887e535c8 [5]: https://github.com/achow101/rust-vanitygen [6]: 83c8e0289fecf93b5a284705396f5a652d9886
[bitcoin-dev] Stumbling into a contentious soft fork activation attempt
I have already expressed my arguments on the regularity of soft forks [0]. Having spent months of my time on Taproot activation last year attempting to get at least rough community consensus on the activation method it seems crazy to me that some want to do that again so soon after Taproot activation and somehow this time it will be plain sailing. (Spoiler: it won’t. Although Taproot safely activated there remain outstanding views ranging on whether BIP 8 or 9 variants of Speedy Trial should be used in future to Speedy Trial only being a short term stopgap that should not be repeated.) 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. I stated in that post: “A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. 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. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources.” I am getting increasingly concerned that we are stumbling into this scenario three months after I wrote that post. One of many future soft fork proposals (as many will know) is BIP 119 [1] which is the enabling of a new opcode OP_CHECKTEMPLATEVERIFY (OP_CTV). 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]. 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]. Similar work has not been done for any of the speculated use cases of OP_CTV. 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. 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. I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day. It is true that Jeremy has some rudimentary proofs of concept built but as any software engineer will tell you the vast majority of the challenges are encountered once you attempt to build out that proof of concept. Once you do you may realize that the tool (or opcode) you are using isn’t the right one for the job. Unlike adjusting a feature on a social media app adjusting a consensus change once it has been activated is trickier to put it mildly. There are a number of other more interesting technical discussions to be had later (what kind of covenants we want and are able to enable safely on Bitcoin etc, how CTV compares to other covenant enabling proposals, to what extent activating CTV would impact future proposals) but I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt. Jeremy has put up this site (https://utxos.org/signals/) which is collecting so-called “soft signals”. I very much doubt anyone has a problem with Jeremy engaging with the community on his proposal and receiving feedback. However, the site currently states: “The following organizations, individuals, or pools have communicated preference for and intent to support a BIP-119 activation attempt using reasonable parameters. These “soft signals” are non-binding until an actual concrete proposal has been formed, but are useful for measuring community consensus.” There have been a number of “soft signals”, many expressing enthusiasm for the speculated use cases of OP_CTV. Personally I share that enthusiasm like I do with the prospect of curing cancer. But these soft signals seem as if they are going to be used to attempt to justify an imminent contentious soft fork attempt. The devil is in the details both with regards to wording like “reasonable parameters” and the utility and s
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
> 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
Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt
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 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 >>
Re: [bitcoin-dev] CTV BIP review
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
wrote:
> -Original Message-
>
> From: Luke Dashjr l...@dashjr.org
>
> Sent: Tuesday, January 18, 2022 2:10 PM
>
> To: e...@voskuil.org
>
> Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org
>
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 e...@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
[bitcoin-dev] Highlighting Taproot implementation gotchas
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
> 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 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 relativel
Re: [bitcoin-dev] Improving RBF Policy
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 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 > th
Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies
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 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
Re: [bitcoin-dev] [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies
> 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 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 michaelfolk...@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 t
Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)
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 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 > 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 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 lis
Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
> 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 wrote: > Devs, > > In advance of the CTV meeting today, I wanted to share what my next step is > in advocating for CTV
Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
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 > 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 >> attem
Re: [bitcoin-dev] 7 Theses on a next step for BIP-119
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 --- Origin
[bitcoin-dev] User Resisted Soft Fork for CTV
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
ling >> 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 > 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 prud
[bitcoin-dev] What to expect in the next few weeks
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What to expect in the next few weeks
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 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 > 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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
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 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 > 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
Re: [bitcoin-dev] What to expect in the next few weeks
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 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 > 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 >> 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
Re: [bitcoin-dev] What to expect in the next few weeks
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 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 > 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 >> theore
[bitcoin-dev] Transcript: Sydney Socratic on FROST w/ Jesse Posner
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, khttps://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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Miniscript support in hardware wallets/signing devices
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] What to do when contentious soft fork activations are attempted
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Transcript: Carl Dong on libbitcoinkernel
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
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
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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP draft: Half-Aggregation of BIP-340 Signatures
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 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). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Online Socratic on MuSig2 and biweekly secp256k1 IRC meeting
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
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 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
[bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
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
Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
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 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 >
Re: [bitcoin-dev] P2P trading replacement transactions
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 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.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Transcript: Online Socratic on MuSig2
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2
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 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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
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 wrote
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
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 equiva lent 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 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@lists.linuxfoundation.org wrote: > > > > > I agree with Ma
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
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 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 w
Re: [bitcoin-dev] bitcoin-inquistion: evaluating soft forks on signet
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 thi ng. 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 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
Re: [bitcoin-dev] Custom signet for testing full RBF
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 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
> 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 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 >> 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 -
Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
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 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, an
Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
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 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 > 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 poli
Re: [bitcoin-dev] Roles and procedures around adding a bitcoin core maintainer
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 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 maintai
[bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
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 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 > 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
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 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-...@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 codeb ase 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
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 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 > wrote: > >> Some people highlighted some minor problems with my last email: >> >> On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev >> wrote: >>> >>> >>> >>> [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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
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/bitco
Re: [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
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 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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
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 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 > 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 st
Re: [bitcoin-dev] A new Bitcoin implementation integrated with Core Lightning
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 wrote: > Hi Michael, > > On Wed, Apr 19, 2023 at 2:40 AM Michael Folkson via bitcoin-dev > 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 eve
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
ave 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 bytes144" > > > 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@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 happ
Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions
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 wrote: > On Tue, Apr 18, 2023 at 12:40:44PM +, 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
