[bitcoin-dev] BIP99 and Schism hardforks lifecycle (was Switching Bitcoin Core to sqlite db)

[Jorge Timón]

On Mon, Nov 16, 2015 at 2:52 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> We have strayed far from both the Subject line and from making progress
> on bitcoin development.  Please redirect to bitcoin-discuss.
>
> I have set the moderation bits on the three contributors from here down
> (CC'd): your next post will go to moderation.

Sorry for going out of topic on that thread, I have just created
another thread to discuss this particular point (whether schism
hardforks can be universally predicted to collapse into a single chain
or not), which is a fundamental part of BIP99 discussion and I believe
technical enough for this list (assuming that we stay on topic). But
the moderation thinks it's not relevant enough for this list, we can
move it to the discussion mailing list or private emails.

On Sun, Nov 15, 2015 at 6:06 PM, Peter R <peter_r at gmx.com> wrote:
>> I am not convinced that Bitcoin even *has* a block size limit, let alone
>> that it can enforce one against the invisible hand of the market.
>
Jorge Timón said:
> You keep insisting that some consensus rules are not consensus rules while
> others "are clearly a very different thing". What technical difference is
> there between the rule that impedes me from creating transactions bigger
> than X and the rules that prevent me frm creatin new coins (not as a miner,
> as a regular user in a transaction with more coins in the outputs than in
> the inputs)?
>

On Sun, Nov 15, 2015 at 6:06 PM, Peter R <peter_r at gmx.com> wrote:
> I think you’re using the term “technical difference” to mean something very
> specific.  Perhaps you could clarify exactly how you are defining that term
> because to me it is crystal clear that creating coins out of thin air is
> very different than accepting a block 1.1 MB in size and full of valid TXs.
> There are many technical differences between the two. For example,
> technically the first allows coins to be created randomly while the second
> doesn’t.

Of course, their technical difference come from the fact they are
technically different. That's not what I meant.
There's no technical argument that lets you predict whether
eliminating one rule or the other will be more or less acceptable to
users.
There's no technical difference that I can see in that reward.
I think these two examples strike people as "obviously different" just
because they are morally different, but I want to avoid moral
judgments in BIP99.

> It is fact that two competing forks can persist for at least a short amount
> of time—we saw this a few years ago with the LevelDB bug and again this
> summer with the SPV mining incident.  In both cases, there was tremendous
> pressure to converge back to a single chain.

Those were unintentional hardforks. There's an example of a failed
schism hardfork: when some people changed the subsidy/issuance rules
to maintain the 50 btc block subsidy constant.
It didn't failed because of "tremendous pressure": it failed because
the users and miners of the alternative ruleset abandoned it. If they
hadn't, the two incompatible chains would still grow in parallel.

> Could two chains persist indefinitely?  I don’t know.  No one knows.  My gut
> feeling is that since users would have coins on both sides of the fork,
> there would be a fork arbitrage event (a “forkbitrage”) where speculators
> would sell the coins on the side they predict to lose in exchange for
> additional coins on the side they expect to win.  This could actually be
> facilitated by exchanges once the fork event is credible and before the fork
> actually occurs, or even in a futures market somehow.  I suspect that the
> forkbitrage would create an unstable equilibrium where coins on one side
> quickly devalue.  Miners would then abandon that side in favour of the
> other, killing the fork because difficulty would be too high to find new
> blocks.  Anyways, I think even *this* would be highly unlikely.  I suspect
> nodes and miners would get inline with consensus as soon as the fork event
> was credible.

Yes, there could be arbitrage and speculators selling "on both sides"
is also a possibility.
At some point we would arrive to some kind of price equilibrium,
different for each of the coins. BIP99 states that those prices are
unpredictable (or at least there's no general method to predict the
result without knowing the concrete case, the market, etc) and in fact
states that the resulting price for both sides could be going to close
to zero market capitalization.
That still doesn't say anything about one side having to "surrender".
The coin that ends up with the lowest price (and consequently, the
lowest block reward and hashrate) can still continue, maybe even for
longer than the side that appeared to be "victorious" after the
initial arbitrage.
I haven't heard any convincing arguments about schism hardforks having
to necessarily collapse into a single chain and until I do I'm not
going to adapt BIP99 to reflect that.

On Sun, Nov 15, 2015 at 11:22 PM, Corey Haddad <corey3 at gmail.com> wrote:
> On Sun, Nov 15, 2015 at 2:12 AM, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>>If the invisible hand of the market is what decides consensus rules instead
>> of their (still incomple) specification (aka libconsensus), then the market
>> could decide to stop enforcing ownership. Will you still think that Bitcoin
>> is a useful system when/if you empirically observe the invisible hand of the
>> market taking coins out of your pocket?
>
> The market, which in this instance I take to mean the economic majority,
> could absolutely decide to stop enforcing ownership of certain coins, even
> arbitrarily ascribing them to a different address.  That's not something any
> of us have any control over, and that reality must be acknowledged.
> Bitcoins have value is due to collective behavior.  We can provide tools to
> help people reach a common understanding, but the tools cannot force people
> to reach a certain conclusion.

Yes, I have control: all users (including miners) have direct control
over the rules that software they run validates.
You cannot ever have your coins stolen in the longest valid chain you
follow if the validity rules you use enforce property ownership.
No majority can force you to move to the new non-ownership rules, just
like no majority can force you to move to any different set of rules.
If we accept the notion that a groups of users could resist to
deploying this particular rule changes and keep operating under the
old rules, we have to accept that this can happen for any
controversial hardfork, and that we cannot predict a common lifecycle
for all schism hardforks.