As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem. Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
split when many would. If you wish to fork off, please do so responsibly.
Post by Peter R via bitcoin-dev
Thank you for the thoughtful reply.
Surely you are aware that what you are proposing is vastly different from
the way soft forks have historically worked.
Yes, it is different. Itâs different because the future network upgrade
to larger blocks includes a loosening of the consensus ruleset whereas
previous upgrades have included a tightening of the rule set. (BTWâthis is
not my proposal, I am describing what I have recently learned through my
work with Bitcoin Unlimited and discussions with miners and businesses).
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
With a loosening of the consensus rule set, the situation is different: a
hash power minority that has not upgraded will produce a minority branch,
that will also drag along non-upgraded node operators, leading to potential
confusion. The idea behind orphaning the blocks of non-upgraded miners was
to serve as a wake-up call to upgrade, to reduce the chances of a minority
chain emerging in the first place, similar to what happens automatically
with a soft-forking change. If one's worry is a chain split, then this
seems like a reasonable way to reduce the chances of that worry
materializing. The Level 3 anti-split protection takes this idea one step
further to ensure that if a minority branch does emerge, that transactions
cannot be confirmed on that branch.
First of all, the bar for miners being on the new chain is extremely high, 95%.
Iâm very confident that most people do NOT want a split, especially the
miners. The upgrade to larger blocks will not happen until miners are
confident that no minority chain will survive.
Second of all, soft forks make rule restrictions on classes of
transactions that are already non-standard so that any non-upgraded miners
are unlikely to be including txs in their blocks which would violate the
new rules and should not have their blocks orphaned even after the fork.
I agree that the soft-fork mechanism usually works well. I believe this
mechanism (or perhaps a modified version of it) to increase the block size
limit will likewise work well. All transactions types that are currently
valid will be valid after the upgrade, and no new types of transactions are
being created. The âblock-size-limit gene" of network nodes is simply
evolving to allow the network to continue to grow in the way it has always
grown. (If youâre interested, here is my talk at Coinbase where I discuss
Finally, soft forks are designed to only be used when there is a very wide
community consensus and the intention is not to overrule anyone's choice to
remain on the old rules but to ensure the security of nodes that may have
neglected to upgrade. Obviously it is impossible to draw a bright line
between users who intentionally are not upgrading due to opposition and
users that are just being lazy. But in the case of a proposed BU hard fork
it is abundantly clear that there is a very significant fraction, in fact
likely a majority of users who intentionally want to remain on the old
My read is completely different. I still have never talked with a person
in real life who doesnât want the block size limit to increase. Indeed, I
have met people who worry that Bitcoin Unlimited is âtrying to take
overââand thus they are worried for other reasonsâbut this couldnât be
further from the truth. For example, what most people within BU would love
to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
adjust the size of blocks their nodes will accept, so that these node
operators can follow consensus through the upgrade if they choose to.
This is not a fight about âCore vs. BUâ; Bitcoinâs future is one of
âgenetic diversityâ with multiple implementations, so that a bug in one
doesnât threaten the network as a whole. To me it seems this is largely a
fight about whether node operators should be easily able to adjust the size
of blocks their nodes accept. BU makes it easy for node operators to
accept larger blocks; Core doesnât believe users should have this power
(outside of recompiling from source, which few users can do).
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
Once again, this is not my proposal. I am writing about what I have come
to learn over the past several weeks. When I first heard about these
ideas, I was initially against them too. They seemed harsh and merciless.
It wasnât until I got out their and started talking to more people in the
community that the rationale started to make sense to me: the biggest
concern people had was a chain split!
So I guess the âethicsâ here depend on the lens through which one is
looking. People who believe that an important outcome of the upgrade to
larger blocks is to avoid a blockchain split may be more favourable to
these ideas than people who want the upgrade to result in a split (or are
OK with a split), as it sounds like you do (is this true that youâd rather
split than accept blocks with more than 1,000,000 bytes of transaction
information in them? Sorry if I misunderstood).
But if one's intention is to split and not follow the majority hash power
when blocks become larger, then why not change the proof-of-work? This
would certainly result in a peaceful splitting, as you said you desire.
On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
Post by Peter R via bitcoin-dev
One of the purported benefits of a soft-forking change (a tightening of
the consensus rule set) is the reduced risk of a blockchain split compared
to a loosening of the consensus rule set. The way this works is that
miners who fail to upgrade to the new tighter ruleset will have their
non-compliant blocks orphaned by the hash power majority. This is a strong
incentive to upgrade and has historically worked well. If a minority
subset of the network didnât want to abide by the new restricted rule set,
a reasonable solution would be for them to change the proof-of-work and
start a spin-off from the existing Bitcoin ledger (
In the case of the coming network upgrade to larger blocks, a primary
concern of both business such as Coinbase and Bitpay, and most miners, is
the possibility of a blockchain split and the associated confusion, replay
risk, etc. By applying techniques that are known to be successful for
soft-forking changes, we can likewise benefit in a way that makes a split
less likely as we move towards larger blocks. Two proposed techniques to
1. That miners begin to orphan the blocks of non-upgraded miners once a
super-majority of the network hash power has upgraded. This would serve as
an expensive-to-ignore reminder to upgrade.
2. That, in the case where a minority branch emerges (unlikely IMO),
majority miners would continually re-org that minority branch with empty
blocks to prevent transactions from confirming, thereby eliminating replay
Just like after a soft forking change, a minority that does not want to
abide by the current ruleset enforced by the majority could change the
proof-of-work and start a spin-off from the existing Bitcoin ledger, as
suggested by Emin.
On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <
Post by Aymeric Vitte via bitcoin-dev
I don't know what "Time is running short I fear" stands for and when
-----BEGIN PGP SIGNED MESSAGE-----
On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
"Time is running short I fear" stands for and when 50% > is supposed
to be reached
According to current hashrate distribution tracking site coin.dance,
very likely within less than four weeks according to current hashrate
While a fork is very likely, that I dont really fear because worst
case scenario is that bitcoin still survives and the invalid chain
becomes an alt. My fear is the centralized mining power being used
to attack the valid chain with intentions on killing it. 
Shouldn't this 50% attack they are threatening be a concern? If it
is a concern, what options are on the table. If it is not a concern
please enlightent me as to why.
[Level 2] Anti-split protection Miners will orphan the
blocks of non-compliant miners prior to the first larger block
to serve as a reminder to upgrade. Simply due to the possibility
of having blocks orphaned, all miners would be motivated to
begin signalling for larger blocks once support definitively
passes 51%. If some miners hold out (e.g., they may not be
paying attention regarding the upgrade), then they will begin
to pay attention after losing approximately $15,000 of revenue
due to an orphaned block.
[Level 3] Anti-split protection In the scenario where Levels
1 and 2 protection fails to entice all non-compliant miners to
upgrade, a small-block minority chain may emerge. To address the
risk of coins being spent on this chain (replay risk), majority
miners will deploy hash power as needed to ensure the minority
chain includes only empty blocks after the forking point. This
can easily be accomplished if the majority miners maintain a
secret chain of empty blocks built off their last empty
block publishing only as much of this chain as necessary
to orphan any non-empty blocks produced on the minority chain.
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
bitcoin-dev mailing list
bitcoin-dev mailing list
bitcoin-dev mailing list