Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

It is quite ironic that yeah, it is quite ironic that the people who are
constantly basing their arguments on personal attack are also the ones who
complain the most about personal attacks. That's exactly the irony I was
trying to convey.
Just like some people claim that the only people against bip119 are people
ignorant about bip119, I can also claim that everyone against bip8 doesn't
really understand it, can't I?
The same people who spread the misinformation that bip8 "would be perceived
by most users as developers trying to dictate changes" are now complaining
about people spreading misinformation about their own proposals. I
personally find it as ironic as it can get.
I'm glad I'm not the only one who noticed how ironic the whole situation is.
How often are the people claiming to be concerned about misinformation
precisely the ones who spread the most misinformation?
Very ironic indeed.

On Fri, May 6, 2022 at 10:07 PM John Tromp via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, 6 May 2022 7:17PM Jorge Tim?n wrote
> > But let's not personally attack andreas for his opinions.
> > The only reason you don't like bip8 is because you're ignorant about it
> and
> > you haven't reviewed it enough.
>
> Can you see the irony in equating "clueless about BIP119" with a
> personal attack and then calling Jeremy ignorant about BIP8?
>
> -John
> ___
> 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] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

So, to be clear, you didn't design speedy trial "to make everyone unhappy"
as Ryan claims, no?
That's a really strange claim on his part.
When the grace period for slower activation after lock in was added, I
don't think it was added to make me or people like me who dislike that
proposal unhappy. On the contrary, I think the goal was precisely to
address some of our concerns.
But it doesn't address them all, as I've tried to explain other times.
I truly think you wanted to make everyone happy with speedy trial, but you
didn't do it, sorry.
I know it' not a lack of capacity because you did impressive and genius
things like simplicity.
But despite your best intentions and your great capacity, I still think
speedy trial is a very bad proposal because you got the analysis wrong.
Let me reiterate that this is not attack against you, but only against one
of your ideas.
Sorry if I sounded sarcastic, but I was trying to be sarcastic with ryan,
not with you.


On Fri, May 6, 2022 at 8:24 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Russell O'Connor wrote the definitive explanation for how ST arose in
>>> the consensus process and how it was designed to make everyone
>>> unhappy.  It's a great explanation of what we went through last year.
>>>
>>>   https://r6.ca/blog/20210615T191422Z.html
>>>
>>> "On Building Consensus and Speedy Trial"
>>>
>>> on | 2021-06-15T19:14:22Z
>>> by | Russell O'Connor
>>>
>>
>> That's a lot of text, are you sure he said in there he designed speedy
>> trial to make everyone unhappy?
>> Well, if we're still talking about it, that proves that it failed at its
>> own design criterion of failing fast.
>>
>
> Quoting from https://r6.ca/blog/20210615T191422Z.html:
>
> > Speedy Trial’s design is not based on any sort of activation philosophy
> about failing fast.
> ___
> 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] What to do when contentious soft fork activations are attempted

[John Tromp via bitcoin-dev]

On Fri, 6 May 2022 7:17PM Jorge Tim?n wrote
> But let's not personally attack andreas for his opinions.
> The only reason you don't like bip8 is because you're ignorant about it and
> you haven't reviewed it enough.

Can you see the irony in equating "clueless about BIP119" with a
personal attack and then calling Jeremy ignorant about BIP8?

-John
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Russell O'Connor via bitcoin-dev]

On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Russell O'Connor wrote the definitive explanation for how ST arose in
>> the consensus process and how it was designed to make everyone
>> unhappy.  It's a great explanation of what we went through last year.
>>
>>   https://r6.ca/blog/20210615T191422Z.html
>>
>> "On Building Consensus and Speedy Trial"
>>
>> on | 2021-06-15T19:14:22Z
>> by | Russell O'Connor
>>
>
> That's a lot of text, are you sure he said in there he designed speedy
> trial to make everyone unhappy?
> Well, if we're still talking about it, that proves that it failed at its
> own design criterion of failing fast.
>

Quoting from https://r6.ca/blog/20210615T191422Z.html:

> Speedy Trial’s design is not based on any sort of activation philosophy
about failing fast.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

On Tue, May 3, 2022 at 4:36 PM Ryan Grant  wrote:

