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

[Cameron Garnham <da2ce7@gmail.com>]

Hello,

It is hard for me to come out disagreeing with Maxwell, however in this case I feel I must.

As many may remember, there was quite some controversy about the BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of P2SH, and how this was the already “tested and proven to work” solution.

I was one of the man hold-out supporters of BIP17, not for any clear reason (I now have a much better technical understanding of the Bitcoin technical details, as we all do); But because it was the ‘more elegant’ solution.  I knew from other fields of engineering that elegant solutions very often better deal with the ‘unknown, unknowns’.  I also didn’t agree with Gavin’s ‘the sky is falling’ sense of urgency.

However, of-course the community got behind BIP16, it was activated, fortunately, without any signifiant incident.

I did learn that in Bitcoin there is something more valuable than technical elegance: that is community buy-in. On the technical side, the engineers need to make sure the solutions are viable: however on the community side we need to make sure that the good solutions are adopted in a reasonable timeframe.

It is both my empirical view and heart-felt belief that the wider Bitcoin Community wants SegWit quickly. In this case the sacrifice of some technical elegance and correctness for expediency is prudent!

It is my unfortunate view that Maxwell is missing the political forest for the technical trees.  Not only is SegWit a technical solution to technical problems; it has come to represent, by the larger Bitcoin Community, a political solution to the conflict that we are waist-deep in every, single, day.

BIP 148 is out terms of peace.  The Bitcoin Community is tired-to-death of this war and wants a resolution swiftly. BIP 148 proves a outlet, and in Maxwell words: “...almost guarantees at a minor level of disruption.”.

I am willing to go through this minor level of disruption, as the daily disruption from the “scaling debate war”; in my personal online life, is far greater.

SegWit is a exceptional feat of engineering, it solves and mitigates so many small and highly subtle issues within Bitcoin; yet still managed to be simple enough successfully reviewed: now the community is clearly calling for a quick activation of the ‘viable’ technical choice.

If you/we are going to provide any engineering solution to activating SegWit, then Swiftness should be the 1st priority after viability.

BIP 148 is both Swift and Viable.

Cameron.



> On 14 Apr 2017, at 10:56 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev