Topic: [Taproot softfork] lukejr removing option to lock-in on timeout... :D (Read 358 times)

I believe when saying “community”, the nodes are in “this” part of the community which is comprised of the economic majority/users, and the miners/mining pools are in “that” part of the community which is comprised of the mining cartel/ASIC companies like Bitmain. Then there’s the developers.

some people may want to upgrade to new version due to new versions cleaning out old bugs but not to auto-vote in to new proposals

so having an auto-vote in can be forced by saying version 0.21.1 fixes a vulnerability and promote that everyone should download it without them knowing they are actually just auto-voting yes to a proposal

users should have the option and not have it as default.
devs should not have absolute power to force a vote/mandate a activation.

if the real community* (nodes and mining pools) say no. then so be it. devs should come up with a better proposal/feature that does appease the nodes and pools

there should definitely not be a mandated date that forks off the opponents before activation
there should not be a vote after opponents have left to fake acceptance

it should be only a vote first.and if it gets to the threshold. then activate.. and then if 10% are opponents. they just get endless block rejects or blocks they cant FULLY validate, unless they upgrade.
emphasis. it only activates if 90% accept

heck id even be happy if there was a 2 stage of 50% acceptance. triggers the devs to then release a 0.21.2 that has more code in it to accept taproot formats.. (still no mandates)
where 0.21.2 then has a better activation policy
and if it doesnt even get 50% in 0.21.1 they give up on taproot and just have 0.21.2 as bug fixes like usual

EDIT (answering the non-dev in post below)
*'community' being the nodes that actually provide important services.. meaning pools, exchanges and other retail nodes. and then their customers are part of "the community"

unlike just letting/pretending the community is just the dev group like some do(you know who you are) makes the pools and exchanges have less/no power. and left to only be able to get whatever devs hand out. no alternate choice.
so the community should have a choice, and if exchanges/users/pools say no.. then the devs should not ever again dare do any mandatory forks to force nodes that oppose devs desires. instead devs should accept defeat and work on bug issues or a different feature the community might accept

I believe, as a community, we should campaign for, and spread more awareness for the NECESSITY of LOT=true as the default, and UASF Taproot’s path to activation.

The miners will be the miners, it’s debatable if their interests are truly aligned with the interest of the network. Game-theoretically speaking, their interests are aligned with profit, and what blockchain gives them more of that. Therefore, they should only follow what the Core developers/community who have their interests aligned with the Bitcoin protocol.

I dunno, maybe because Segwit activates on August 2017, 5 years earlier than that? I rummaged through the mailing list and couldn't find any references of people suggesting August 2022 specifically, and the Taproot BIP 341's Deployment section still has "TODO" in it.

Keep in mind that this was likely decided soon after BIP341 was drafted (some time back in 2019) so my gut feeling says that they wanted to make sure everyone got enough time to upgrade their nodes.

If August 2022 is arbitrary, what is stopping core from making it January 1st 2022 or some other date?

I think that it was clear in my post as 14 people were fine with either choice 

Very well said, I could not have found a better way to express that, which is what I think too. Only problem I see is the very long wait: August 2022 is too far way, too many things can happen in this huge timeframe.

Not all 26 of the voters are against LOT=false, as explained in the wiki some of them chose to use LOT=false first and then if Taproot fails to activate after some time then use LOT=true, so chances are we'll see a Taproot deployment earlier than that.

If it's particularly important to activate Taproot then a BIP can be drafted that moves the flag day earlier BIP 148 style, but this is unlikely.

I agree with this actually. I don't see the need for signaling if you can just choose to run the code or not. I'm not a coder, but I understand the concept of simplistic code being better. Running the code should be the signal. This whole signaling after you install the update makes no sense to me and seems over engineered. If you don't run the new code, then you are signaling you don't support the changes.

When is the next IRC meetup for activation?

No, not quite

It's making LOT changeable that luke is regretting. He thinks it should be set in the code, and not changeable unless you edit the code (which is not easy for everybody)



someone (Matt Corallo, a Bitcoin dev) suggested that. But his proposal was just to activate the fork the simplest way: Bitcoin 0.21.1 would just start enforcing the fork after August 1st 2022. No signals, no percentages. Either you're running the new code or you're not.

That's not such a terrible compromise, all discussion will be pretty simple afterwords, chain forking risks are minimized, at the expense of a long wait for using Taproot.

So can the devs just vote to get rid of LOT and move forward? Is it too late for that? Seems like that would solve the debate no?

My understanding is that getting rid of LOT is the same thing as LOT=false. So if he regrets adding LOT, then why is he pushing so hard for LOT=true?

Yes, I know. It wouldn't be any different if:

1. hardcoded LOT=false 0.21.1 is released, miners stalled until timeout, LOT=true is released
2. Flag day is set for August 2022 (new proposal vaunted today on bitcoin-dev ml)

people would still download the software without understanding they were implicitly supporting activation of a softfork.

I wrote exactly that: people often don't know what they're doing when they upgrade. They also don't know what they're doing when they fail to change an option.

I could understand this "consent" argument of yours if someone had a credible argument about how taproot/schnorr was going to have a negative effect on people that won't even use it, but there are none. Like with much of Bitcoin (and tech in general), many people will use Taproot without even knowing they are, because they're not interested in the details.

According to the Taproot activation wiki, 26 attendees of the February meeting voted for LOT=false, 19 for LOT=true, but 14 from both these groups also suggested they would be fine with either choice. https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
Here is the IRC LOG https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

Do we really have to wait August 2022 for Taproot to be activated? It is light years away.

Most people don't see it that way. Upgrading to a new version is always equal to upgrading to a "new" version with new features and bug fixes, not signalling for a fork. A very small percentage of those upgrading read or understand the change-logs. And I'd argue that if they don't understand it that option should not be enabled for them by default.

We have already had about a dozen different soft forks, they were all safe without BIP8 (LOT) because they all took place using BIP9 which has no "forced activation" and more importantly mandates reaching >95% hashrate support.
The difference is actually a less safe fork activation. LOT is basically allowing anyone to split bitcoin into more than one chain with any amount of support even with 1% hashrate.

Maybe I am a bit off, but from my understanding, if nothing bad happens you are fully right.
But what if something bad happens, a critical bug is found and a quick fix needs to be released?

If people are assured that in this case there will be released both 0.21.0.1 and 0.21.1.1, I think that we are good and we can go on by your logic.
Maybe this is trivial for you, but many may assume that after 0.21.1 the next is 0.21.2 no matter what and from here they may feel that sooner or later they'll be forced to go on that path.

It won't change the number of coins available.  Just let the damn thing alone for God sakes.

right, that's the argument here: it shouldn't be available as an option, I'd only disagree that defaulting to "yes" is forcing anything on anyone



If dangerously low numbers of people running nodes upgrade to 0.21.1, then miners/pools won't follow the fork either.

Why have layers of opting-in to complicate the situation? People ought to be aware of the Taproot soft fork, and that running Bitcoin 0.21.1 will contribute to activating it. How is that any different to adding an extra option?

• If LOT is an option, some people won't set it, unaware that it's there (or don't understand what it does)
• If 0.21.1 is hardcoded to either LOT=false or LOT=true, some people won't upgrade, unaware of the implications (or don't understand them)

What's the difference? As a way to choose your preference for LOT, there is no difference. As a way of making the network safer right before the fork is activated, there's a big difference.


 

It is absurd to even talk about forced activation when the signalling has not yet even begun.
I could see lock-in on timeout or any similar forced activation be implemented in second try after the first period (1 year to activate) ends with malicious miner's preventing it and only after enough investigation took place to make sure the rejection was actually malicious and without any valid reasons but not before and in first try!

Generally speaking to have any proposal that makes group A force group B to bend to their will where neither group A nor B have the majority support (ie. >95% hashrate) is malicious in my view whether it is BIP-148 or BIP-8. Because the dangers of splitting this immutable blockchain of this currency that is supposed to be decentralized and based on consensus of majority with such actions is more severe than not having the new features added to bitcoin.
In other words LOT option should not even exist, and arguing whether default (true or false) is better is moot.

Based on the comments on the PR it seems like core is going to have the code that it wasn't supposed to have https://bitcointalksearch.org/topic/on-bip-8-and-chain-split-5293982

The nice thing about doing this is that everyone who disagrees with Taproot is going to make a hardfork and jump ship to that, and this leads to less conflict about Taproot because mostly, only the people who want to use it will be left.

This pretty much forces a minority hardfork by tying future bugfixes and patches to Taproot activation. The only problem I see is exchanges and web wallets not migrating to Taproot making it inconvenient for all their users who want to use e.g bc1p addresses just like the ones that to this day don't let you receive from native segwit addresses.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html

background: link to Taproot Proposal thread


tl;dr, luke is writing code for activating soft forks in Bitcoin, and he thinks it was a mistake to make an option for the new soft fork code for Taproot to lock-in automatically (this happens if miners don't signal to activate before the fork's activation time limit is over.)

I agree. If there's a mix of nodes signalling to activate (LOT=true) and not signalling (LOT=false), a wide variety of problems can occur, especially if miners activate without paying attention to what other nodes are signalling. For that reason, miners might take the safe option of _not_ activating, assuming they don't want chaos. The other way to look at it is that some miners might like some temporary chaos, as it gives them or any friends of theirs with spare fiat to buy any market dip caused by said chaos.

The potential for chaos if people can choose which LOT they want is pretty high. It's both possible, and possible to exploit. So, I agree with luke. Stability, of every facet, should be the paramount concern.


The subtext to most arguments revolving around this issue is:

• 1. let people decide for themselves
• 2. we must be sure that they know and understand what they have chosen

Point 1 is easy. Point 2 is hard, and probably not realistic.

But I disagree with the idea that pushing out LOT=true with Bitcoin 0.21.1 is somehow forcing users into something they didn't want.


Everyone is responsible for understanding what's in the Bitcoin software they run (and for all software they run). Significant numbers of people don't pay any attention though, and that's unlikely to change much before or immediately after Bitcoin 0.21.1 is released (although I'd argue that the trend for being more conscious of "what's in my software" is increasing).

---

So the decision seems easy to me:

• Release Bitcoin 0.21.1 with LOT=true, no option to configure it
• Running 0.21.1 or not becomes the choice as to whether the soft fork activates

This way, all potential chain forking chaos is avoided, and most of the drama will be neutralized.

Don't like Taproot? Then don't run Bitcoin 0.21.1, and you can try to convince others to do the same. It's simple to understand, and if people don't understand it, then making the options more complicated is a perfect recipe for making the situation much, much worse.


Thread rules: No trolling, no trolls