Takeaways from the 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 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.

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

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

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

@pete @georgevaccaro @rusty I know you like to be a lil controversial Pete but I'm hoping bitcoin.con was a typo...


@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 I stand by my statement. You were loudest, but not in the majority.

@rusty There was no polling to determine majority from.

@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!).

@rusty @lukedashjr It's a UASF not a DASF anyway, metrics gathered in a dev meeting are meaningless.

@kekcoin @rusty @lukedashjr You are welcome to collect your own data. There were mining pool representatives at the meeting and some non-devs (developers are users too btw) It was by no means perfect but it wasn't "meaningless" either, it gives some (limited) signal.

@kekcoin @rusty @lukedashjr Personally I'm much less concerned on ensuring watertight consensus over activation parameters. The high bar for consensus on having the soft fork in the first place and what is in the soft fork is the most important thing imo.

@michaelfolkson @rusty @lukedashjr It's heavily biased for various reasons. Mining pool operators being "representatives" for miners is a bug, not a feature.

@kekcoin @rusty @lukedashjr Ok. As I said if you want to collect your own data that is less biased you are very welcome. I suspect you will find some apathy among those who aren't engaged with the technical detail but I would be interested to find out.

@kekcoin @rusty @lukedashjr I don't know why if you are a non-dev but have views on activation parameters why you wouldn't join a meeting on it and express them there. 🤷‍♂️

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

@kekcoin @rusty @lukedashjr Ok. Again I'm not claiming it was any way in perfect. What are your personal views on the activation parameters so I can add it to the (potentially flawed) sample? Presumably you agree with Luke and want LOT=true?

@kekcoin @rusty @lukedashjr I just want to make progress towards a decision on activation parameters. I don't think it benefits anyone to not activate Taproot for months/years(?) because we aren't sure what the consensus is on an activation parameter.

@michaelfolkson @kekcoin @rusty LOT=false is literally "not activate Taproot for over a year"...

@lukedashjr @kekcoin @rusty Only over a year if miners don't activate it within that year. Of course that possibility is open with LOT=false.

@michaelfolkson @kekcoin @rusty LOT only matters at all if miners don't activate it. It makes no sense to talk about LOT in the context of miners doing so.

@michaelfolkson @rusty @lukedashjr Already gave my opinion in another part of the original thread, but I'll repeat for visibility.

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.

@kekcoin @rusty @lukedashjr belcher points out on IRC that "if needed there are other irc networks which support tor e.g. darkscience IRC and hackint IRC"

@kekcoin @michaelfolkson @rusty a) How not? It was announced weeks ago, and I tweeted about it (here too) several times...

b/c) freenode staff were not involved.

@michaelfolkson @rusty @lukedashjr I don't have a better way to collect data, but I can still point out that you probably did not reach a representative sample set (both in bias and sample size) to base any sort of analysis on.

@kekcoin @michaelfolkson @rusty Miners aren't relevant in this in the first place.

Not to mention it's a safeguard against miners. It makes no sense to ask the hired security if they should get to be CEO too.

@michaelfolkson @kekcoin @rusty The only thing it told us was that there was no consensus yet.

Sign in to participate in the conversation
Bitcoin Mastodon

Bitcoin Maston Instance