[bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Eric Voskuil eric at voskuil.org
Sun Mar 26 21:12:20 UTC 2017


-----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 at lists.linuxfoundation.org 
> <mailto:bitcoin-dev at 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-----


More information about the bitcoin-dev mailing list