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

[alicexbt via bitcoin-dev]

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

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

[Michael Folkson via bitcoin-dev]

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

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

[Erik Aronesty via bitcoin-dev]

>
>
> I would comment on this point, but I'm not sure I'm "technical enough". I
> have to admit: I've never played tennis.
>

You are technicial enough to read the nacks... everyone is:
https://github.com/JeremyRubin/utxos.org/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

I can give a summary of the nack arguments here on one sentence:"I am
resisting a consensus change because we don't have consensus"

It's lovely recursive logic

--

The most cogent *technical* arguments against ctv seem fall into 3 camps:

1. APO is better for eltoo:
https://twitter.com/rusty_twit/status/1518007923896578048?s=20=8IUgni_i5jcfSlJ1Gy7T1A

2. CTV doesn't have recursion, but i want recursion... which are swiftly
followed by arguments against recursion:
https://bitcoinops.org/en/newsletters/2022/03/09/#limiting-script-language-expressiveness

(I usually ignore this one)

3. TLUV is super cool for vaults, so why are we even talking about CTV when
TLUV is better?

I like this (positive vibes) summary:

https://raymonddurk.medium.com/bitcoin-after-taproot-86c93fe5cc0c

Nowhere in there would anyone say CTV is "bad".

Just that other opcodes will wind up being used more because they are more
purpose-fit for 

If only we had unlimited resources we could have APO/TLUV;/CTV all ready to
go and be able to evaluate them on a level playing field / signet.

Does this sound about right?   Am I missing something?


- Erik
___
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

[Jeremy Rubin via bitcoin-dev]

Thanks, this is good feedback.

I think the main thing then to add to forkd would be some sort of seed
nodes set that you can peer with of other forkd runners? And have forkd be
responsible for making sure you addnode them?

wrt the generation of other problems, my understanding of the *summons
rusty's bat signal i wonder if he'll see this* triumvirate in this context
is that it's essentially, in this case:

- Dev proposes
- Miners may signal
- Users may credibly threaten that if signal, Miners will lose consensus
with sufficient portion of economy.


And that it's really, AFAIU, the *threat* of the outcome that ensures that
miners don't signal, and the followthrough is intentionally messy. If it's
*not* messy, then it is actually less effective and people just 'go their
separate ways', but if the intent is to drive consensus, it must be messy.

This is similar to Nuclear Deterrence game theory, whereby it's clearly not
the right call to use nukes, but paired with an irrational leader, the
credible threat serves to force a system of more relative peace. So the
pairing of ST + Users able to reject, albeit messily, does form a
relatively stable configuration.

Kudos to NVK for explaining the nuance to me.
--
@JeremyRubin 


On Tue, Apr 26, 2022 at 3:47 AM Anthony Towns  wrote:

