Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 36CBD86 for ; Mon, 16 Nov 2015 12:06:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED1C3148 for ; Mon, 16 Nov 2015 12:06:49 +0000 (UTC) Received: by ykdr82 with SMTP id r82so233909433ykd.3 for ; Mon, 16 Nov 2015 04:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon_cc.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+PbxUE/MggKIvU1gJvpD/aRkESV36kFMa8ypM9CRWRs=; b=WnmQTDzJUx2E+5vOkbczHj1wWbLZ59li9JPbtJAxY6RZUwLdNDAQHQJG/DRf1y3JiD Bku2XvrQvUFBK1CfDp2pjoQvKvgFgE1byVCuq0BlSx/XRbx1Ht0J2Pqft5H0sD84Uidz 9Ax3iQQ7ACERIm7zXwqSWS+1GB+Sn/Mq+1ShgrchrbE3o7qemuUoW9wpMO4MWfeDgJ2Z V5pP9kgBkell/KCgA+JO9D9v3ZTdJM+CYGsXLfovldRENGxaIL/DwkEoq/WhmvS4QS89 I/bKrqfJM3ZSWujMsVJMC7byk3KI4T3OTbmpGDdRtOLAsIXYvIE8fqIEnMZKJ4Pwb6PW l7AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=+PbxUE/MggKIvU1gJvpD/aRkESV36kFMa8ypM9CRWRs=; b=SFctzVaEtXU2aZbfwd9GHbs2StCb4nNGw0i3AH+BnYZcFarX4nWy6VqRL1+eYigFq2 bUfBfnEuDr7JcjU2NKXKFuxHzH/Io3mhYemsiNcqEViVC+BxTqZQ21YKELgoOJMKdEWw X7zTy675ce2DfVcJlk9A7mUjKw3984OIS7ygiA+TdmA+rZxGP0URFfD/+vY1HnQi0lSH plbjImIH7lksXqE2vPDYsDcce+iwGgVl0sKudm4WhNn9gVwMBQUWvO0cWTRTpDUgWsVb C6lUia2hLqsutVqoSotJ2fJ4y0MwkVKxKmbetE2Vn5YN3ECdpJI1HafzEbfgxc8fQ8Ah eIfg== X-Gm-Message-State: ALoCoQk7GhyIASKz7lhUWZ8SU/gahOFTu47DQqcefDswJF7V6gX3IMEpSXKoqCPaqGI7BplsJ9sL MIME-Version: 1.0 X-Received: by 10.129.115.68 with SMTP id o65mr6787489ywc.166.1447675609133; Mon, 16 Nov 2015 04:06:49 -0800 (PST) Received: by 10.31.132.147 with HTTP; Mon, 16 Nov 2015 04:06:49 -0800 (PST) Date: Mon, 16 Nov 2015 13:06:49 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Rusty Russell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 X-Mailman-Approved-At: Mon, 16 Nov 2015 13:40:57 +0000 Cc: Bitcoin Dev Subject: [bitcoin-dev] BIP99 and Schism hardforks lifecycle (was 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: Mon, 16 Nov 2015 12:06:51 -0000 On Mon, Nov 16, 2015 at 2:52 AM, Rusty Russell wrot= e: > 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 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=C3=B3n said: > You keep insisting that some consensus rules are not consensus rules whil= e > 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 mine= r, > 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 wrote: > 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 te= rm > 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 TX= s. > There are many technical differences between the two. For example, > technically the first allows coins to be created randomly while the secon= d > doesn=E2=80=99t. 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 amou= nt > of time=E2=80=94we saw this a few years ago with the LevelDB bug and agai= n 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=E2=80=99t know. No one kno= ws. 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) w= here 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 f= ork > 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 suspec= t > nodes and miners would get inline with consensus as soon as the fork even= t > 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 wrote: > On Sun, Nov 15, 2015 at 2:12 AM, Jorge Tim=C3=B3n > wrote: > > >>If the invisible hand of the market is what decides consensus rules inste= ad >> of their (still incomple) specification (aka libconsensus), then the mar= ket >> could decide to stop enforcing ownership. Will you still think that Bitc= oin >> 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, eve= n > 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 peop= le > 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.