[bitcoin-dev] I do not support the BIP 148 UASF

Hampus Sjöberg hampus.sjoberg at gmail.com
Tue May 23 09:47:48 UTC 2017

> Who are we protecting users from, themselves? Are you protecting core?
from what? I am somewhat genuinely befuddled by those who can't even allow
a user config switch to be set.

Indeed. It seems silly. If you're activating the switch, you're most likely
fully aware of what you're doing.
I also saw some very harsh rhetoric being used against BIP148, which seems
unjustified as we have no idea yet how it all will play out. We can only


2017-05-23 6:03 GMT+02:00 Steven Pine via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> I'm glad some discussion has been moved back here.
> Correct me if I am wrong, but currently core developers are arguing over
> whether or not to allow an optional configuration switch which defaults off
> but signals and enforces BIP148 when used. Who are we protecting users
> from, themselves? Are you protecting core? from what? I am somewhat
> genuinely befuddled by those who can't even allow a user config switch to
> be set.
> I guess I find it all incredibly silly, but perhaps I suffer from some
> basic confusion.
> On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> 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 [1], or
>> optimizing transaction selection for miners who are willing to enforce the
>> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
>> 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 [3].  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
>> achieving.
>>  [1] https://lists.linuxfoundation.org/pipermail/bitcoin-
>> dev/2017-March/013811.html
>>  [2] https://github.com/bitcoin/bitcoin/pull/9955
>>  [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
>> --Suhas Daftuar
>> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> 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
>>> of disruption.
>>> Segwit was carefully engineered so that older unmodified miners could
>>> continue operating _completely_ without interruption after segwit
>>> activates.
>>> 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
>>> more strongly.
>>> 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> --
> Steven Pine
> (510) 517-7075
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/0a7c89a0/attachment-0001.html>

More information about the bitcoin-dev mailing list