public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] I do not support the BIP 148 UASF
@ 2017-04-14 10:52 Chris Acheson
  0 siblings, 0 replies; 41+ messages in thread
From: Chris Acheson @ 2017-04-14 10:52 UTC (permalink / raw)
  To: bitcoin-dev

Speaking as one of the BIP148 agitators:

> 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.

I'm assuming that you're referring to the flag date "segwit is on now"
approach. This is more dangerous than the orphaning approach that BIP148
uses.

If we orphan non-signalling blocks on the flag date and don't have
majority hash power supporting us, there will be a chain split on the
flag day. We expect this to happen, we plan for it, and we employ
strategies to mitigate any damage. The bulk of the economy has
coordinated around this event happening. We even had the opportunity to
pull the plug before the flag date if things were looking too grim.

After the dust settles, 100% of the miners are guaranteed to have
upgraded, assuming they didn't choose to forgo 2+ weeks of income. Any
further chain splits would have to be the result of deliberate action by
51%+ of the mining power.

If we just have segwit activate on the flag date without orphaning the
blocks of non-segwit miners, we set ourselves up for a chain split at
some unknown time in the future. Without majority hash power on our
side, as soon as someone mines a segwit-invalid transaction, the chain
will split, with upgraded nodes and miners on one side, and non-upgraded
nodes and miners on the other side. The segwit-invalid transaction
doesn't even need to come from someone with their own mining equipment.
Open a short on BTC, rent some hash power, profit.

Since we don't know when this attack will occur, we won't be organized
and ready for it. It's also easy for both miners and users to get
complacent about it and fail to upgrade. The damage will be far worse
than if we had used the orphaning approach.

> "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.

Punitive action against miners is not the point of BIP148, it's an
unavoidable side-effect of making the UASF less disruptive for the users
of Bitcoin. Minimizing disruption for users must take priority over
minimizing disruption for miners. Given the intensity of this dispute
and the bad faith of certain actors, some schadenfreude is bound to
occur. Don't let that distract you from the actual reasons that BIP148
is designed the way it is.

> 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.

I respect this perspective, and I agree with it to a certain extent.
However, continuing to wait has costs. I do not believe we have the
luxury of continuing to wait for a couple more years. In doing so it's
entirely possible that we may damage our reputation for stability and
integrity rather than build on it.

We have a window of opportunity with BIP148, and it would be a waste not
to act on it. In the event that we still lack sufficient support by
July, we can abandon the project, and make plans for how best to proceed
from there.


^ permalink raw reply	[flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] I do not support the BIP 148 UASF
@ 2017-04-15 13:42 Mark Friedenbach
  2017-04-15 14:54 ` Ryan Grant
  2017-04-15 18:50 ` Gregory Maxwell
  0 siblings, 2 replies; 41+ messages in thread
From: Mark Friedenbach @ 2017-04-15 13:42 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Greg,

If I understand correctly, the crux of your argument against BIP148 is that
it requires the segwit BIP9 activation flag to be set in every block after
Aug 1st, until segwit activates. This will cause miners which have not
upgrade and indicated support for BIP141 (the segwit BIP) to find their
blocks ignored by UASF nodes, at least for the month or two it takes to
activate segwit.

Isn't this however the entire point of BIP148? I understand if you object
to this, but let's be clear that this is a design requirement of the
proposal, not a technical oversight. The alternative you present (new BIP
bit) has the clear downside of not triggering BIP141 activation, and
therefore not enabling the new consensus rules on already deployed full
nodes. BIP148 is making an explicit choice to favor dragging along those
users which have upgraded to BIP141 support over those miners who have
failed to upgrade.

On an aside, I'm somewhat disappointed that you have decided to make a
public statement against the UASF proposal. Not because we disagree -- that
is fine -- but because any UASF must be a grassroots effort and
endorsements (or denouncements) detract from that.

Mark Friedenbach

[-- Attachment #2: Type: text/html, Size: 1608 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread
* [bitcoin-dev] I do not support the BIP 148 UASF
@ 2017-04-14  7:56 Gregory Maxwell
  2017-04-14 16:50 ` praxeology_guy
                   ` (5 more replies)
  0 siblings, 6 replies; 41+ messages in thread
From: Gregory Maxwell @ 2017-04-14  7:56 UTC (permalink / raw)
  To: 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
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.


^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2017-05-23 13:20 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-14 10:52 [bitcoin-dev] I do not support the BIP 148 UASF Chris Acheson
  -- strict thread matches above, loose matches on Subject: below --
2017-04-15 13:42 Mark Friedenbach
2017-04-15 14:54 ` Ryan Grant
2017-04-15 18:50 ` Gregory Maxwell
2017-04-19 16:17   ` Erik Aronesty
2017-04-20 14:23     ` Alphonse Pace
2017-04-20 15:48       ` Erik Aronesty
2017-04-14  7:56 Gregory Maxwell
2017-04-14 16:50 ` praxeology_guy
2017-04-14 17:36   ` Chris Stewart
2017-04-14 18:33     ` praxeology_guy
2017-04-14 19:12   ` Tom Zander
2017-04-14 19:20 ` Tom Zander
2017-04-14 19:33   ` James Hilliard
2017-04-14 20:34     ` Tom Zander
2017-04-14 20:51       ` James Hilliard
2017-04-14 20:58         ` Tom Zander
2017-04-14 21:10           ` James Hilliard
2017-04-14 21:12             ` Gregory Maxwell
2017-04-14 20:59       ` Gregory Maxwell
2017-04-15  2:01 ` Steven Pine
2017-04-15  3:05   ` Chris Stewart
2017-04-15  3:29   ` Gregory Maxwell
2017-04-15  4:10     ` Steven Pine
2017-04-15  4:47       ` Gregory Maxwell
2017-04-15  6:28 ` Cameron Garnham
2017-04-15  7:04   ` Gregory Maxwell
2017-04-15  7:46     ` Chris Acheson
2017-04-15 13:23       ` Natanael
2017-04-15 13:54         ` Greg Sanders
2017-04-15  8:05     ` Cameron Garnham
2017-04-20 18:39 ` shaolinfry
2017-04-25 18:28   ` Gregory Maxwell
2017-04-25 18:46     ` Luke Dashjr
2017-05-02 16:54       ` Erik Aronesty
2017-05-22 19:23 ` Suhas Daftuar
2017-05-23  4:03   ` Steven Pine
2017-05-23  6:30     ` Karl Johan Alm
2017-05-23 12:55       ` Luke Dashjr
2017-05-23 13:20         ` Jorge Timón
2017-05-23  9:47     ` Hampus Sjöberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox