From: Alex Morcos <morcos@gmail•com>
To: Chris Pacia <ctpacia@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
Date: Sun, 26 Mar 2017 06:27:30 -0500 [thread overview]
Message-ID: <CAPWm=eXkNzgFEkd_Y23sHhWj3xQP4qtjBrh0J8Man5e6gFGLNQ@mail.gmail.com> (raw)
In-Reply-To: <CAB+qUq47LUCSNUPZRY=ROrrHH5a6SLYrhwBs4msjWJt9ArUwpA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4202 bytes --]
No I actually agree with a lot of what you said.
I feel there has been a lack of precision and consistency in talking about
these things in the past. This is not intentional, but its just what
happens when a lot of different people are all giving their own arguments.
I tried to be a bit more clear by talking about how soft forks have
historically been done. But certainly the technical definition of a soft
fork is a slippery slope. I completely disagree with the idea that miners
have any right to enforce a soft fork. Even more strongly, I don't think
they have the ability. Censoring a certain class of transactions (such as
those invalid under a soft fork) is something they can unilaterally do, but
it is not the same thing as a soft fork. It is necessarily transient. It
requires nodes to enforce the rules to make it a permanent soft fork.
I do think there are differences between soft forks and hard forks and
consensus requirements and safety for rolling them out. But as mentioned
in my email, I think soft forks should still have a very high bar for
consensus. It's an open question as to whether Core misjudged this for
segwit, although if so, I think it was a close call. The intention is not
to let 95% of miners make the rules (although again, note that it is 95%, a
very high bar, vastly different than 75% of miners). It seems to me that
the vast majority of the community is in favor of segwit. I'm not sure
about your comment that it is obvious to an observer than a sizable portion
of the community is opposed. It is certainly some, and perhaps more than
expected. But this is exactly why the new version bits soft fork roll out
mechanism allows proposals to expire. We did do an extensive job assessing
support for segwit before roll out, and although we knew of a few loud
voices against we judged them to be a very small minority. No business we
contacted was opposed. If it turns out we got it wrong then the proposal
will expire harmlessly. I for one am certainly opposed to forcing segwit
or any other fork of any kind on a significant minority that is opposed.
Despite saying that, I think you will hear some other responses about how
soft forks are opt-in and if you don't like the new features don't use
them. There is some logic behind this idea. But these are all subtleties
which are hard to make strong right and wrong statements about. See some
of the past discussion on this list.
On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia <ctpacia@gmail•com> wrote:
>
>
> On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> I just want to point out what appears to be doublespeak going on here.
>
> First, I think it would seem obvious to an observer that a sizable portion
> of the community (certainly greater than 5%) view segwit as preventing
> "rules I want to use instead of just peacefully splitting" but no
> consideration was given to these people when designing segwit as a
> softfork. I believe it was Luke who went as far as saying consensus does
> not matter when it comes softforks.
>
> Furthermore, when segwit was first introduced it kicked off a round of
> softfork/hardfork debate which I participated in. The primary concern that
> I and other raised was precisely what is going on now.. that miners could
> unilaterally impose an unpopular change to the protocol rules.
>
> At the time I told, rather forcefully, by multiple people that miners have
> an "absolute right" to softfork in whatever rules they want. Which, of
> course, is absurd on it's face.
>
> But I don't see how people can make such claims on the one hand, and then
> complain when this process is used against them.
>
> It amounts to nothing more than "When it's rules I like we get to impose
> them on non-consenting users. When it's rules I don't like it's an attack
> on the network".
>
> It was completely obvious this entire time that softforks were a very
> slippery slope, now we are indeed sliding down that slope.
>
>
>
[-- Attachment #2: Type: text/html, Size: 5473 bytes --]
next prev parent reply other threads:[~2017-03-26 11:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 16:03 CANNON
2017-03-24 16:27 ` Emin Gün Sirer
2017-04-14 2:22 ` CANNON
2017-03-24 17:29 ` Nick ODell
2017-03-24 17:37 ` Hampus Sjöberg
2017-03-24 19:00 ` Aymeric Vitte
2017-03-25 16:12 ` CANNON
2017-03-25 20:28 ` Peter R
2017-03-26 2:38 ` Alex Morcos
2017-03-26 9:13 ` Chris Pacia
2017-03-26 11:27 ` Alex Morcos [this message]
2017-03-26 19:05 ` Peter R
2017-03-26 20:20 ` Alphonse Pace
2017-03-26 20:22 ` Bryan Bishop
2017-03-26 20:37 ` Trevin Hofmann
2017-03-26 20:44 ` Bryan Bishop
2017-03-26 21:12 ` Eric Voskuil
2017-03-26 21:42 ` Tom Harding
2017-03-26 22:15 ` Eric Voskuil
2017-03-27 10:25 ` Aymeric Vitte
2017-03-26 3:00 ` [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?) Eric Voskuil
2017-03-24 19:00 ` [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? Aymeric Vitte
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='CAPWm=eXkNzgFEkd_Y23sHhWj3xQP4qtjBrh0J8Man5e6gFGLNQ@mail.gmail.com' \
--to=morcos@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=ctpacia@gmail$(echo .)com \
/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