Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0A7BDB8C for ; Mon, 19 Jun 2017 20:32:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot0-f179.google.com (mail-ot0-f179.google.com [74.125.82.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EC4C01A6 for ; Mon, 19 Jun 2017 20:32:24 +0000 (UTC) Received: by mail-ot0-f179.google.com with SMTP id r67so76335715ota.1 for ; Mon, 19 Jun 2017 13:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oqUGjD6pnx+4GKgfa0bXaGDbOgNeL4wQBfwVvaQo8Pg=; b=RZ4UbJtIR/e9tNab5GS3nr1fJloIJg2ITEQvwXY2tQtm+6/AMaemZU2ejE776/IZn9 Dw6YJdoD/04p9TPyaVcCczaCWYJ3+iNd59Abs2u6FcgbdWiQg1/AumKhbcEQyKyBIINI Yc8JLVLuhxWLQHu+Xb6w5O9gI+nawgpCQlXkubWyiol3VirPynjFfZiLuxUt5GV8ojM0 ZyyILgR6AZULbKl8pnEfDgZbkhp9wvZ3pooNfXIJXiL6h+eLau8Fxp0iiZCCxkzx56LF 2xZtXHhLOhiM18Mh8/Utpe98mpfWGIsSkcBCFgkHd7f4YiG1nsQOY368D712GQwZWjje 0M2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oqUGjD6pnx+4GKgfa0bXaGDbOgNeL4wQBfwVvaQo8Pg=; b=MYVFUub0I8MBOiS6VMND8YYlyHj79U/p30zq63388lEOQIp+vpzamuEKoHX516cVfL uZWrKe50bMqBSR5xXBUuxHgbjN70Br0L5vaCqEUWrLRuFQMBMkeoe6J0kCLzvXq9mzYI mMgFzE9+4Hv+3lOVuYx1Lv/CHd1d1ordZrtiSmCSrZ/ZVE3hIn+KorIQdA/eCG7GpOCg vajNQssDDoRUiNanbtOHNzuIiK5Gow1J2edJAosWZf9nKkPYTs7XZ/mgxOW2l2qEB/ly 0tE4gghaBz/t661SbonU6wySqXJ15y5889MNSAA3v6jVihab+pKWXjl/MyV3kJGTTfqz 2hLQ== X-Gm-Message-State: AKS2vOxJr21o9QMPAg0MxEcTD1TaWXitX2wcbzkcivQZLfIRLBakiJZP 4Czw7gjbuuZ6t01AReEPL2jn2XasR2qDLZg= X-Received: by 10.157.48.135 with SMTP id s7mr3920437otc.171.1497904344209; Mon, 19 Jun 2017 13:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.43.100 with HTTP; Mon, 19 Jun 2017 13:32:23 -0700 (PDT) In-Reply-To: References: From: Moral Agent Date: Mon, 19 Jun 2017 16:32:23 -0400 Message-ID: To: Wang Chun <1240902@gmail.com> Content-Type: multipart/alternative; boundary="f4030435c0585821ae05525608ed" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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, 19 Jun 2017 20:41:46 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat 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: Mon, 19 Jun 2017 20:32:26 -0000 --f4030435c0585821ae05525608ed Content-Type: text/plain; charset="UTF-8" Here is the text of a post to reddit from Feb 2017, discussing a similar idea, and wondering if it could reduce the incentive to delay broadcast of solved blocks: # How an anchored Proof of Stake Sidechain can help the Bitcoin main chain # Steps: 1. Soft fork Bitcoin to enable side chains 2. Create a side chain that is secured with Proof of Stake. Call blocks on this chain "POS-blocks." The original chain is made of "POW-blocks." 3. Side chain mints one POS-block after each POW-block on the main chain, and contains the hash of the POW-block, and the hash of the previous POS-block. See diagram [here.](https://s32.postimg.org/916n9zxlx/Pos_Sf1.png ) 4. Side chain Minters must make a deposit in order to mint. If they mint an invalid POS-block, they lose the deposit. 5. Side chain blocks are small enough to broadcast and validate quickly (e.g. 100 - 300 KB). 6. Soft fork a new rule into Bitcoin that encourages POW-blocks to include the hash of the prior POS-block. Specifically, penalize POW-blocks which do not point to the prior POS-block by doubling the difficulty necessary for them to be valid. Call POW-blocks which do not point to the prior POS-block but are valid because of their very high POW "hard blocks." In the following diagram POW2 and POW4 are valid because they point to the prior POS-block and also satisfy the difficulty requirement. POW3 does not point to the prior POS-bock, but is valid anyway because it contains proof of work at twice the normal difficulty. https://s27.postimg.org/6hc0b8ejn/Pos_Sf2.png # Advantages: 1. Allow people who do not control ASICs to influence which transactions happen. 2. Allow people who do not control ASICs to influence which chain gets extended. 3. Reduce the incentive to selfish mine. Once a miner discovers a block, they should broadcast it immediately in the hopes that a Minter will build on it, because that is the most likely way their block will not go stale. Miners will also immediately start trying to build a hard block. (Maybe statistics could tell us what is the proper range for the Hardness Multiplier. I guessed 2 would be good.) 4. Reduces the effective block interval while reducing the incidence of stale blocks, empty blocks and SPV mining. After a POW-block is mined, it is immediately broadcast to the network, seeking a qualified Minter to extend it. Minters have a deposit, which they will lose if they mint an invalid block. Pointing to the hash of an invalid POW-block would produce an invalid minted block, so Minters have a strong incentive to completely validate the POW-block before they mint on top of it. After validating, they mint a block and broadcast it. While the Minter is validating the previous POW-block, competing miners also have time to fully validate the previous POW-block. By the time the Miners receive the POS-block, they know what transactions they can and cannot include in their own block, because the Minter only processes transactions on the side chain. There is less reason to mine empty blocks, because there is adequate time to update the mempool before mining the next soft block begins, and because hard blocks take a long time to produce. The risks involved with mining on an un-validated POS-block can be made small by the fact that there is a deposit that will be destroyed if the POS-block is invalid. POS-blocks can be validated quickly because they are small. Here is a gantt chart of the schedule described above: https://s22.postimg.org/hvnkyac5d/Pos_Sf3.png 5. Unlike a pure POS system, a cabal of early Stake holders cannot cheaply hatch an alternate history. Much less imperative for nodes to go to a trusted peer and ask whether the chain they are being fed is legitimate. 6. After step 6 above, the side chain would have essentially the same security characteristics as the main chain, and could be used interchangeably. 7. No hard fork required, and this soft fork could be deployed even if the miners do not consent to it. Some hybrid POS system would be my recommendation as preferable to simply changing POW algorithms in the face of miners abusing their power. 8. Users can opt into the POS sidechain, and it can fully prove itself in production before there is any attempt to anchor the main chain back to it. Even if consensus cannot be obtained to execute step 6, the mere existence of such a chain could deter tomfoolery on the part of POW miners, lest they galvanize the community into throwing the switch. Original reddit post here: https://www.reddit.com/r/Bitcoin/comments/5vy4qc/how_an_anchored_proof_of_stake_sidechain_can_help/ --f4030435c0585821ae05525608ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is the text of a post to reddit from Feb 2017, d= iscussing a similar idea, and wondering if it could reduce the incentive to= delay broadcast of solved blocks:

# How an anchor= ed Proof of Stake Sidechain can help the Bitcoin main chain
<= br>
# Steps:

1. Soft fork Bitcoin to ena= ble side chains

2. Create a side chain that is sec= ured with Proof of Stake. Call blocks on this chain "POS-blocks."= The original chain is made of "POW-blocks."

=
3. Side chain mints one POS-block after each POW-block on the main cha= in, and contains the hash of the POW-block, and the hash of the previous PO= S-block. See diagram [here.](https://s32.postimg.org/916n9zxlx/Pos_Sf1.png)
4. Side chain Minters must make a deposit in order to mint. If= they mint an invalid POS-block, they lose the deposit.

5. Side chain blocks are small enough to broadcast and validate quick= ly (e.g. 100 - 300 KB).

6. Soft fork a new rule in= to Bitcoin that encourages POW-blocks to include the hash of the prior POS-= block. Specifically, penalize POW-blocks which do not point to the prior PO= S-block by doubling the difficulty necessary for them to be valid. Call POW= -blocks which do not point to the prior POS-block but are valid because of = their very high POW "hard blocks."

In th= e following diagram POW2 and POW4 are valid because they point to the prior= POS-block and also satisfy the difficulty requirement. POW3 does not point= to the prior POS-bock, but is valid anyway because it contains proof of wo= rk at twice the normal difficulty.


# Advantages:

1. Allow people who do not control ASICs to influence which transact= ions happen.

2. Allow people who do not control AS= ICs to influence which chain gets extended.

3. Red= uce the incentive to selfish mine. Once a miner discovers a block, they sho= uld broadcast it immediately in the hopes that a Minter will build on it, b= ecause that is the most likely way their block will not go stale. Miners wi= ll also immediately start trying to build a hard block. (Maybe statistics c= ould tell us what is the proper range for the Hardness Multiplier. I guesse= d 2 would be good.)

4. Reduces the effective block= interval while reducing the incidence of stale blocks, empty blocks and SP= V mining. After a POW-block is mined, it is immediately broadcast to the ne= twork, seeking a qualified Minter to extend it. Minters have a deposit, whi= ch they will lose if they mint an invalid block. Pointing to the hash of an= invalid POW-block would produce an invalid minted block, so Minters have a= strong incentive to completely validate the POW-block before they mint on = top of it. After validating, they mint a block and broadcast it. While the = Minter is validating the previous POW-block, competing miners also have tim= e to fully validate the previous POW-block. By the time the Miners receive = the POS-block, they know what transactions they can and cannot include in t= heir own block, because the Minter only processes transactions on the side = chain. There is less reason to mine empty blocks, because there is adequate= time to update the mempool before mining the next soft block begins, and b= ecause hard blocks take a long time to produce. The risks involved with min= ing on an un-validated POS-block can be made small by the fact that there i= s a deposit that will be destroyed if the POS-block is invalid. POS-blocks = can be validated quickly because they are small.

H= ere is a gantt chart of the schedule described above:

<= div>https://s22.p= ostimg.org/hvnkyac5d/Pos_Sf3.png

5. Unlike= a pure POS system, a cabal of early Stake holders cannot cheaply hatch an = alternate history. Much less imperative for nodes to go to a trusted peer a= nd ask whether the chain they are being fed is legitimate.

6. After step 6 above, the side chain would have essentially the s= ame security characteristics as the main chain, and could be used interchan= geably.

7. No hard fork required, and this soft fo= rk could be deployed even if the miners do not consent to it. Some hybrid P= OS system would be my recommendation as preferable to simply changing POW a= lgorithms in the face of miners abusing their power.

8. Users can opt into the POS sidechain, and it can fully prove itself i= n production before there is any attempt to anchor the main chain back to i= t. Even if consensus cannot be obtained to execute step 6, the mere existen= ce of such a chain could deter tomfoolery on the part of POW miners, lest t= hey galvanize the community into throwing the switch.

= Original reddit post here:

--f4030435c0585821ae05525608ed--