[bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

Peter R peter_r at gmx.com
Sun Nov 15 17:06:58 UTC 2015

Hello Jorge:
> > What rules does Bitcoin obey? 
> Thanks to the worl of many people, part of the consensus rules are finally encapsulated in the libbitcoinconsensus library. I'm currently writing a document to complete the encapsulation of the specification of the consensus rules.
I applaud your work on the consensus library.  I think it an important step to encouraging multiple competing implementations of the protocol.
> > 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.
> 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)?
What technical difference is there between a cat and a dog? They both have four legs and a furry coat. 

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.  
> What about property enforcement? 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.
Correct.  Bitcoin is an experiment and could still fail (e.g., the network could allow people to move coins without valid signatures).  For Bitcoin to be viable, the network of miners and node operators being net-econo-rational actually is probably a core axiom that must be accepted.  
> You also keep assuming that somehow it is a universal law that users must eventually converge under the most-work chain. People follow the most-work VALID chain, but if they consciously decide to implement different rules (different definitions of "valid block") then their chains can diverge, and once they do they won't converge again (unless/until one group decides to implement the rules of the other exactly again)
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.

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.  

Cryptocurrency is a new area of interdisciplinary research.  We are all learning together and no one knows how things will unfold.  

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151115/864944e1/attachment.html>

More information about the bitcoin-dev mailing list