Takeaways from the #taproot activation discussion:
1. Unanimous support for BIP8. RIP BIP 9.
2. Overwhelming consensus that 1yr is correct timeout value (it's actually defined in blocks, so 26x2016 or maybe 87600).
3. Majority consensus for lockin false, though @lukedashjr strongly opposed.
4. No decision I could see on start time, but 2 months was done for segwit, and that didn't seem too objectionable.

My opinions: BIP8 is designed to make a UASF easier, because it would activate the soft fork for non-UASF nodes.

I don't think it will come to that this time, but it's nice to have a robust method for future upgrades, too.

We use miners to co-ordinate the SF simply because they are the one group we can reliably measure without centralization. But this implies they might not co-ordinate! Last time, they did this for bad reasons, but it could also be for good ones. In particular, if a flaw or improvement were found before activation, they could kill activation.

Of course, at some point we need to commit, so you could argue an extra few months isn't worth it. But I'm conservative here.

If miners are stalling without good technical reasons at the 6 month mark, I will personally champion and run my nodes with 9 month lockin=true.

But that's making best of a bad situation. Having bitcoin ship with lockin=true feeds perception that devs de-facto control the protocol (defaults are *sticky*!). I consider that more dangerous, long term, than Taproot not activating easily.

@rusty

This is probably a ridiculous idea, but could there be an initialization script that asks the user what their preference is? A mandatory question but no default.

@georgevaccaro @rusty You could make it a required option in bitcoin.con/command line.

@pete @georgevaccaro @rusty So what? Ask users "Taproot or no?" But the whole premise of having activation in there is that the users have already decided...

@lukedashjr @georgevaccaro @rusty To be clear, by required option, I mean requiring users to make a choice.

@pete @georgevaccaro @rusty But the choice was already made, or the activation shouldn't be in there for anyone yet.

Follow

@lukedashjr @georgevaccaro @rusty Sorry, but I'm really not sure what you mean by "the choice was already made"

· · Web · 1 · 0 · 1

@pete @georgevaccaro @rusty I mean deploying activation is a step AFTER the community has already decided to accept Taproot.

Non-activation is no longer on the table.

If we're still unsure, nobody should deploy any activation code until we are sure.

@lukedashjr @pete @georgevaccaro

Devs *think* they are sure, yes. But are they fooled, inside a bubble, have cognitive defects, be exploited or corrupt? Of course they made decisions every day, but keystone ones require safeguards.

Users accept the SF by upgrading (or not).

Miners signal accepting the SF by version bits (or not).

These both help measure and reinforce consensus.

Devs should enable *users* to override miner signalling. Users need to be prepared to seize their legitimacy!

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!