Re: [bitcoin-dev] What to expect in the next few weeks

[alicexbt <alicexbt@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 13830 bytes --]

Hi Michael,

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

I'm quoting 5 points from the blog post and putting some words in capital :

- EVALUATE the software PROPOSED above and find any bugs (claim 5.5 BTC Bounties?)
- DISCUSS vociferously through the next few months if BIP-119 SHOULD BE ACTIVATED OR NOT (that means you should e.g. POST PUBLICLY if you/your org ENDORSES this particular path, cover it in your news org, etc).
- Before the end of July, Miners should signal IF the speedy trial should succeed
- Before November, IF Speedy Trial passes, then all users should ensure they upgrade to validate CTV
- IF Speedy Trial FAILS, at least we were at the ball, and we can either TRY AGAIN NEXT YEAR, meaning CTV would be available for use in at minimum 1.5 years, or we can RE-EVALUATE the design of CTV against ALTERNATIVES that would take more time to prepare engineering wise (e.g., more general covenants, small tweaks to CTV).

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

People are free to discuss things on different apps and websites. Not everyone enjoys spamming the mailing list every day with the same message repeated in many threads. Instead of trusting a group, I would ask them to verify everything and think critically and independently.

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

You should assume good faith not incompetence for a developer who has contributed to bitcoin for years as suggested earlier: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020303.html

Chain splits are discussed during each soft fork and nothing wrong in a conversation that is looking for solutions. Personal attacks will not stop chain split but they might derail the covenants research and development. Jeremy will be remembered for his contributions in bitcoin covenants and others can help him improve bitcoin with code. Some developers have already started reviewing, testing and even writing code for use cases of other covenant proposals.

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

- Developers have discussed, suggested and wrote lot of things during Binance and Bitfinex hack. This includes lot of respected core developers and co-authors of previous soft forks. I would not rehash and go in to the details of each event, comments etc. as this has nothing to do with BIP 119.

https://www.reddit.com/r/Bitcoin/comments/4vupa6/p2shinfo_shows_movement_out_of_multisig_wallets/d61qyaj/

- Coin flip was neither proposed by Jeremy nor used for anything during Taproot

Bitcoin developers care about bitcoin, despite our differing viewpoints on some issues. I'm sure we can accuse others of being irresponsible about a lot of things, and breaking bitcoin doesn't always require a soft fork. Nobody needs anyone's permission to suggest improvements to Bitcoin or to contribute in other ways, the most common of which is coding.

Please don't use personal insults to deter bitcoin contributors.

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.
------- Original Message -------
On Tuesday, April 26th, 2022 at 7:23 PM, Michael Folkson via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:

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

[-- Attachment #2: Type: text/html, Size: 16112 bytes --]