On 4/7/21 01:01, Rusty Russell via bitcoin-dev wrote:
Ryan Grant <bitcoin-...@rgrant.org> writes:
On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Having deescalation in the strategy toolkit makes
Bitcoin stronger.
I don't believe that having a plan is brinkmanship or an escalation.
I strongly disagree with this characterization of ST, primarily because there just isn't the kind of agreement you seem
to be assuming. ST isn't a "lets not decide because we don't want to formulate a specific grand plan" its more of a
"lets not decide, because there are very strong, and very divergent viewpoints on what a specific grand plan can or
should look like, and something most people are ok with is better than nothing at all". Ultimately, there are a number
of possible directions a grand plan could go, and there appear to be at least several prominent (and likely many
non-prominent) individuals who would strongly disagree with any such plan, you and I likely among them :).
LOT=true does face the awkward question, but there are downsides:
- in the requirement to drop blocks from apathetic miners (although
as Luke-Jr pointed out in a previous reply on this list they have
no contract under which to raise a complaint); and
Surely, yes. If the users of bitcoin decide blocks are invalid, they're
invalid. With a year's warning, and developer and user consensus
against them, I think we've reached the limits of acceptable miner
apathy.
You say "developer and user consensus against them" here, but then go on to argue that its perfectly acceptable for only
a small subset of users to be required to do something below.
- in the risk of a chain split, should gauging economic majority
support - which there is zero intrinsic tooling for - go poorly.
Agreed that we should definitely do better here: in practice people
would rely on third party explorers for information on the other side of
the split. Tracking the cumulative work on invalid chains would be a
good idea for bitcoind in general (AJ suggested this, IIRC).
We already have a really, really great precedent for tracking economic majority, I'd argue we have great tooling here!
During Segwit2x, we had multiple futures and chain-split-tokens available, including the BitMex futures with billions of
dollars in daily volume! For the BCH split, ViaBTC issued similar chain split tokens.
At the end of the day, economic value is going to determine the amount of hashrate on any chain, and there is a very,
very strong incentive (trading fees!) for an exchange to list...more stuff, chainsplit tokens included.
Why do we need to build in really janky ways to measure economic majority when there's already a great one that
experience has shown us will prop up and provide reasonable signal, given any material demand.
Personally, I think the compromise position is using LOT=false and
having those such as Luke and myself continue working on a LOT=true
branch for future consideration. It's less than optimal, but I
appreciate that people want Taproot activated more than they want
the groundwork future upgrades.
Another way of viewing the current situation is that should
brinkmanship be necessary, then better tooling to resolve a situation
that requires brinkmanship will be invaluable. But:
- we do not need to normalize brinkmanship;
- designing brinkmanship tooling well before the next crisis does
not require selecting conveniently completed host features to
strap the tooling onto for testing; and
Again, openly creating a contingency plan is not brinkmanship, it's
normal. I know that considering these scenarios is uncomfortable; I
avoid conflict myself! But I feel obliged to face this as a real
possibility.
I think we should be normalizing the understanding that bitcoin users
are the ultimate decider. By offering *all* of them the tools to do so
we show this isn't lip-service, but something that businesses and
everyone else in the ecosystem should consider.
While I strongly agree with your principle, I strongly disagree with the practice of how you propose going about it.
Ultimately, no matter what we decide here, elsewhere, or what the process for consensus changes is, the decider will be
economic activity and users voting with their Bitcoin. We should start by acknowledging that, and acknowledging that the
markets will (and have!) let us know what they think when there is any kind of material disagreement.
Then, we should optimize for ensuring that the market never needs to "correct the situation", because if we end up there
(or in any of these kinds of scenarios), we've basically screwed the pooch. Sure, some 10% minority group (and usually
less as time goes on) forking themselves off has turned out to basically be irrelevant, but if we end up with multiple
active chains as a normal course of business (which I'd strongly argue we'd be optimizing for with some kind of UASF/LOT
option design out the gate), all we do is encourage strife, at the cost of users who just want to use a robust and
reliable Bitcoin.
- it's already the case that a UASF branch can be prepared along
with ST (ie. without requiring LOT=false), although the code is a
bit more complex and the appropriate stopheight a few blocks later.
I don't believe this is true, unless you UASF before ST expires? ST is
explicitly designed *not* to give time to conclude that miners are
stalling (unless something has changed from the initial 3 month
proposal?).
ST is not intended to be an end-all, be-all of the taproot activation story. I don't think anyone who is pushing for it
thinks that ST is the only option if miners are not able to upgrade before its signaling window expires. Just because it
isn't designed to ensure we can play brinksman ship fork games with a UASF doesn't mean there isn't a followup that
could include such a thing.
Matt
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
