From: Chris Acheson <mail@chrisacheson•net>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Date: Sat, 15 Apr 2017 03:46:47 -0400 [thread overview]
Message-ID: <2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net> (raw)
In-Reply-To: <CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
On 04/15/2017 03:04 AM, Gregory Maxwell via bitcoin-dev wrote:
> Considering that you did not spare a single word about the specific
> property that I am concerned about-- that the proposal will reject
> the blocks of passive participants, due to avoidable design
> limitations-- I can't help but feel that you don't even care to
> understand the concern I was bringing up. :(
Not sure if you missed my previous reply to you, but I'm curious about
your thoughts on this particular point. I contend that for any UASF,
orphaning non-signalling blocks on the flag date is safer than just
considering the fork active on the flag date.
Unless we have majority miner support for the fork, we have to assume
that a chain split will occur at some point. With the orphaning
approach, we know exactly when that will be, and can plan around it.
Miners know that they need to upgrade by the flag date in order to get
paid. We even have an opportunity to back out if it looks like we don't
have enough economic support.
With the non-orphaning approach, the split won't occur until someone
chooses to craft a malicious block (short bitcoin; rent hash power;
profit). We don't know when that will be, so we can't plan around it.
Some nodes and miners will assume it won't happen at all. When it
happens, our responses to it will be clumsy, uncoordinated, and likely
panicked.
While the orphaning approach is potentially disruptive to miners, it is
necessarily so in order to minimize disruption to users. In general,
users should be prioritized over miners. The point of Bitcoin is to have
secure, digital money that we can *use*, not to enable people to earn
money from running busy-work computations.
> How many people barely reviewed the specifics of the proposal simply
> because they want something fast and this proposal does something
> fast?
I have scrutinized the strategy of BIP148 a fair bit. I was initially
opposed to it, but after Bitfury showed their support, and especially
after the Asicboost revelation, I think it has solid potential to
succeed. It would be a waste not to at least attempt to organize around
it. If it turns out that we can't get the necessary support in time, we
can abandon the effort and reassess our options.
next prev parent reply other threads:[~2017-04-15 7:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
2017-04-14 10:52 Chris Acheson
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2941cf86-422f-6a88-fb44-9ac01c5e996a@chrisacheson.net \
--to=mail@chrisacheson$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox