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.
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 I would have been in favour of lot=true by default if it wasn't for that last point. It should be a command line parameter/config value. False by default, but easy to enable. Making it "configurable" by re-compiling doesn't work, as that is non-trivial even for technical users.
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.
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!
@rusty Activation should only be deployed AFTER the decision has already been made.
If we're not as a community already certain on Taproot, then discussion of activation methods is premature.
So no, it does not honestly feed the perception of dev control.
@rusty Many people did support LOT=false, but many also supported LOT=true.
I don't think anyone gave much thought to a safe start time for Segwit... just assumed 2 months was fine.
@lukedashjr Again, I stand by my statement. Obviously, only people who were there and made a comment can be counted. That was what, 10:3 (on mobile, didn't actually recount sorry!).
@michaelfolkson @rusty @lukedashjr a) I didn't know it was happening, b) Freenode is not a neutral platform. It's not possible to use it purely via tor (account creation needs to happen via plainnet), the staff is subject to infiltration by adversaries (indications exist that this has already happened).
It's a UASF not a DASF, so ship Bitcoin Core with LOT = configurable by command line parameter or config file, default false. Making it "configurable" by re-compiling doesn't work, as that is non-trivial even for technical users.
Bitcoin Maston Instance