I'm glad some discussion has been moved back here.
but signals and enforces BIP148 when used. Who are we protecting users
Post by Suhas Daftuar via bitcoin-dev
I also do not support the BIP 148 UASF, and I'd like to add to the points
that Greg has already raised in this thread.
BIP 148 would introduce a new consensus rule that softforks out
non-segwit signalling blocks in some time period. I reject this consensus
rule as both arbitrary and needlessly disruptive. Bitcoin's primary
purpose is to reach consensus on the state of a shared ledger, and even
though I think the Bitcoin network ought to adopt segwit, I don't think
that concern trumps the goal of not splitting the network.
Many BIP 148 advocates seem to start with the assumption that segwit
already has a lot of support, and suggest that BIP 148 does as well.
However I don't think it's fair or correct to separate the activation
proposal for segwit from the rest of the segwit proposal. The deployment
parameters for segwit are consensus-critical; assuming that some other
deployment has consensus because it would result in the rest of the segwit
proposal activating is an unjustified leap.
Even if there were no feasible alternate segwit deployment method
available to us, I would hesitate to recommend that the network adopt a
potentially consensus-splitting approach, even though I firmly believe that
the ideas behind segwit are fundamentally good ones. But fortunately that
is not the situation we are in; we have substantially less disruptive
methods available to us to activate it, even if the current BIP 9
deployment were to fail -- such as another BIP 9 deployment in the future,
or perhaps a BIP 149 deployment.
If we do pursue a "user-activated" deployment of segwit, I'd recommend
that we do so in a more careful way than BIP 148 or 149 currently suggest,
which as I understand would otherwise make very few changes to the current
implementation. However, due to the BIP 9 activation assumption, the
Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
the idea that miners would both enforce the rules and mine segwit blocks.
However, we can separate these concerns, as we started to do in the Bitcoin
Core 0.14.1 release, where mining segwit blocks is not required in order to
generally mine or signal for segwit in the software. And we can go further
still: without too much work, we could make further improvements to
accommodate miners who, for whatever reason, don't want to upgrade their
systems, such as by improving block relay from pre-segwit peers , or
optimizing transaction selection for miners who are willing to enforce the
segwit rules but haven't upgraded their systems to mine segwit blocks .
If we would seek to activate a soft-fork with less clear miner signaling
(such as BIP 149), then I think such improvements are warranted to minimize
network disruption. In general, we should not seek to censor hashpower on
the network unless we have a very important reason for doing so. While the
issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
proposal on the spectrum of "censorship attack on Bitcoin" to "benign
protocol upgrade", BIP 148 strikes me as closer to the former than the
latter. There is simply no need here to orphan these non-signalling blocks
that could otherwise be used to secure the network.
To go further: I think BIP 148 is ill-conceived even for achieving its
own presumed goals -- the motivation for adding a consensus rule that
applies to the version bits on blocks is surely for the effect such bits
have on older software, such as Bitcoin Core releases 0.13.1 and later.
Yet in trying to bring those implementations along as segwit-enforcing
software, BIP 148 would risk forking from such clients in the short term!
If one really cared about maintaining consensus with older, segwit-enabled
software, it would make far more sense to seek segwit activation in a way
that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
after this one times out). And if one doesn't care about such consensus,
then it'd be far simpler to just set (e.g.) August 1 as the flag day
activation of segwit, and not play these contortionist games with block
version bits, which carry no useful or intrinsic meaning. Either of these
two approaches should have the advantage of reduced fork risk, compared
with BIP 148.
Of course, everyone is free to run the software of their choosing. I
write this to both generally convey my opposition to a careless proposal,
which I believe represents a way of thinking that is detrimental to
Bitcoin's long run success, and specifically explain why I oppose inclusion
of this proposal in the Bitcoin Core implementation . The Bitcoin Core
project hasn't been, and shouldn't be, careless in deploying consensus
changes. Instead, I think the Bitcoin Core project ought to stand up for
the best practices that our community has learned about how to deploy such
changes (specifically for minimizing chain-split risk when deploying a soft
fork!), and I think we should all avoid adoption or encouragement of
practices that would depart from the high standards we are capable of
On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
Post by Gregory Maxwell via bitcoin-dev
I do not support the BIP148 UASF for some of the same reasons that I
do support segwit: Bitcoin is valuable in part because it has high
security and stability, segwit was carefully designed to support and
amplify that engineering integrity that people can count on now and
into the future.
I do not feel the the approach proposed in BIP148 really measures up
to the standard set by segwit itself, or the existing best practices
in protocol development in this community.
The primary flaw in BIP148 is that by forcing the activation of the
existing (non-UASF segwit) nodes it almost guarantees at a minor level
Segwit was carefully engineered so that older unmodified miners could
continue operating _completely_ without interruption after segwit
Older nodes will not include segwit spends, and so their blocks will
not be invalid even if they do not have segwit support. They can
upgrade to it on their own schedule. The only risk non-participating
miners take after segwit activation is that if someone else mines an
invalid block they would extend it, a risk many miners already
frequently take with spy-mining.
I do not think it is a horrible proposal: it is better engineered than
many things that many altcoins do, but just not up to our normal
standards. I respect the motivations of the authors of BIP 148. If
your goal is the fastest possible segwit activation then it is very
useful to exploit the >80% of existing nodes that already support the
original version of segwit.
But the fastest support should not be our goal, as a community-- there
is always some reckless altcoin or centralized system that can support
something faster than we can-- trying to match that would only erode
our distinguishing value in being well engineered and stable.
"First do no harm." We should use the least disruptive mechanisms
available, and the BIP148 proposal does not meet that test. To hear
some people-- non-developers on reddit and such-- a few even see the
forced orphaning of 148 as a virtue, that it's punitive for
misbehaving miners. I could not not disagree with that perspective any
Of course, I do not oppose the general concept of a UASF but
_generally_ a soft-fork (of any kind) does not need to risk disruption
of mining, just as segwit's activation does not. UASF are the
original kind of soft-fork and were the only kind of fork practiced by
Satoshi. P2SH was activated based on a date, and all prior ones were
based on times or heights. We introduced miner based activation as
part of a process of making Bitcoin more stable in the common case
where the ecosystem is all in harmony. It's kind of weird to see UASF
portrayed as something new.
It's important the users not be at the mercy of any one part of the
ecosystem to the extent that we can avoid it-- be it developers,
exchanges, chat forums, or mining hardware makers. Ultimately the
rules of Bitcoin work because they're enforced by the users
collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
something people can count on: the rules aren't easy to just change.
There have been some other UASF proposals that avoid the forced
disruption-- by just defining a new witness bit and allowing
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
think they are vastly superior. They would be slower to deploy, but I
do not think that is a flaw.
We should have patience. Bitcoin is a system that should last for all
ages and power mankind for a long time-- ten years from now a couple
years of dispute will seem like nothing. But the reputation we earn
for stability and integrity, for being a system of money people can
count on will mean everything.
If these discussions come up, they'll come up in the form of reminding
people that Bitcoin isn't easily changed at a whim, even when the
whims are obviously good, and how that protects it from being managed
like all the competing systems of money that the world used to use
were managed. :)
So have patience, don't take short cuts. Segwit is a good improvement
and we should respect it by knowing that it's good enough to wait for,
and for however its activated to be done the best way we know how.
bitcoin-dev mailing list
bitcoin-dev mailing list