> On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev
> wrote:
> > 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?
>
> The point of running a client with a validation requirement of "blocks
> must (not) signal" is to handle the possiblity of there being a chain
> split, where your preferred ruleset ends up on the less-work side.
>
> Ideally that will be a temporary situation and other people will come to
> your side, switch their miners over etc, and your chain will go back to
> having the most work, and anyone who wasn't running a client with the
> opposite signalling requirement will reorg to your chain and ruleset.
>
> But forkd isn't quite enough to do that reliably -- instead, you'll
> start disconnecting nodes who forward blocks to you that were built on
> the block you disconnected, and you'll risk ending up isolated: that's
> why bip8 recommends clients "should either use parameters that do not
> risk there being a higher work alternative chain, or specify a mechanism
> for implementations that support the deployment to preferentially peer
> with each other".
>
> Also, in order to have other nodes reorg to your chain when it has
> more work, you don't want to exclusively connect to likeminded peers.
> That's less of a big deal though, since you only need one peer to
> forward the new chain to the compatible network to trigger all of them
> to reorg.
>
> Being able to see the other chain has more work might be valuable in
> order to add some sort of user warning signal though: "the other chain
> appears to have maintained 3x as much hash power as the chain your are
> following".
>
> In theory, using the `BLOCK_RECENT_CONSENSUS_CHANGE` flag to indicate
> unwanted signalling might make sense; then you could theoretically
> trigger on that to avoid disconnecting inbound peers that are following
> the wrong chain. There's already some code along those lines; but while I
> haven't checked recently, I think it ends up failing relatively quickly
> once an invalid chain has been extended by a few blocks, since they'll
> result in `BLOCK_INVALID_PREV` errors instead. The segwit UASF client
> took some care to try to make this work, fwiw.
>
> (As it stands, I think RECENT_CONSENSUS_CHANGE only really helps with
> avoiding disconnections if there's one or maybe two invalid blocks in
> a row from a random miner that's doing strange things, rather than if
> there's an active conflict resulting in a deliberate chain split).
>
> On the other hand, if there is a non-trivial chain split, then everyone
> has to deal with splitting their coins across the different chains,
> presuming they don't want to just consider one or the other a complete
> write-off. That's already annoying; but for lightning funds I think it
> means the automation breaks down, and every channel in the network would
> need to be immediately closed on chain, as otherwise accepting state
> updates risks losing the value of your channel balance on whichever
> chain you're lightning node is not 

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

[Jeremy Rubin via bitcoin-dev]

I'm a bit confused here. The "personal blog" in question was sent to this
list with an archive link and you saw an replied to it.

The proposal to make an alternative path hadn't gotten buy in sufficient
from those iterating, and given the propensity of people to blow things out
of proportion in this list, I wanted to be sure a follow up plan carried
some buy before wider dissemination.

On Tue, Apr 26, 2022, 6:53 AM Michael Folkson 
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.
>
> [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 Tuesday, April 26th, 2022 at 6:48 AM, Jeremy Rubin <
> jeremy.l.ru...@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 

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

[Jorge Timón via bitcoin-dev]

"The only 3 nacks"...I would not call that an accurate "collection of
feedback". Feedback is always more positive when you laregely chose to
ignore any negative feedback, isn't it?

"Largely, the formal critiques of CTV (the 3 NACKs) are based on topics of
whether or not to swing the racquet, not if we should be at the ball. "

I would comment on this point, but I'm not sure I'm "technical enough". I
have to admit: I've never played tennis.
Besides, I'm pretty sure any feedback I give would be ignored.
Following the tennis analogy, one could think Jeremy is trying to win this
match the way Nadal won Djokovich in Australia in 2021 (ie by doing
everything in his hand to make sure his opponent wasn't even allowed to
play, ie not by playing fair nor by playing better than the opppnent).

"Activation parameters like in taproot".
If this was a tennis match, then I would have some sort of ability to slow
time down or something, because I've been seeing this ball slowly coming
since taproot's activation parameters were discussed.

It feels a little bit "deja vu" too. Was ever a controversial hardfork
attempted "just with the same activation mechanism as the last softfork"?
I should look for the exact words, I guess.


On Mon, Apr 25, 2022, 23:45 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
>  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.tet...@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

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

[Melvin Carvalho via bitcoin-dev]

On Fri, Apr 22, 2022 at 7: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.
>

Thanks for raising this

Remembering 2017 quite well, it's often characterized as small block(ers)
vs big block(ers).  While that was certainly the case, I see it slightly
differently.

I think the bigger argument of 2017 was around a network split.  Splitting
the network is problematic because one or other of the split chains may
experience a hash death (without mitigating difficulty adjustment
algorithms), or the so-called "famine and feast" minority hash behaviour,
experienced on testnet, and disruptive to users

Any proposed changes should factor in network splits as a potential risk.
Or perhaps through another lens, you could see a network split as an
attack, on a par with a 51% attack, in terms of user disruption.  It may in
fact, be more potent, since we've never had a serious 51% attack, but we
have had network splits

I do think the conversation here is MUCH better tempered than 2017.
Hopefully we can try and avoid perceptions of gate keeping and railroading,
and keep the network together, as we did back then


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

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

[Anthony Towns via bitcoin-dev]

On Mon, Apr 25, 2022 at 10:48:20PM -0700, Jeremy Rubin via bitcoin-dev wrote:
> 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?

The point of running a client with a validation requirement of "blocks
must (not) signal" is to handle the possiblity of there being a chain
split, where your preferred ruleset ends up on the less-work side.

Ideally that will be a temporary situation and other people will come to
your side, switch their miners over etc, and your chain will go back to
having the most work, and anyone who wasn't running a client with the
opposite signalling requirement will reorg to your chain and ruleset.

But forkd isn't quite enough to do that reliably -- instead, you'll
start disconnecting nodes who forward blocks to you that were built on
the block you disconnected, and you'll risk ending up isolated: that's
why bip8 recommends clients "should either use parameters that do not
risk there being a higher work alternative chain, or specify a mechanism
for implementations that support the deployment to preferentially peer
with each other".

Also, in order to have other nodes reorg to your chain when it has
more work, you don't want to exclusively connect to likeminded peers.
That's less of a big deal though, since you only need one peer to
forward the new chain to the compatible network to trigger all of them
to reorg.

Being able to see the other chain has more work might be valuable in
order to add some sort of user warning signal though: "the other chain
appears to have maintained 3x as much hash power as the chain your are
following".

In theory, using the `BLOCK_RECENT_CONSENSUS_CHANGE` flag to indicate
unwanted signalling might make sense; then you could theoretically
trigger on that to avoid disconnecting inbound peers that are following
the wrong chain. There's already some code along those lines; but while I
haven't checked recently, I think it ends up failing relatively quickly
once an invalid chain has been extended by a few blocks, since they'll
result in `BLOCK_INVALID_PREV` errors instead. The segwit UASF client
took some care to try to make this work, fwiw.

(As it stands, I think RECENT_CONSENSUS_CHANGE only really helps with
avoiding disconnections if there's one or maybe two invalid blocks in
a row from a random miner that's doing strange things, rather than if
there's an active conflict resulting in a deliberate chain split).

On the other hand, if there is a non-trivial chain split, then everyone
has to deal with splitting their coins across the different chains,
presuming they don't want to just consider one or the other a complete
write-off. That's already annoying; but for lightning funds I think it
means the automation breaks down, and every channel in the network would
need to be immediately closed on chain, as otherwise accepting state
updates risks losing the value of your channel balance on whichever
chain you're lightning node is not following.

So to your original question: I think it's pretty hard to do all that
stuff in a separate script, without updating the node software itself.

More generally, while I think forkd *is* pretty much state of the art;
I don't think it comes close to addressing all the problems that a chain
split would create.  Maybe it's still worthwhile despite those problems
if there's some existential threat to bitcoin, but (not) activating CTV
doesn't seem to rise to that level to me.

Just my opinion, but: without some sort of existential threat, it
seems better to take things slowly and hold off on changes until either
pretty much everyone who cares is convinced that the change is a good
idea and ready to go; or until someone has done the rest of the work to
smooth over all the disruption a non-trivial chain split could cause.
Of course, the latter option is a _lot_ of work, and probably requires
consensus changes itself...

Cheers,
aj

___
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

[Jeremy Rubin via bitcoin-dev]

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

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

[Michael Folkson via bitcoin-dev]

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

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

[Michael Folkson via bitcoin-dev]

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] What to expect in the next few weeks

[Billy Tetrud via bitcoin-dev]

>   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

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

[Michael Folkson via bitcoin-dev]

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