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 6D4E0927 for ; Wed, 15 Nov 2017 02:13:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx.sdf.org (ol.sdf.org [205.166.94.20]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7E78846F for ; Wed, 15 Nov 2017 02:13:40 +0000 (UTC) Received: from mx.sdf.org (ol.freeshell.org [205.166.94.20]) by mx.sdf.org (8.15.2/8.14.5) with ESMTP id vAF2DV30023353 for ; Wed, 15 Nov 2017 02:13:31 GMT Received: from n165-156-000-000.static.ge.com ([165.156.138.25]) (SquirrelMail authenticated user creighto) by mx.sdf.org with HTTP; Wed, 15 Nov 2017 02:13:31 -0000 Message-ID: <5d7cceb34b3d49a0fc9822450e42c750.squirrel@mx.sdf.org> Date: Wed, 15 Nov 2017 02:13:31 -0000 From: creighto@sdf.org To: bitcoin-dev@lists.linuxfoundation.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD autolearn=disabled 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, 15 Nov 2017 02:41:09 +0000 Subject: [bitcoin-dev] Con-peg sidechain model X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:13:43 -0000 I posted the following on bitcointalk.org and slack bitcoinunlimited. This isn't a technical paper, just fleshing out my thoughts and hoping for some help & feedback. I understand bitcoin as well as any non-programer realisticly could, but I am not a programmer, so if this isn't feasible, someone please let me know why. -MoonShadow Con-Peg Sidechain Model I know that this is going to sound similar to the Fed-Peg model, so don't whine about that. It's not the Fed-Peg model, not quite, and the differences are critical, I believe. Every proposal that I've seen so far require some kind of soft or hard fork to the current bitcoin model, but I think that I've come up with a way to make a sidechain work without new modifications to the running bitcoin protocol. I think I will call it the Confederation-Peg model. Imagine a confederation of large corporations, all of which would benefit from the ability to process a large number of bitcoin transactions for net zero or near zero transaction fees. These corporations would, most likely, have to have the following characteristics... 1) Multi-national in scope, with employee bases in several different nations using several different fiat currencies. 2) Have a rather large employee base. 3) Not in direct competition with each other 4) and not dependent upon any particular government. With just a bit of google-fu, I will use the following corporations in this example... Wal-Mart, with more than 2 million employees worldwide. Volkswagon, with more than half a million employees worldwide. General Electric, with about 300K employees worldwide. and Johnson & Johnson, with More than 100K. Let's call these corporations the confederation sponsors. These sponsors would decide most of the sidechain's rules by consensus amongst themselves, but let me lay out, in general, how I think that such a sidechain can be set up so that the sidechain is secure while also contributing to the overall security of the main blockchain. First, these sponsors agree upon a deposit/escrow amount that they will each commit to a multi-sig address on the main blockchain; for a round number, let's say they all contribute 10 BTC to the cause. Next, they all agree that they must each either build or contract out bitcoin mining capability of a minimum standard; high enough that the collection of sponsors can mine a block on a regular interval. Let's say once each day. But when they mine a main blockchain block, they place into the 100 byte large "2nd nonce" space of the coinbase transaction the following data. 1) a code that identifies the sponsor who mined this block to the other sponsors, 2) the merkle tree root hash of the sidechain block that the sponsor is about to release on the sidechain network. 3) a cryptographic signing of the two prior pieces of data. (this might be unnecessary, I'm not sure) Once a sponsor's mining agent releases this block to the network, and it's accepted as valid by the main blockchain, The sponsor then releases the sidechain block to the other sponsors. This block can be of an arbitrarily large size; enough to accommodate all of the transactions that all of the sponsors (and their clients) have produced in the past day. Since it's likely that every sponsor has seen every valid transaction, this block might only include the merkle tree created by the most recent mining sponsor. This looks a lot like merged mining, but it's not, because the side chain doesn't use proof-of-work, and doesn't require it. It uses proof-of-authority. Specifically, releasing a valid block onto the main blockchain is the proof of the authority to release the next sidechain block. This achieves several things for the sponsors. 1) It contributes mining power to the main blockchain, thus supporting main chain security regardless of the profitability for those sponsor miners, since their incentive is to reduce the costs of their own transactions, not win mining rewards or fees. 2) It creates a definate timeline of the blockchain of the sidechain, without need for cryptographic proof-of-work, by tying each sidechain block to a known main chain block. Thus leveraging the main chain's security model without needing to attract miners willing to drop the main chain work to mine the sidechain. 3) It establishes a definitive authority amonst the sponsors about who has the right to publish the next block, as well as claim any sidechain transaction fees. 4) It allows all sponsors to keep each other honest, because if any sponsor were to cut back on their main chain mining responsibilities, they would all be able to tell. 5) It allows the sponsors to chose to accept as many free transactions as they like, which may or may not benefit themselves, 6) as well as keep any transaction fees that might have been issued on the sidechain, for which odds are high that they would have had to pay. Thus transaction fees most likely travel in a circle (for the sponsors, not the clients) In order to add btc to this sidechain, a main chain bitcoiner would have to send funds to one of the sponsors, after acquiring their agreement to issue sidechain coins using a special sidechain coinbase transaction that... 1) creates or destroys sidechain bitcoins 2) references the main chain transaction that would permit it 3) and identifies the sponsor creating the sidechain funds In this way, bitcoins can flow into the sidechain, and each of the sponsors can watch the other sponsors to make certain that they aren't creating more sidechain funds than their main chain holding would permit. I would imagine that the rule would be that a sponsor can't issue more side chain bitcoins than it has in it's public main chain addresses, and if that were to be violated, the other sponsors would automatically ignore their (otherwise valid) sidechain blocks. This security model requires more trust than the trustless model of the main blockchain, but permits the sidechain to structure itself in any way necessary to permit safe referencing of unconfirmed transactions, thereby permitting nearly instant follow-up transactions. Sponsors could also detect, and potentially punish, double spend attemps. Any other rapid transaction model, such as the Lightening Network, could be permitted to work on the sidechain; but I doubt they would be necessary. Sponsors could attract "clients" by a number of incentives. For example, Wal-mart could offer free sidechain transactions to any paying customer, as well as a limited number of main chain transactions to their own employees; whereas Johnson & Johnson might only offer free transactions to their employees and associated businesses. I can even imagine a deposit & (fully BTC reserve backed) sidechain credit system, complete with interest rates. Paid for transaction fees could be based upon whatever the sponsors agree to, including a transaction fee based upon a percentage of the transfer value instead of the byte-size of a transaction. This would make the fee model much closer to how current day credit card transfer fees work, but would almost certainly be less. Getting BTC back out of the sidechain (via the main chain) would work like a sponsor's coinbase transaction with a negative value, also referencing a valid transaction (which may or may not be confirmed yet) that can be seen on the main bitcoin network. Alternatively, in a world where several such sidechains exist, sponsors of one sidechain could be clients on another, potentially permitting value to transfer from one sidechain directly to another without creating a main blockchain transaction at all. The details of the rules of both sidechains would matter in this possibility. Since declaring weeknesses of one's own ideas is a convention in the cryptocurrency world, let me begin... Since this is a some-trust model; i.e. individuals have to trust an institution, at least a little bit, in order to get onto the sidechain. It's possible that a sponsor might take your main chain BTC and claim you never sent them, but you'd still have the transaction you produced, so you'd still have recourse through traditional courts. Moving funds in the other direction, it's possible for your leaving transaction to be blocked, but only if all of the sponsors refuse to deal with you. Likewise, as a client, your ability to transact on the sidechain could be hindered or blocked by the sponsors, but only if all of them blacklist you. But that only risks the possibility that you can't spend your bitcoins on the sidechain, not that the sponsors could take them from you without your participation. This is a move towards some centralization, yes; but not for bitcoin as a whole. For the most part, "clients" choose whether the lower transaction costs & convenience at these institutions is worth the re-addition of trust to some portion of their bitcoin activities. Perhaps employees don't get a choice about being a client on this sidechain, but they still get to choose if they work for a sponsor. This low-trust model depends upon the idea that the sponsors don't entirely trust one another, and will keep an eye on each other for bad behavior; much in the same way that the banks of the free banking era would occasionally challenge one another to produce the gold for the currencies they issued, either driving them out of business or harming their businesses should they misbehave. It also depends upon the idea that, for the "clients", no one on the sidechain has more to lose from getting caught defrauding a client than the sponsors themselves, because the integrity of the sidechain and of their own reputations are of great value to the sponsors. It's possible that all sponsors turn to the dark side at once, crash the sidechain & steal all of the main chain bitcoins in their reserve addresses. Since this isn't one trusted authority, but many in a trust-distrust relationship (and in different industries) this possibility seems remote to me. I could also imagine sidechains that were explicitly not worldwide in scope, such as those limited to a particular nation or economic block. I.E., there might be a Eurozone specific sidechain, a United States specific sidechain (but would that be redundant?) and a Francophone sidechain. There might be a sidechain for Portuguese speaking nations around the world, or a sidechain just for nations in South America that don't speak Portuguese. There could be a sidechain that exists entirely on Tor, using high anonymity rules; or a sidechain sponsored by governments for the expressed purpose of paying taxes (but who would join this voluntarily?) Many people have complained that Bitcoin isn't anonymous, because the entire transaction history is visible. Sidechains would fix that immediately, even without improved anonymity rules. For that matter, since the extra-nonce space available in the coinbase transaction is 100 bytes, that's enough to record an entire sidechain block header anyway, so there might not be any reason to record the headers anyplace else.