From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D6A2D7A for ; Sun, 15 Nov 2015 17:19:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6222B13D for ; Sun, 15 Nov 2015 17:19:49 +0000 (UTC) Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LgZRV-1alb3D3dLR-00nxfG; Sun, 15 Nov 2015 18:07:03 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Peter R In-Reply-To: Date: Sun, 15 Nov 2015 09:06:58 -0800 Message-Id: References: <5631C363.5060705@neomailbox.net> <201510290803.52734.luke@dashjr.org> <5632DE33.7030600@bitcartel.com> <3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com> <571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com> <6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com> <13D7C936-4D2E-4BAC-AC61-3DA80581C946@gmx.com> <2C8EBBD8-51B7-4F47-AFFA-3870DBD6C4EA@gmx.com> To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:gJPyxGyuBAoEAKuw8DJy/EXzk1p6ApAHcJ8fI4VocKkTAPhA3gv VYO6ugplwhGNuBphAGCFeKYPWoliEZoMexqsgkvCFkUyloaj1zpd3r3yEEnH7Y3HRg4oxzi x61eZGrNCcmLI/mYqHeLTgwygH+n/G5Je5ko2Lx35mLyAqreRbHkRkYA/sS0uP9/E0LxW1O rUvSGVTw/xO6o5s4ORS5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:KEOX/5GF+VY=:nePGWGYDQ3B3HkZDnidBDI zVco6e/FjvDtDHp7Vj/GMSHtHrIswSil4HfXp3lzP98Axn2YTMFIn/XW+FIdStgYOKMfc+Jpt Ii6H/nFC1tRbFB1PmcAwnTxbyroWeKK9zK+vcEIzSLFV/jEfG57BeetL5GyQzcVNaR6MFLZKq CXVpuPUpnOBrlseY5n34eDXB7dJpIKSw7tiMR9ekcG9J5vimvKPDW1bH3OMWCi+XBNZfVaBu7 oE0zQn38RKqQTs+hJ0gHpZp56ic+xYv2CAtudE6gPdHFamHZcBJbA91Y0UdIx6jTtQNxRdeYV /q4Yymy5iTncbnXFXmtIJo7s9pKHDxUJZ4BgSIbB8HMSuBs1CCuWNMes5r0ddQFXz1uqcA9uE meICcpoAibHFjXBNDbFX6vH8nlfa/45lAPoEF25kZ75ByTdR9Y/uFTWLxnqDS1VdK01EmTKdL jZUPZvGYSO0qxRSQxvHA0HbsrGBmR63QpTqnVxh/7vOlqMYFE+WerlqWRgYULnHsY/Ag51g5s OWF+Je/v9N8J27gDGUhNIvMKwryen8mVKZD0NfJw2FeHJpYNfbu8GejK0HdJ1208RFB1XpCO8 I4Lr6P1ftLCKB5WK1ex/jUyJwibjQHMvpOy0w106wtKyfm7uQogVocoadQsgHZarvZZ1yFWQj A7VW+wQiwGVxV0VOxQky8SYOt+07m/ztCKDe6dcWwhU+aoOWpKPBXwUeBYwU2DLdbKW1dFUZL 1PaVRCCgWE8ofcl2T8bTqCl433HG7pZI0DyuJZ7DzX3oPsFpE7f9cV1sFkXZgEwJPIzS15Ebv QZSyd8q X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Gregory Maxwell , telemaco Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 17:19:51 -0000 --Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Jorge: > > What rules does Bitcoin obey?=20 >=20 > 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. >=20 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. >=20 > 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)? >=20 What technical difference is there between a cat and a dog? They both = have four legs and a furry coat.=20 I think you=E2=80=99re using the term =E2=80=9Ctechnical difference=E2=80=9D= 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=E2=80=99t. =20 > 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. >=20 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. =20 > 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) >=20 It is fact that two competing forks can persist for at least a short = amount of time=E2=80=94we 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=E2=80=99t 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 = =E2=80=9Cforkbitrage=E2=80=9D) 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. =20 Cryptocurrency is a new area of interdisciplinary research. We are all = learning together and no one knows how things will unfold. =20 Best regards, Peter --Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99re = using the term =E2=80=9Ctechnical difference=E2=80=9D 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=E2=80=99t. =  

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=E2=80=94we 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=E2=80=99t 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 = =E2=80=9Cforkbitrage=E2=80=9D) 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

= --Apple-Mail=_9E440E5C-41D1-4F34-8EBA-776F0B3F18AA--