On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote: > On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <a...@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.
I mean, I've already spent a lot of time thinking through these worst cast scenarios, including the ones you bring up. Maybe I've come up with wrong or suboptimal conclusions about it, and I'm happy to discuss that, but it's a bit hard to avoid taking offense at the suggestion that I haven't even thought about it. In the case of taproot, the final substantive update to the BIP was PR#982 merged on 2020-08-27 -- so even if you'd only been opposed to the changes in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to raise those concerns before the code implementing taproot was merged, and 6 months to raise those concerns before activation parameters were set. If you'd been following the discussion outside of the code and BIP text, in the case of 32B pubkeys, you'd have had an additional 15 months from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you only follow optech's summaries) until it was included in the BIP. > 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. Perhaps there's no opposition until the change has been deployed and in wide use for 30 years. Aborting activation isn't the be-all and end-all of addressing problems with a proposal, and it's not going to be able to deal with every problem. For any problems that can be found before the change is deployed and in use, you want to find them while the proposal is being discussed. More broadly, what I don't think you're getting is that *any* method you can use to abort/veto/revert an activation that's occuring via BIP8 (with or without mandatory activation), can also be used to abort/veto/revert a speedy trial activation. Speedy trial simply changes two things: it allows a minority (~10%) of hashpower to abort the activation; and it guarantees a "yes" or "no" answer within three months, while with BIP343 you initially don't know when within a ~1 year period activation will occur. If you're part of an (apparent) minority trying to abort/veto/reject activation, this gives you an additional option: if you can get support from ~10% of hashpower, you can force an initial "no" answer within three months, at which point many of the people who were ignoring your arguments up until then may be willing to reconsider them. For example, I think Mark Friedenbach's concerns about unhashed pubkeys and quantum resistance don't make sense, and (therefore) aren't widely held; but if 10% of blocks during taproot's speedy trial had included a tagline indicating otherwise and prevented activation, that would have been pretty clear objective evidence that the concern was more widely held than I thought, and might be worth reconsidering. Likewise, there could have somehow been other problems that somehow were being ignored, that could have similarly been reprioritised in the same way. That's not the way that you *want* things to work -- ideally people should be raising the concerns beforehand, and they should be taken seriously and fixed or addressed beforehand. That did happen with Mark's concerns -- heck, I raised it as a question ~6 hours after Greg's original taproot proposal -- and it's directly addressed in the rationale section of BIP341. But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and other places are somehow being censored, or sensible critics are being demonised and ignored. The advantage of a hashrate veto here is that it's hard to fake and hard to censor -- whereas with mailing list messages and the like, it's both easy to fake (setup sockpuppets and pay troll farms) and easy to censor (ban/moderate people for spamming say). So as a last ditch "we've been censored, please take us seriously" method of protest, it seems worthwhile to have to me. (Of course, a 90% majority might *still* choose to not take the concerns of the 10% minority seriously, and just continue to ignore the concern and followup with an immediate mandatory activation. But if that's what happening, you can't stop it; you can't only choose whether you want to be a part of it, or leave) Another example: if we'd had a 3-month speedy trial for segwit, that would presumably have run from 2016-11-15 to 2017-02-15, and been successfully blocked by people objecting to segwit activation. That would have left a clean slate for either a simple and safe BIP149 style UASF activation of segwit (shaolinfry introduced the concept of "user activated softfork activation" in a post on 2017-02-25), or redesigning segwit to be compatible with covert ASICBoost (which Greg Maxwell revealed publicly on 2017-04-05, after apparently realising the potential interaction with segwit a month earlier) and retrying segwit activation with that approach via a new speedy trial later in the year. > > 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. The question that comment was addressing wasn't whether BIP148 was a good idea, it was how quickly users can coordinate a software update to respond to consensus rules heading in a direction they find unacceptable. All the risk and potential for disaster was due to the goals of BIP148: to get segwit locked in prior to its activation timeout in Nov 2017, even if only supported by a minority of hashrate. > > 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. Futures markets measure people's beliefs weighted by wealth and confidence; and unlike with hashrate signalling there's a real cost to lying/being wrong. They're certainly not perfect, but nothing is. > 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. 2x and BCH were two different things. For BCH, the only futures market was run by viabtc (one of the main advocates of BCH), was only available a week before the split, and was (I think?) only available to Chinese investors (at least, it was only traded against CNY). Nevertheless, the price stabilised at around $300USD equivalent (0.1 BTC) prior to the split, and that was fairly in line with the spot price after the split had occurred. That price dropped during the next two weeks to ~0.07 BTC, then rose to ~0.2 BTC, and has since dropped to ~0.008 BTC. Coincidentally that's about $300USD in today's market, so if you're pricing things in USD, the futures market was actually weirdly accurate. Viabtc also launched a market for BIP148, though in addition to the problems with its BCH market, it was pretty unusable in that if the BIP148-valid chain was the most-work chain, the BIP148 token wouldn't be redeemed. But the 2x market I was thinking of was bitfinex's; afaik bitfinex is reasonably unbiased, the market was fairly accessible and could be traded against the USD, and it was open for a month before the question of 2x was definitevely resolved. The discovered price was about 0.2 BTC up until it was announced that 2x was being abandoned at which point it dropped to something like 0.02 BTC, representing holding costs until the market was finalised about 2 months later. > > 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. I don't agree. The BCH futures market accurately predicted the rewards (and hence hashrate) for mining BCH in the first couple of weeks after the split. On the same basis, the 2x futures market predicted that mining the 2x chain would be massively unprofitable: immediately after the split, both the 2x chain and the original-rules chain would have the same difficulty and hence have the same expected cost to mine a block; but the 2x chain would only have 25% of the reward (0.2 vs 0.8 valuation per the futures market). Without someone subsidising the first 2016 blocks on the 2x chain to the tune of about ~15,000 pre-split bitcoin (or ~75,000 post-split 2x coins; or between $80M-$150M USD), either directly, or by mining at an economic loss, the 2x chain could only collapse. BCH avoided that fate by having a new difficulty adjustment algorithm that allowed the difficulty to drop immediately, rather than only on the next 2016 block boundary. > 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. If it's an either-or choice, it's likely that 99.9% of hashrate will switch even if the rewards are only 0.1 times more valuable (or 1.1 times as valuable if you prefer). That's why you run a futures market, to figure out which will be more valuable and by how much. We saw the either-or case happen with BCH vs BTC; the difficulty of BCH would drop quickly due to the "EDA", but only rise slowly, making BCH mining more profitable for an extended period so that opportunistic miners would switch to BCH for a while until it got expensive again then switch back to BTC, causing both chains' hashrate to be unstable. But if you don't hard fork to a different difficulty adjustment algorithm the way BCH did on day one, then it doesn't matter how long miners don't mine on your chain, your chain's difficulty won't adjust, and so you'll need to instead wait until BTC's difficulty doubles or more, or its reward halves or more, or some combination of the two. That's likely much more than 3 months away. I can't imagine why anyone would still care about your proposed chain months or years later. So hardforking in merge-mining (so it's not an either-or question) or a new difficulty adjustment algorithm (so you don't have to wait months or years) seems a much more realistic approach. > > 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. *shrug* Do what you like (and I mean, I don't trade in futures markets either) but I think you'd be missing out on very useful information, and losing a chance for people who aren't devs to offer tangible and objective support for your cause. > > 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. If we're talking about consensus changes, the target is 100% of hashpower, and also something approaching 100% of nodes. By comparison 10% of hashpower is *much* cheaper, especially when the 100% have to actively upgrade in order to support, while the 10% just have to not do anything in order to oppose. To be clear: You don't have to setup the 10% of hashpower yourself, you just have to convince the existing owners of 10% of hashpower to not actively support the change. > > 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. The BIP8 spec we have today is very different to the BIP8 spec when taproot was merged, let alone before it was even proposed. As it was, it had serious problems that hadn't been addressed, and the version we have today likewise has significant problems that haven't been addressed, which is why it wasn't and shouldn't be merged. > Updating software is certainly not more expensive than getting 10% of > the hashrate. Updating software (or not updating software) is precisely *how* to get 10% of hashrate. It's not more or less expensive -- it *is* the expense. > > 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. Yes; you then move to the next step knowing that what level of interest/support you actually have. > > 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? If it's other people that lack information, there's two options. One, you might be able to explain things to them, so that they learn and gain the information. The other is that for whatever reason they're not willing to listen to the truth and will remain ignorant. If it's the first case, you'd have succeeded in an earlier step. If it's the latter, then it's not something you can change, and it doesn't really matter in how you decide what to do next. > 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. It's extremely unhelpful to call things "evil" if what you want is a reasonable discussion. And if reasonable discussion isn't what you want, you're in the wrong place. At this point in the hypothetical you're in a small minority, and have been unable to convince people of your point of view. Calling the people you disagree with "evil" (and saying they support something that's evil is exactly that) isn't going to improve your situation, and doing it in a hypothetical sure feels like bad faith. > 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". If it's an evil change, then good people will oppose it. You've tried convincing devs in the "discuss the proposal" stage, whales in the "futures market" stage, and miners in the "hashpower signalling" phase, and failed each time because the good people in each of those groups haven't opposed it. So yes, I think the most likely explanation is that you're wrong in thinking it's evil. But hey what about the worst case: what if everyone else in bitcoin is evil and supports doing evil things. And maybe that's not even implausible: maybe it's not an "evil" thing per se, perhaps it's simply equally "misguided" as the things that central banks or wall street or similar are doing today. Perhaps bitcoin becomes the world currency, and in 100 or 200 years time, whether through complacency and forgetting the lessons of the past, or too much adherence to dogma that no longer matches reality, or just hitting some new problem that's never been seen before and an inability to perfectly predict the future, and as a result most of the world opts into some change that will cause bitcoin to fail. In that scenario, I think a hard fork is the best choice: split out a new coin that will survive the upcoming crash, adjust the mining/difficulty algorithm so it works from day one, and set it up so that you can maintain it along with the people who support your vision, rather than having to constantly deal with well-meaning attacks from "bitcoiners" who don't see the risks and have lost the plot. Basically: do what Satoshi did and create a better system, and let everyone else join you as the problems with the old one eventually become unavoidably obvious. > But that contradicts the premise: an evil change being deployed using > speedy trial. Again: any change that could be avoided if it were deployed via BIP8, can also be avoided *by the exact same techniques* if it were deployed via speedy trial or a similar approach. > > 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. The value of the subsidy is something you can directly figure out from running a futures market; and unless you're deliberately subsidising fees, they'll almost certainly be ~0. > > (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. I think you're reading too much precision into those numbers? When I looked again the other day, I got a figure of 0.66%; today I get 0.75%. I'm sure I rounded whatever figure I saw to one significant figure, so it might have been 0.75% then too. https://bitinfocharts.com/comparison/bitcoin-hashrate.html#3y https://bitinfocharts.com/comparison/bitcoin%20cash-hashrate.html#3y > In perfect competition and leaving fees aside (in which probably > bitcoin wins too), BCH should have approximately 0.0073% the hashrate > bitcoin hash. Oh, or you're just getting the percentage conversion wrong -- 0.0073 BTC is 0.73% of a BTC, and thus it would be expected to have about 0.73% of the hashrate. > > 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. Of course; that's why option (1) is to talk to people about why it's a bad idea so it doesn't get proposed in the first place. But if you want to resist a consensus change that is overwhelmingly supported by the rest of the bitcoin economy, and for which your reasons aren't even considered particularly logical by everyone else, then yeah, if you really want to go off on your own because everyone else is wrong, you *should* do a hardfork. If a change doesn't have overwhelming support, then hopefully the costs to get 90% of hashrate signalling is a significant impediment. If you do have overwhelming support, then the cost to get 90% of hashrate signalling (or even apparently 99.8%, see getdeploymentinfo on block 693503) -- doesn't seem to be too bad. > "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". (Arguing semantics: You can't do the split at exactly the same time, because the split starts with each chain finding a new block, and blocks are found probabilistically depending on hashrate, so they won't be found at the same time. Or, alternatively, the split happens whenever either client considers the other chain invalid, and always happens at the "same" time) If you want to do things at exactly the same height, you can do that if the soft fork is activated by speedy trial as well. I'd say the same height approach works better on speedy trial than with BIP8/BIP343, since with speedy trial signalling is only for a short period, and hence you know well in advance if and when you'll be splitting, whereas with an extended signalling period that goes for a year past the minimum activation height, you may find yourself splitting at any point in that year with as little as two week's notice. If I were doing a hardfork coin split to avoid following some new soft forked rules that I think were horrible, I think I'd prefer to do the split in advance of the softfork -- that way exchanges/wallets/lightning channels/etc that have to do work to deal with the coinsplit aren't distracted by simultaneously having to pay attention to the new softfork. YMMV of course. > 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? No, exactly the opposite. In order to abort a BIP8 activation, 100% of hashpower and 100% of node software needs to downgrade from anything that specifies BIP8 with mandatory activation. The "berkelyDB thing" was an accidental hard fork due to the updated software with leveldb being able to accept larger blocks than the old bdb-based bitcoind could. The result was two chains: one with a large block in it, that could only be validated by the newer software, and a less work chain with only smaller chains, that could be validated by both versions of the software; the problem was ~60% of hashpower was on the larger-block chain, but many nodes including those with ~40% hashpower. The problem was quickly mitigated by encouraging a majority of hashpower to downgrade to the old software, resulting in them rejecting the larger-block chain, at which point a majority of hashpower was mining the smaller-block chain, and the smaller-block chain eventually having more work than the larger-block chain. At that point any newer nodes reorged to the more-work, smaller-block chain, and everyone was following the same chain. What that means is that the operators of *two* pools downgraded their software, and everything was fixed. That's a *lot* less work than everyone who upgraded their node having to downgrade/re-update, and it was done that way to *avoid* having to rush to get everyone to do an emergency update of their node software to be compatible with the larger-block chain. See https://bitcoin.org/en/alert/2013-03-11-chain-fork and https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki On the other hand, that approach only works because it takes advantage of a lot of hashrate being centralised around a few pools; if we succeed in making block construction more decentralised, solutions here will only become harder. > If there's only opposition after it is deployed, whatever the > activation mechanism, in that particular case, would be irrelevant. Once you've released software with a softfork activated via BIP8 with mandatory activation (ie, lot=true), and it has achieved any significant adoption, the soft fork is already deployed and you need to treat it as such. If you want to have an easier way of undoing the softfork than you would have for one that's already active on the network, you need a different activation method than BIP8/lot=true. Cheers, aj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