> On Sun, May 1, 2022 at 8:49 PM Jorge Timón via bitcoin-dev
>  wrote:
> > On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >> [...] Andreas is clueless about BIP 119 and other covenant
> >> proposals.  He is spreading misinformation and [...]
>
> > Clueless and spreading disinformation, you say?  What
> > misinformation, could you explain?
>
> First, OP_CTV covenants cannot restrict any address that the sender
> does not control.  OP_CTV just delivers auditable presigned
> transactions.  That's it!  OP_CTV's primary design constraint is to
> NOT empower new ways to do blacklists (which are already possible
> using unwanted-multisig).  That's not a statement about what Bitcoin
> should ultimately become, but rather what Bitcoin is likely ready for.
> Much like Bitcoin's design, the simplest possible covenant solution
> was chosen, so that it would be "dirt simple" to audit that the code
> does only what it should, and no more.
>
> Andreas used a few words of indecision to make excuses for not
> code-reviewing BIP119 or the pull request, while using a lot of words
> talking about: how dangerous any change is; conservative consensus
> process; and GovCoin blacklists.  This gave the strong impression that
> the change was dangerous and could easily lead to the creation of
> blacklists enforced by L1 consensus itself (rather than enforced by
> other signers in a sidechain or unwanted-multisig).
>
> Andreas also didn't look into the reason that the proposed client was
> safe and would not cause a chain split.  Speedy Trials by themselves
> don't risk chain splits, they poll.  There was no UASF in the planned
> executable.  Some devs hate ST because it puts the initiative in
> miner's hands to gauge **user support and readiness** - which those
> devs feel the miners have no reason to be good at - but that expires
> speedily.  If everyone loved the change and the trial was about to
> pass, except ornery users - who we love when UASF is needed, of
> course - were going to cause a chain split of their own to block it,
> then ST offers miners the capability to - very quickly, faster than a
> release can be pushed out - change their signaling to again prevent a
> chain split.
>

I don't think that's enough of a reason to justify you calling andreas
"clueless". I'm sure whatever andreas said, he said it with the best
intentions.
Remember:

- Avoid personal attacks

Accusing andreas of being clueless is spreading misinformation.

Russell O'Connor wrote the definitive explanation for how ST arose in
> the consensus process and how it was designed to make everyone
> unhappy.  It's a great explanation of what we went through last year.
>
>   https://r6.ca/blog/20210615T191422Z.html
>
> "On Building Consensus and Speedy Trial"
>
> on | 2021-06-15T19:14:22Z
> by | Russell O'Connor
>

That's a lot of text, are you sure he said in there he designed speedy
trial to make everyone unhappy?
Well, if we're still talking about it, that proves that it failed at its
own design criterion of failing fast.
But if you think my judgement about speedy trial (sorry, we discussed it
for so long that I forgot the BIP number, it wasn't eight, I remember that)
and I locked my mind in about speedy trial too soon and without giving
anyone a chance to coordinate about my personal signaling of the
proposal...I guess I can give you a grace period of 6 months to upgrade
your own mind about it and accept my judgment about it, so that concern
about my criticism on the proposal is addressed.
There may be a couple of people trying to create dissent about this opinion
of mine. But once all concerns are addressed...

Andreas also didn't look for a non-attack reason for a separate binary
> release.  (Here I feel like I should be naming a lot of devs as well,
> hmm.)  Let's go back to O'Connor, who reminds us of a faction from the
> last consensus change:
>
>   > The "devs-do-not-decide" faction's concern is regarding the
>   > appearance of Bitcoin developers deciding the rules of Bitcoin.
>   > [...]  This faction would be fine with users building their own
>   > alternative client for forced activation, or a configuration flag
>   > for enabling some kind of forced activation that is not enabled by
>   > default.
>

Yeah, I know, both speedy trial and CTV could be perceived as developers
trying to dictate rules.
I guess that criticism against bip8 can be applied from now on to any
proposal forever. what a great precedent.
It's not always that software designers should focus on making everyone
unhappy (like any other kind of designer, I guess), but some times it's
potential perceptions from vaguely defined groups that should be at the
heart of your design decisions.


> Maintainers of the repository and "Big Name" devs have very personal
> reasons to take this stance.  Meanwhile, devs who want to form an
> opinion on some given matter 

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Ryan Grant via bitcoin-dev]

