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 EB8D3F2B for ; Wed, 20 Apr 2016 15:57:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 29D13A6 for ; Wed, 20 Apr 2016 15:57:02 +0000 (UTC) Received: by mail-qk0-f174.google.com with SMTP id r184so15745275qkc.1 for ; Wed, 20 Apr 2016 08:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=1q22MNtC8KdUZsRMM/ebZaRKx0jjZk0E8SqZS2A6M0A=; b=jWTQFFQ3Z/vhmy/LN/DnaHwtNNeqVWo2aaZUDdjZMIq7i8fuI2f+ZxEhSegf7RvCYX tazb9FufsRkeSoRKl6F5PxNzGdb8GNs7x8j9+5+f6WZqR3qDLMA8rJbA4LRV0NI6Pymg KsFBy9gCq/FmKh91OIO1VuzuVpTel1z+kGIaHKhehrmzncSuZePUgRz6iSA7s/TUajUC HVCpHseTSBI6TRPRBfoUEVlI891Kfy7a4OqiPkT5a/hUxAi1sP/BUTzDJ9PoqymUnWAb FLqDL/u59dx6amqndJpgOYCd1Tjwp1SLEAuC5/jKHxTcz5PkMBFgGYjxPJbmgTxM/nyE 7jRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=1q22MNtC8KdUZsRMM/ebZaRKx0jjZk0E8SqZS2A6M0A=; b=eA8eLcdDBPZ8k9YVZEwRSUax75BUX0cItgOCdyTWXbOAAGJ1QdkYmmP82jT0aypX0a 3ouNvkMo8QlI4Q/Rnahjex1wGz29uHCUuuDhUV7dUy5DaDX3guw3roO1LygfFXRh81MU 846y7uff97zIKnJM2TCnr86bQb42OfGi/CvpIDKxZnIz/9d08UALrt5+bn1nz3yP0NR9 MleHXDuolZV7MSW2QUmRQqi38fpkpQZqXt++rFckEJmFUKjjLw7CcvtsCRx1GtN49Gz6 xH+VzP9QVLMKtUMRz0nOz+ieWwddbmP33ZCm1JOT1mTUabhymsF6EyMogr7NSXYk/ccq dMJg== X-Gm-Message-State: AOPr4FVJ/IqK2xZgIb2CUaOpQSSKz3n9xYh7laIcctALVFTJoy1sOTOxiH+7GVU8qPUSeQ== X-Received: by 10.55.11.4 with SMTP id 4mr12476187qkl.92.1461167821262; Wed, 20 Apr 2016 08:57:01 -0700 (PDT) Received: from [192.168.1.105] (ool-4575fa8d.dyn.optonline.net. [69.117.250.141]) by smtp.googlemail.com with ESMTPSA id r130sm2174460qha.25.2016.04.20.08.57.00 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2016 08:57:00 -0700 (PDT) To: Bitcoin Dev From: Paul Sztorc Message-ID: <5717A6C9.1030702@gmail.com> Date: Wed, 20 Apr 2016 11:56:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Wed, 20 Apr 2016 17:06:15 +0000 Subject: [bitcoin-dev] Sidechains pre-BIP Discussion 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: Wed, 20 Apr 2016 15:57:03 -0000 Dear list, This message concerns pegged "sidechains", namely the Two Way Peg [1]. Specifically, it is to introduce a new OP Code (perhaps called "OP_CheckVotesVerify"). This OP code can be deployed by soft fork, and has (as we all probably know) many benefits, including: 1. ("Optional hard forks") Sidechains allow 'opt in' adoption of new features. As a result, Bitcoin (the bearer asset, not the software) will never need to worry about competing with an alternate system. This includes competitors such as Ripple or Ethereum (supposedly "innovative"), as well as BitcoinXT and Bitcoin Classic (supposedly "popular"). 2. ("Staging Upgrades") SCs allow complex updates to Bitcoin to be tested, in a realistic environment (where actual BTC are at risk, and utilizing actual network mining resources). If these updates fail, they can be revised; if they succeed, they can be incorporated into the mainchain. 3. Directing "blockchain resources" to Bitcoin. This includes money, developer talent, public attention, etc. 4. Less time spent debating controversial features. Instead, we return to a culture of "permissionless innovation". Again, as we all know, the concept has generally received high interest and favorable appraisal. -- However, this feature has highly complex effects on the Bitcoin ecosystem, and so the details should command our full attention. First, the deployment of this OP Code involves new block validation rules ("Drivechain") which are described on my blog [2]. In addition to that post, I intend to release short presentations: 1. On the overall design justification. 2. On "Enforcing Limits on Shared Resources". This explores the potential for SCs to have a detrimental effect on users of vanilla BTC, and how this proposal confronts these problems. 3. On the governance of SCs-- aka the degree of 'coupling', inter-relatedness, and/or hierarchy --- and how Drivechain's design acts to maximize the total value of the "chain portfolio". My purpose, in emailing today, is to begin the conversation. The scope of the concept is simply too large, to draft a readable BIP without knowing what the actual points of interest are. Please express your reactions! Thank you for reading, Paul P.S. In assessing the proposal, you may find a recent technical paper [3] by Sergio Demian Lerner to be of interest. -- [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004724= =2Ehtml [2] http://www.truthcoin.info/blog/drivechain/ [3] http://www.rootstock.io/#resources ( https://uploads.strikinglycdn.com/files/27311e59-0832-49b5-ab0e-2b0a73899= 561/Drivechains_Sidechains_and_Hybrid_2-way_peg_Designs_R9.pdf )