Jorge Tim贸n [ARCHIVE] on Nostr: 馃搮 Original date posted:2022-03-17 馃摑 Original message:On Tue, Mar 15, 2022 at ...
馃搮 Original date posted:2022-03-17
馃摑 Original message:On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj at erisian.com.au> wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Tim贸n via bitcoin-dev wrote:
> People opposed to having taproot transactions in their chain had over
> three years to do that coordination before an activation method was merged
> [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
>
> [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> trial activation parameters for mainnet and testnet were merged.
> [1] 2021-11-14
People may be opposed only to the final version, but not the initial
one or the fundamental concept.
Please, try to think of worse case scenarios.
Perhaps there's no opposition until after activation code has been
released and miners are already starting to signal.
Perhaps at that moment a reviewer comes and points out a fatal flaw.
> For comparison, the UASF activation attempt for segwit took between 4
> to 6 months to coordinate, assuming you start counting from either the
> "user activated soft fork" concept being raised on bitcoin-dev or the
> final params for BIP 148 being merged into the bips repo, and stop
> counting when segwit locked in.
That was extremely risky and could have been a disaster. It went well,
but in my opinion a BIP8 approach from the beginning would have been
much less risky. Instead of improvising these things we should plan
ahead. But for "user forced" activations and for "user forced"
rejections.
Just remember you may reject your own code.
> > Please, try to imagine an example for an activation that you wouldn't like
> > yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
> Sure. There's more steps than just "fork off onto a minority chain"
> though.
>
> 1) The first and most important step is to explain why you want to
> resist it, either to convince the proposers that there really is
> a problem and they should stand down, or so someone can come up
> with a way of fixing the proposal so you don't need to resist it.
> Ideally, that's all that's needed to resolve the objections. (That's
> what didn't happen with opposition to segwit)
Agreed, for any given proposal, the first approach should be rational
discussion.
Some times we consider other arguments irrational simply because we
don't understand them though.
> 2) If that somehow doesn't work, and people are pushing ahead with a
> consensus change despite significant reasonable opposition; the next
> thing to do would be to establish if either side is a paper tiger
> and setup a futures market. That has the extra benefit of giving
> miners some information about which (combination of) rules will be
> most profitable to mine for.
>
> Once that's setup and price discovery happens, one side or the other
> will probably throw in the towel -- there's not much point have a
> money that other people aren't interested in using. (And that more
> or less is what happened with 2X)
Future markets can be manipulated.
Regarding 2x, that's not how I remember it. If I remember correctly,
"discovered" a price in btc for bcash that was
orders of magnitude higher than what it is today.
> If a futures market like that is going to be setup, I think it's
> best if it happens before signalling for the soft fork starts --
> the information miners will get from it is useful for figuring out
> how much resources to invest in signalling, eg. I think it might even
> be feasible to set something up even before activation parameters are
> finalised; you need something more than just one-on-one twitter bets
> to get meaningful price discovery, but I think you could probably
> build something based on a reasonably unbiassed oracle declaring an
> outcome, without precisely defined parameters fixed in a BIP.
Whatever miners signal, until there are two chains and their real
rewards can be traded, it's hard to know what they will mine
afterwards.
They could signal a change with 100% and then after it is activated on
one chain and resisted on another, they 95% of them may switch to the
old chain simply because its rewards are 20 times more valuable. This
may happen 3 days after activation or 3 months, or more.
It could depend on how fast some relevant information about the new
change spreads.
Which is specially hard to estimate in a censored world like ours.
> So if acting like reasonable people and talking it through doesn't
> work, this seems like the next step to me.
Not to me, but you're free to create your future markets or trade in them.
I wouldn't do any of them, and I would advice against it.
> 3) But maybe you try both those and they fail and people start trying
> to activate the soft fork (or perhaps you just weren't paying
> attention until it was too late, and missed the opportunity).
Yes, some changes may be rejected late because some people weren't
paying attention or weren't paid attention, indeed.
Or perhaps it's your own proposal and you realize it is flawed
yourself. There are infinite hypothetical scenarios we could consider
for this to happen.
> I think the speedy trial approach here is ideal for a last ditch
> "everyone stays on the same chain while avoiding this horrible change"
> attempt. The reason being that it allows everyone to agree to not
> adopt the new rules with only very little cost: all you need is for
> 10% of hashpower to not signal over a three month period.
No, 10% of hashpower is not "very little cost", that's very expensive.
> That's cheaper than bip9 (5% over 12 months requires 2x the
> cumulative hashpower), and much cheaper than bip8 which requires
> users to update their software
Updating software is not expensive. the code for bip8 could have been
merged long before taproot was even initially proposed.
It could be merged now before another proposal.
Updating software is certainly not more expensive than getting 10% of
the hashrate.
> 4) At this point, if you were able to prevent activation, hopefully
> that's enough of a power move that people will take your concerns
> seriously, and you get a second chance at step (1). If that still
> results in an impasse, I'd expect there to be a second, non-speedy
> activation of the soft fork, that either cannot be blocked at all, or
> cannot be blocked without having control of at least 60% of hashpower.
And if you never got 10% hashpower, we move to the next step, I guess.
> 5) If you weren't able to prevent activation (whether or not you
> prevented speedy trial from working), then you should have a lot
> of information:
>
> - you weren't able to convince people there was a problem
>
> - you either weren't in the economic majority and people don't
> think your concept of bitcoin is more valuable (perhaps they
> don't even think it's valuable enough to setup a futures market
> for you)
>
> - you can't get control of even 10% of hashpower for a few months
>
> and your only option is to accept defeat or create a new chain.
What if it's still the other people who are lacking information?
It wouldn't be a new chain, it would be the old chain without the new
evil change, until you manage to show the other people that the change
was indeed evil.
Remember, in this example, the new change being evil is not a
possibility, but an assumption.
What you're arguing is "if you haven't been able to stop the evil
change, then perhaps it wasn't evil all along and the people trying to
resist it were wrong and don't know it".
But that contradicts the premise: an evil change being deployed using
speedy trial.
> Since your new chain won't have a hashpower majority, you'll likely
> have significant problems if you don't hard fork in a change to
> how proof-of-work works; my guess is you'd either want to switch
> to a different proof-of-work algorithm, or make your chain able
> to be merge-mined against bitcoin, though just following BCH/BSV's
> example and tweaking the difficulty adjustment to be more dynamic
> could work too.
No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.
A better difficulty update filter and merge mining could help you, I
guess. But that could be a threat on its own.
Also, as pointed out earlier, "mining majority" is dynamic and depends
on the rewards.
> (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> merge-mining, are apparently at 68%, 42% and 17% respectively)
Google tells me 0.0073BTC.
In perfect competition and leaving fees aside (in which probably
bitcoin wins too), BCH should have approximately 0.0073% the hashrate
bitcoin hash. This tells me someone who likes BCH is throwing money
away to subsidize its security.
Or perhaps it's something else I'm not taking into account or your
estimate is wrong.
But BCH having 0.8% of bitcoin's hashrate sounds like too much to me.
And yet, what did your future markers "discovered" pre hard fork?
> At the point that you're doing a hard fork, making a clean split is
> straightforward: schedule the hard fork for around the same time as
> the start of enforcement of the soft fork you oppose, work out how
> to make sure you're on your own p2p network, and figure out how
> exchanges and lightning channels and everything else are going to
> cope with the coin split.
You shouldn't need to do a hardfork to resist a consensus change you don't like.
"around the same time", with bip8 and the resistance mechanism
proposed by luke, it doesn't need to be "around the same time
according to some expert who will tell you what to put in your
software", but "exactly at the same time, and you only need to know
which pproposal version bit you're opposing".
> 6) There's potentially also the case where a soft fork locks-in
> and later everyone realises the people who were opposing it were
> right all along and the fork is a really bad idea.
>
> If everyone agreed that some idea was irredeemably bad -- eg,
> OP_VERIF -- then we could soft fork them out and just forbid
> blocks/transactions that attempt to use them. Or conceivably we could
> do a hardfork and have more options about how to fix the problem.
Yeah, great example. It doesn't have to be an "evil change" as such,
it can just be a "deeply wrong change" or something.
Or if we were using BIP8 and had the resistance mechanism proposed by
luke, all we would need to do is change one line and recompile:
I don't remember his enumeration constants but, something like...
- bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
+ bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;
Say we discover it 3 days before forced activation.
Well, that would still be much less rushed that the berkeleyDB thing,
wouldn't it?
As you point out, after activation it is much more painful to fix
things. In some cases a hardfork may be the best solution a
posteriori, but I guess that gets out of the scope for activation
mechanisms.
If there's only opposition after it is deployed, whatever the
activation mechanism, in that particular case, would be irrelevant.
Whatever evil change it was, we would have probably swallowed whatever
the activation mechanism, because we only thought it evil or wrong a
posteriori.
Published at
2023-06-07 23:06:14Event JSON
{
"id": "74d3b2a6fe5b31ffa36072fba6cb34c3ba6b4252f6ea7b50b86966ac4051c192",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179174,
"kind": 1,
"tags": [
[
"e",
"a5af5e39047c2302ef2c813ca29b2c17152d49444d282becfeb36106acf5ee47",
"",
"root"
],
[
"e",
"ec8e514cb3f822c9f3ae33452e60fac3c89f8607828241014c452cb696fc7cce",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "馃搮 Original date posted:2022-03-17\n馃摑 Original message:On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e\n\u003e On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Tim贸n via bitcoin-dev wrote:\n\u003e People opposed to having taproot transactions in their chain had over\n\u003e three years to do that coordination before an activation method was merged\n\u003e [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].\n\u003e\n\u003e [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy\n\u003e trial activation parameters for mainnet and testnet were merged.\n\u003e [1] 2021-11-14\n\nPeople may be opposed only to the final version, but not the initial\none or the fundamental concept.\nPlease, try to think of worse case scenarios.\nPerhaps there's no opposition until after activation code has been\nreleased and miners are already starting to signal.\nPerhaps at that moment a reviewer comes and points out a fatal flaw.\n\n\u003e For comparison, the UASF activation attempt for segwit took between 4\n\u003e to 6 months to coordinate, assuming you start counting from either the\n\u003e \"user activated soft fork\" concept being raised on bitcoin-dev or the\n\u003e final params for BIP 148 being merged into the bips repo, and stop\n\u003e counting when segwit locked in.\n\nThat was extremely risky and could have been a disaster. It went well,\nbut in my opinion a BIP8 approach from the beginning would have been\nmuch less risky. Instead of improvising these things we should plan\nahead. But for \"user forced\" activations and for \"user forced\"\nrejections.\nJust remember you may reject your own code.\n\n\u003e \u003e Please, try to imagine an example for an activation that you wouldn't like\n\u003e \u003e yourself. Imagine it gets proposed and you, as a user, want to resist it.\n\u003e\n\u003e Sure. There's more steps than just \"fork off onto a minority chain\"\n\u003e though.\n\u003e\n\u003e 1) The first and most important step is to explain why you want to\n\u003e resist it, either to convince the proposers that there really is\n\u003e a problem and they should stand down, or so someone can come up\n\u003e with a way of fixing the proposal so you don't need to resist it.\n\u003e Ideally, that's all that's needed to resolve the objections. (That's\n\u003e what didn't happen with opposition to segwit)\n\nAgreed, for any given proposal, the first approach should be rational\ndiscussion.\nSome times we consider other arguments irrational simply because we\ndon't understand them though.\n\n\u003e 2) If that somehow doesn't work, and people are pushing ahead with a\n\u003e consensus change despite significant reasonable opposition; the next\n\u003e thing to do would be to establish if either side is a paper tiger\n\u003e and setup a futures market. That has the extra benefit of giving\n\u003e miners some information about which (combination of) rules will be\n\u003e most profitable to mine for.\n\u003e\n\u003e Once that's setup and price discovery happens, one side or the other\n\u003e will probably throw in the towel -- there's not much point have a\n\u003e money that other people aren't interested in using. (And that more\n\u003e or less is what happened with 2X)\n\nFuture markets can be manipulated.\nRegarding 2x, that's not how I remember it. If I remember correctly,\n\"discovered\" a price in btc for bcash that was\norders of magnitude higher than what it is today.\n\n\u003e If a futures market like that is going to be setup, I think it's\n\u003e best if it happens before signalling for the soft fork starts --\n\u003e the information miners will get from it is useful for figuring out\n\u003e how much resources to invest in signalling, eg. I think it might even\n\u003e be feasible to set something up even before activation parameters are\n\u003e finalised; you need something more than just one-on-one twitter bets\n\u003e to get meaningful price discovery, but I think you could probably\n\u003e build something based on a reasonably unbiassed oracle declaring an\n\u003e outcome, without precisely defined parameters fixed in a BIP.\n\nWhatever miners signal, until there are two chains and their real\nrewards can be traded, it's hard to know what they will mine\nafterwards.\nThey could signal a change with 100% and then after it is activated on\none chain and resisted on another, they 95% of them may switch to the\nold chain simply because its rewards are 20 times more valuable. This\nmay happen 3 days after activation or 3 months, or more.\nIt could depend on how fast some relevant information about the new\nchange spreads.\nWhich is specially hard to estimate in a censored world like ours.\n\n\u003e So if acting like reasonable people and talking it through doesn't\n\u003e work, this seems like the next step to me.\n\nNot to me, but you're free to create your future markets or trade in them.\nI wouldn't do any of them, and I would advice against it.\n\n\u003e 3) But maybe you try both those and they fail and people start trying\n\u003e to activate the soft fork (or perhaps you just weren't paying\n\u003e attention until it was too late, and missed the opportunity).\n\nYes, some changes may be rejected late because some people weren't\npaying attention or weren't paid attention, indeed.\nOr perhaps it's your own proposal and you realize it is flawed\nyourself. There are infinite hypothetical scenarios we could consider\nfor this to happen.\n\n\u003e I think the speedy trial approach here is ideal for a last ditch\n\u003e \"everyone stays on the same chain while avoiding this horrible change\"\n\u003e attempt. The reason being that it allows everyone to agree to not\n\u003e adopt the new rules with only very little cost: all you need is for\n\u003e 10% of hashpower to not signal over a three month period.\n\nNo, 10% of hashpower is not \"very little cost\", that's very expensive.\n\n\u003e That's cheaper than bip9 (5% over 12 months requires 2x the\n\u003e cumulative hashpower), and much cheaper than bip8 which requires\n\u003e users to update their software\n\nUpdating software is not expensive. the code for bip8 could have been\nmerged long before taproot was even initially proposed.\nIt could be merged now before another proposal.\nUpdating software is certainly not more expensive than getting 10% of\nthe hashrate.\n\n\u003e 4) At this point, if you were able to prevent activation, hopefully\n\u003e that's enough of a power move that people will take your concerns\n\u003e seriously, and you get a second chance at step (1). If that still\n\u003e results in an impasse, I'd expect there to be a second, non-speedy\n\u003e activation of the soft fork, that either cannot be blocked at all, or\n\u003e cannot be blocked without having control of at least 60% of hashpower.\n\nAnd if you never got 10% hashpower, we move to the next step, I guess.\n\n\u003e 5) If you weren't able to prevent activation (whether or not you\n\u003e prevented speedy trial from working), then you should have a lot\n\u003e of information:\n\u003e\n\u003e - you weren't able to convince people there was a problem\n\u003e\n\u003e - you either weren't in the economic majority and people don't\n\u003e think your concept of bitcoin is more valuable (perhaps they\n\u003e don't even think it's valuable enough to setup a futures market\n\u003e for you)\n\u003e\n\u003e - you can't get control of even 10% of hashpower for a few months\n\u003e\n\u003e and your only option is to accept defeat or create a new chain.\n\nWhat if it's still the other people who are lacking information?\nIt wouldn't be a new chain, it would be the old chain without the new\nevil change, until you manage to show the other people that the change\nwas indeed evil.\nRemember, in this example, the new change being evil is not a\npossibility, but an assumption.\nWhat you're arguing is \"if you haven't been able to stop the evil\nchange, then perhaps it wasn't evil all along and the people trying to\nresist it were wrong and don't know it\".\nBut that contradicts the premise: an evil change being deployed using\nspeedy trial.\n\n\u003e Since your new chain won't have a hashpower majority, you'll likely\n\u003e have significant problems if you don't hard fork in a change to\n\u003e how proof-of-work works; my guess is you'd either want to switch\n\u003e to a different proof-of-work algorithm, or make your chain able\n\u003e to be merge-mined against bitcoin, though just following BCH/BSV's\n\u003e example and tweaking the difficulty adjustment to be more dynamic\n\u003e could work too.\n\nNo, I disagree. You'll just get the hashpower you pay for with subsidy and fees.\nA better difficulty update filter and merge mining could help you, I\nguess. But that could be a threat on its own.\nAlso, as pointed out earlier, \"mining majority\" is dynamic and depends\non the rewards.\n\n\u003e (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,\n\u003e BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support\n\u003e merge-mining, are apparently at 68%, 42% and 17% respectively)\n\nGoogle tells me 0.0073BTC.\nIn perfect competition and leaving fees aside (in which probably\nbitcoin wins too), BCH should have approximately 0.0073% the hashrate\nbitcoin hash. This tells me someone who likes BCH is throwing money\naway to subsidize its security.\nOr perhaps it's something else I'm not taking into account or your\nestimate is wrong.\nBut BCH having 0.8% of bitcoin's hashrate sounds like too much to me.\nAnd yet, what did your future markers \"discovered\" pre hard fork?\n\n\u003e At the point that you're doing a hard fork, making a clean split is\n\u003e straightforward: schedule the hard fork for around the same time as\n\u003e the start of enforcement of the soft fork you oppose, work out how\n\u003e to make sure you're on your own p2p network, and figure out how\n\u003e exchanges and lightning channels and everything else are going to\n\u003e cope with the coin split.\n\nYou shouldn't need to do a hardfork to resist a consensus change you don't like.\n\"around the same time\", with bip8 and the resistance mechanism\nproposed by luke, it doesn't need to be \"around the same time\naccording to some expert who will tell you what to put in your\nsoftware\", but \"exactly at the same time, and you only need to know\nwhich pproposal version bit you're opposing\".\n\n\u003e 6) There's potentially also the case where a soft fork locks-in\n\u003e and later everyone realises the people who were opposing it were\n\u003e right all along and the fork is a really bad idea.\n\u003e\n\u003e If everyone agreed that some idea was irredeemably bad -- eg,\n\u003e OP_VERIF -- then we could soft fork them out and just forbid\n\u003e blocks/transactions that attempt to use them. Or conceivably we could\n\u003e do a hardfork and have more options about how to fix the problem.\n\nYeah, great example. It doesn't have to be an \"evil change\" as such,\nit can just be a \"deeply wrong change\" or something.\nOr if we were using BIP8 and had the resistance mechanism proposed by\nluke, all we would need to do is change one line and recompile:\nI don't remember his enumeration constants but, something like...\n\n- bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;\n+ bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;\n\nSay we discover it 3 days before forced activation.\nWell, that would still be much less rushed that the berkeleyDB thing,\nwouldn't it?\nAs you point out, after activation it is much more painful to fix\nthings. In some cases a hardfork may be the best solution a\nposteriori, but I guess that gets out of the scope for activation\nmechanisms.\nIf there's only opposition after it is deployed, whatever the\nactivation mechanism, in that particular case, would be irrelevant.\nWhatever evil change it was, we would have probably swallowed whatever\nthe activation mechanism, because we only thought it evil or wrong a\nposteriori.",
"sig": "6bf57a21ad7ea0827006820312e1427e63ef0ca17852ae62bbf8928c6f6ae28b500de33ac49a36b93c25f82c75a0010e6ccc71c3d29f66bf49b2eb6a5f41518a"
}