public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter R <peter_r@gmx.com>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Gregory Maxwell <gmaxwell@gmail.com>,
	telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Date: Sun, 15 Nov 2015 09:06:58 -0800	[thread overview]
Message-ID: <D64AA4C7-BB66-41B2-A001-107985071DA1@gmx.com> (raw)
In-Reply-To: <CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

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,
Peter


[-- Attachment #2: Type: text/html, Size: 4698 bytes --]

  parent reply	other threads:[~2015-11-15 17:19 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29  6:57 [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db telemaco
2015-10-29  8:03 ` Luke Dashjr
2015-10-30  3:04   ` Simon Liu
2015-10-30  3:35     ` Gregory Maxwell
2015-10-30  4:04       ` Peter R
2015-10-30  4:28         ` Gregory Maxwell
2015-11-15  1:02           ` Peter R
2015-11-15  1:08             ` Gregory Maxwell
2015-11-15  1:45               ` Peter R
2015-11-15  2:10                 ` Gregory Maxwell
2015-11-15  2:58                   ` Peter R
2015-11-15  3:30                     ` Gregory Maxwell
2015-11-15  4:10                       ` Peter R
2015-11-15 10:12                         ` Jorge Timón
2015-11-15 11:28                           ` Jorge Timón
2015-11-15 15:48                             ` Peter R
2015-11-15 17:06                           ` Peter R [this message]
2015-11-17 13:54                             ` Tamas Blummer
2015-11-17 15:24                               ` Tom Harding
2015-11-17 22:17                                 ` telemaco
2015-11-20 14:15                                   ` Jorge Timón
2015-11-16  1:52                     ` Rusty Russell
2015-11-15  3:04             ` Luke Dashjr
2015-11-15  3:17               ` Peter R
2015-10-29  8:17 ` Gregory Maxwell
  -- strict thread matches above, loose matches on Subject: below --
2015-10-22 21:26 Jeff Garzik
2015-10-22 21:54 ` Patrick Strateman
2015-10-22 21:56 ` Joseph Gleason ⑈
2015-10-23  6:53 ` Jonas Schnelli
2015-10-23  7:45 ` Lucas Betschart
2015-10-28 20:28   ` Sean Lynch
2015-10-28 21:11     ` Jeff Garzik
2015-10-23 10:30 ` Tom Zander
2015-10-26 18:06   ` Douglas Roark
2015-10-28 15:52     ` Tom Zander
2015-11-18  0:06     ` Jonathan Wilkins

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=D64AA4C7-BB66-41B2-A001-107985071DA1@gmx.com \
    --to=peter_r@gmx.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gmaxwell@gmail.com \
    --cc=jtimon@jtimon.cc \
    --cc=telemaco@neomailbox.net \
    /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