public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Bryan Bishop <kanzure@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Peter R <peter_r@gmx.com>
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
Date: Sun, 26 Mar 2017 14:12:20 -0700	[thread overview]
Message-ID: <0ee42982-22d9-7e3f-23aa-f3743df88a6a@voskuil.org> (raw)
In-Reply-To: <CABaSBayb-FAt0XOX9u+T3-Z2gJQAV-Y7xZS_k6YG74VhPqejQA@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/26/2017 01:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> With a tightening of the rule set, a hash power minority that has 
> not upgraded will not produce a minority branch; instead they will 
> simply have any invalid blocks they produce orphaned, serving as a 
> wake-up call to upgrade.
> 
> False. With bip9-based soft-fork-based activation of segwit, miner 
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told
> miners otherwise, let me know.

Given the protocol requirements of the segwit proposal this is not the
case. A miner running pre-segwit code will produce blocks that no
segwit node will ever receive. It matters not whether these blocks
contain transactions that are invalidated by the soft fork. Despite
being valid to other pre-segwit nodes they will never be built upon by
the majority hash power once segwit activates.

At the same time, Peter's comment above is also incorrect. A "minority
branch" *is* a set of blocks that have been orphaned (the term orphan
being a misnomer, since these blocks of course have an ancestry all
the way to the genesis block). That's precisely what is implied by the
word "minority". So his description contradicts itself.

e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY2C6pAAoJEDzYwH8LXOFOf4gH/2e/euZ9bQxPKZyC7DN8us6T
R1R9f+JFFsU3Vo8HkcU028Ib4aF0IAELvAWrhpZfH6ixZV2c3CJoi53rMbPmJ/+H
Rlj0Qjc58mYpqosxyNoi0qPFZ2e3yCv+R5v9PQEeOdcGwXIr77Tij8lI1yu4uqHU
bqJ3BXJLFpvL5iXOLhbakeu2qVIHqJnb1/hQMNh6eNM794n+UT2T8You52xUkuTm
zJ+5CTQUiMNFE/HBWsbk8Vf3BTrM0sqMRTJzdr4VT1l+uOZn58BJJPFzLr2WeZww
klAB/wK5oExMNlKQVy6Rw9+uFx88qRTl5s7LwFASOxEZYJIjd36bBaoTdqfaB5U=
=pvlp
-----END PGP SIGNATURE-----


  parent reply	other threads:[~2017-03-26 21:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24 16:03 [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? 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
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 [this message]
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=0ee42982-22d9-7e3f-23aa-f3743df88a6a@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=kanzure@gmail.com \
    --cc=peter_r@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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