đ
Original date posted:2021-03-03
đ Original message:On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
> Enter flag day activation. With a flag day there can be no
> brinksmanship. A social media blitz cant do anything except have its
> own
> followers fork away. Crucially, miner signalling cant be used to change
> the activation date for nodes that didn't choose to and just passively
> follow signalling. Changing the activation date requires all those
> users
> to actually run different node software.
Is that supposed to be a good thing? "We should do X because it'll work"
doesn't prove X is actually good. These things can be evil, but they can
also be legitimate opposition to a change. Taking away the power of a
"social media blitz" is not guaranteed to be a good thing!
> What if one day the Core developer team uses the flag
> day method to do something bad? The bitcoin user
> community who wants to resist this can create their own
> counter-soft-fork full node. This forces a chain
> split. The real bitcoin which most people follow will be
> the chain without censorship.
[edited for brevity]
That will only work for really egregious changes. In practice, most
people will trust Core on all other (non-egregious) decisions, because
of the inertia inherent in disobeying them.
What you suggest may be an efficient way to ram taproot through, but is
it inherently good? Nothing is free. This seems like de-facto forcing
people to go along with you, because you're convinced you're right. In
this case, you are, but you'd be convinced you'd be right even if you
weren't so.
You're right in suggesting that it will work, but the reason why it will
work is because nobody wants to disobey Core. It seems immoral to
exploit this fact.
At least you shouldn't hard-code it and require dissenters to fork away.
I exhort you to consider making all this controversial stuff settings
that can be changed by RPC command or command-line flag; set the default
value sure, but requiring a fork to change it is, in my opinion,
oppressive.
(Also consider some compromise, such as ">95% miner support before flag
day or >33% on flag day")
Best wishes
Yanmaani
yanmaani at cock.li [ARCHIVE] /
npub13aâŚ9uc29
2023-06-07 18:29:55
in reply to nevent1qâŚpmzn
Author Public Key
npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29Published at
2023-06-07 18:29:55Event JSON
{
"id": "4eb276364aac1cf7e73a785540034621b72ea1f12eac25453fb5da7972643403",
"pubkey": "8f5bcf9ba2de88dd877a672f629a5c6a7bebbeda3fa51324521e03863d8fe094",
"created_at": 1686162595,
"kind": 1,
"tags": [
[
"e",
"06f81a4772cfd591a3ba851990b1b3701b74c7460ca0f5e45bb7dfe492b7e3a1",
"",
"root"
],
[
"e",
"317f2ffda15fd47f90125e7fa6e5083ccf8d8edb6cf75b88ce541991f2fda30c",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "đ
Original date posted:2021-03-03\nđ Original message:On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:\n\u003e Enter flag day activation. With a flag day there can be no\n\u003e brinksmanship. A social media blitz cant do anything except have its \n\u003e own\n\u003e followers fork away. Crucially, miner signalling cant be used to change\n\u003e the activation date for nodes that didn't choose to and just passively\n\u003e follow signalling. Changing the activation date requires all those \n\u003e users\n\u003e to actually run different node software.\n\nIs that supposed to be a good thing? \"We should do X because it'll work\" \ndoesn't prove X is actually good. These things can be evil, but they can \nalso be legitimate opposition to a change. Taking away the power of a \n\"social media blitz\" is not guaranteed to be a good thing!\n\n\u003e What if one day the Core developer team uses the flag\n\u003e day method to do something bad? The bitcoin user\n\u003e community who wants to resist this can create their own\n\u003e counter-soft-fork full node. This forces a chain\n\u003e split. The real bitcoin which most people follow will be\n\u003e the chain without censorship.\n\n[edited for brevity]\n\nThat will only work for really egregious changes. In practice, most \npeople will trust Core on all other (non-egregious) decisions, because \nof the inertia inherent in disobeying them.\n\nWhat you suggest may be an efficient way to ram taproot through, but is \nit inherently good? Nothing is free. This seems like de-facto forcing \npeople to go along with you, because you're convinced you're right. In \nthis case, you are, but you'd be convinced you'd be right even if you \nweren't so.\n\nYou're right in suggesting that it will work, but the reason why it will \nwork is because nobody wants to disobey Core. It seems immoral to \nexploit this fact.\n\nAt least you shouldn't hard-code it and require dissenters to fork away. \nI exhort you to consider making all this controversial stuff settings \nthat can be changed by RPC command or command-line flag; set the default \nvalue sure, but requiring a fork to change it is, in my opinion, \noppressive.\n\n(Also consider some compromise, such as \"\u003e95% miner support before flag \nday or \u003e33% on flag day\")\n\nBest wishes\nYanmaani",
"sig": "147971414d9856dd369b9b51995260d44816c242ced8c1e393a9316666ff6da6f479016058ebaa48c34e8be3972d9222a0c286cd00084b03ed6996f822ac0321"
}