On Sun, May 1, 2022 at 8:49 PM Jorge Timón via bitcoin-dev
 wrote:
> On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev 
>  wrote:

>> [...] Andreas is clueless about BIP 119 and other covenant
>> proposals.  He is spreading misinformation and [...]

> Clueless and spreading disinformation, you say?  What
> misinformation, could you explain?

First, OP_CTV covenants cannot restrict any address that the sender
does not control.  OP_CTV just delivers auditable presigned
transactions.  That's it!  OP_CTV's primary design constraint is to
NOT empower new ways to do blacklists (which are already possible
using unwanted-multisig).  That's not a statement about what Bitcoin
should ultimately become, but rather what Bitcoin is likely ready for.
Much like Bitcoin's design, the simplest possible covenant solution
was chosen, so that it would be "dirt simple" to audit that the code
does only what it should, and no more.

Andreas used a few words of indecision to make excuses for not
code-reviewing BIP119 or the pull request, while using a lot of words
talking about: how dangerous any change is; conservative consensus
process; and GovCoin blacklists.  This gave the strong impression that
the change was dangerous and could easily lead to the creation of
blacklists enforced by L1 consensus itself (rather than enforced by
other signers in a sidechain or unwanted-multisig).

Andreas also didn't look into the reason that the proposed client was
safe and would not cause a chain split.  Speedy Trials by themselves
don't risk chain splits, they poll.  There was no UASF in the planned
executable.  Some devs hate ST because it puts the initiative in
miner's hands to gauge **user support and readiness** - which those
devs feel the miners have no reason to be good at - but that expires
speedily.  If everyone loved the change and the trial was about to
pass, except ornery users - who we love when UASF is needed, of
course - were going to cause a chain split of their own to block it,
then ST offers miners the capability to - very quickly, faster than a
release can be pushed out - change their signaling to again prevent a
chain split.

Russell O'Connor wrote the definitive explanation for how ST arose in
the consensus process and how it was designed to make everyone
unhappy.  It's a great explanation of what we went through last year.

  https://r6.ca/blog/20210615T191422Z.html

"On Building Consensus and Speedy Trial"

on | 2021-06-15T19:14:22Z
by | Russell O'Connor

Andreas also didn't look for a non-attack reason for a separate binary
release.  (Here I feel like I should be naming a lot of devs as well,
hmm.)  Let's go back to O'Connor, who reminds us of a faction from the
last consensus change:

  > The "devs-do-not-decide" faction's concern is regarding the
  > appearance of Bitcoin developers deciding the rules of Bitcoin.
  > [...]  This faction would be fine with users building their own
  > alternative client for forced activation, or a configuration flag
  > for enabling some kind of forced activation that is not enabled by
  > default.

Maintainers of the repository and "Big Name" devs have very personal
reasons to take this stance.  Meanwhile, devs who want to form an
opinion on some given matter but who do not want to do their own code
reviews typically look to Big Name code reviewers for guidance, in a
"Consensus Beauty Contest" [note_kbc].  Contrast this with everyone
who restricts their opinion-formation to their own review of the code;
they are "Doing Consensus Right", rather than being stuck in the
Beauty Contest.  Now, if a "devs-do-not-decide" dev wrote some code,
they implicitly reviewed their own code, right?  But!  If they did not
write that code, then they **must avoid it** ...in proportion to how
much it affects consensus.  According to this theory of Bitcoin's
consensus, we would **expect** Big Names to be partly missing from the
OP_CTV code reviews.  This confuses people who are used to playing the
Consensus Beauty Contest.

  [note_kbc:] for another game about what everybody else thinks,
see Keynesian beauty contest:
  https://en.wikipedia.org/wiki/Keynesian_beauty_contest

(The connection is funny to me because we all have to individually
play this game when deciding what money is, and in so doing pay a
last homage to Keynes, during our multi-generational exit from his
eponymous economics of manipulated interest rates.)

Jimmy Song, in a video best fitting the advocacy referred to by
Michael (who did not give any specific link), claims that the OP_CTV
review process is "routing around" some Big Names.  Jimmy is seemingly
unaware that some Big Names are explicitly not participating in
guiding what Bitcoin's consensus should be, and that some are even
using strategic ambiguity to do so.  With the context above, we have a
much less nefarious interpretation of motive for releasing a
binary - one that is part of the consensus process.

  

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Billy Tetrud via bitcoin-dev]

+1 alicexbt

We of course want knowledgeable bitcoiners who aren't knowledgeable about a
certain proposal to be skeptical. But what we don't want is for that
natural skepticism-from-ignorance to be interpreted as opposition, or
really a strong signal of any kind. Any thoughts from ignorance, whether
self-aware or not, should be given small weight. It seems the vast majority
of push back has been this kind of skepticism from ignorance. And to a
certain degree I think we want to give time for understanding to those who
have not participated in the first, second, third, etc round of discussion
on a proposal. It may not be reasonable to say "you had the last 2 years of
time to voice your concern".

Now that CTV is being taken seriously as a proposal, we probably should
give the community who is finally taking a serious look at it time to
understand, get their questions answered, and come to terms with it. This
is not to say that CTV as a technology or proposal has been rushed, or has
not had enough work put into it, but rather that the community as a whole
has not paid enough attention to it for long enough.

The wrong approach is: "how do I yell more loudly next time I see something
I'm uncomfortable with?" The right approach is to educate those who aren't
educated on the proposal and gather consensus on what people think when
they understand enough about it to contribute to that consensus. If you
care about consensus, you should respect the consensus process and be ok
with consensus being not your preferred outcome. If you don't care about
consensus, then you're basically attacking the bitcoin community.

On Sun, May 1, 2022 at 3:22 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Michael,
>
> 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.)
>
>
> Some users have been misled and there is nothing great being achieved by
> doing this on social media. Andreas is clueless about BIP 119 and other
> covenant proposals. He is spreading misinformation and some of the URSF
> enthusiasts do not understand what are they even opposing or going to run
> with risks involved.
>
>
> Answering the subject of this email: "What to do when contentious soft
> forks activations are attempted?"
>
> - Do not consider something contentious because someone said it on mailing
> list
> - Do not spread misinformation
> - Read all posts in detail with different opinions
> - Avoid personal attacks
> - Look at the technical details, code etc. and comment on things that
> could be improved
>
>
>
> /dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>
> 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 

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[Jorge Timón via bitcoin-dev]

On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Michael,
>
> 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.)
>
>
> Some users have been misled and there is nothing great being achieved by
> doing this on social media. Andreas is clueless about BIP 119 and other
> covenant proposals. He is spreading misinformation and some of the URSF
> enthusiasts do not understand what are they even opposing or going to run
> with risks involved.
>
Clueless and spreading disinformation, you say? What misinformation, could
you explain?


> - Avoid personal attacks
>
Could accusing someone of apreading misinformation without prove and
calling him clueless be considered a personal attack?
What do we do with hypocrites and liars?
People who knowingly lie to push their own agenda, how do we protect
against those?


> /dev/fd0
>
> Sent with ProtonMail  secure email.
>
> --- Original Message ---
> On Saturday, April 30th, 2022 at 3:23 PM, Michael Folkson via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
>
> 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 

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

[alicexbt via bitcoin-dev]

Hi Michael,

> 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](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)
>  highlighting the dangers many months ago or recent posts. Normally Optech is 
> very high signal.)

Some users have been misled and there is nothing great being achieved by doing 
this on social media. Andreas is clueless about BIP 119 and other covenant 
proposals. He is spreading misinformation and some of the URSF enthusiasts do 
not understand what are they even opposing or going to run with risks involved.

Answering the subject of this email: "What to do when contentious soft forks 
activations are attempted?"

- Do not consider something contentious because someone said it on mailing list
- Do not spread misinformation
- Read all posts in detail with different opinions
- Avoid personal attacks
- Look at the technical details, code etc. and comment on things that could be 
improved

/dev/fd0

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

> 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](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)
>  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.
>
> --

[bitcoin-dev] What to do when contentious soft fork activations are attempted

[Michael Folkson via bitcoin-dev]

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