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 31EA11126 for ; Mon, 19 Feb 2018 09:04:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255052.outbound.protection.outlook.com [40.92.255.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A40B6FE for ; Mon, 19 Feb 2018 09:04:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6iRpDAzqazavVc0whNVqe3vaRaQ25cFkNS8rY4DgNpM=; b=A3iPU/rIZu6e8Rkn6TdW9+cbsQvUyiCb4lUl8JLP8aAjQHUAN2GDZrC2tEgRuyyg4cRGYtPZ/9dnkyrQomfxF9jLzYdUdwLSJO25peR7QO+JgU9AJeyl7nIQWb14+1KBhvM+8XHkbon5ZYBRWcfwFSlgrIXZHt0z1RUvrgCYwuzId6qu0B09PhpjL5S5H00HzOmDsagPu/w9u9X9URpYQ3crhfugxhrF25OrnxNnFR3D25zbpnOAB9TDLA9ZsWPNpiyndkhtc/Zx3NvgbpkB5D+933SVuS0mYXeU6S51fi2vdr9294SCYpZwINCkv8Letgefo441dK9zKRk5uKgvkA== Received: from SG2APC01FT053.eop-APC01.prod.protection.outlook.com (10.152.250.57) by SG2APC01HT030.eop-APC01.prod.protection.outlook.com (10.152.251.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.506.19; Mon, 19 Feb 2018 09:04:02 +0000 Received: from PSXP216MB0181.KORP216.PROD.OUTLOOK.COM (10.152.250.58) by SG2APC01FT053.mail.protection.outlook.com (10.152.250.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.506.19 via Frontend Transport; Mon, 19 Feb 2018 09:04:02 +0000 Received: from PSXP216MB0181.KORP216.PROD.OUTLOOK.COM ([10.174.19.149]) by PSXP216MB0181.KORP216.PROD.OUTLOOK.COM ([10.174.19.149]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 09:04:02 +0000 From: Damian Williamson To: Tao Effect , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Some thoughts on removing timestamps in PoW Thread-Index: AQHTqS4XPtJIvftsJU6GmaABHRoECqOrbXSh Date: Mon, 19 Feb 2018 09:04:02 +0000 Message-ID: References: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> In-Reply-To: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:93534FE9EEC266BBBA6262B744FFE7A9F7830BF00E94B15B52F7C6CDC5F78FB8; UpperCasedChecksum:52684B1CC792B26CD05B5F18474E3FAC8C5028B4F51865E216159AB8998F5A95; SizeAsReceived:7092; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Ob55l/uKAE0BFbT9f02+fxaVGMXCqcYX] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SG2APC01HT030; 6:z/JHwudu1RQhWqI7kApIxTFq4/ECdaPFYDf1lpb2Wh1CUH106wfvypNIUBTdhM5reQKMQX7K2k61ZMnJW3JCqdBfle+JcgDfZpF8j0x4QAtr0RYEUZCJsc9Rh62SHJYQ3YrAgnFxaLbuskrXPiBp6951nFah7Ah8HYi4lcRqaYPy1b7QAfbkCOaPEkj36PLixSV2WzbjU60sqeMSSZa8sgyr1KEHp+D++n1g9IM34tsvXkD5aJOwAe7xrs6gr00lPrzqyAf7mZIoLehVO/9WdixNDmnOfm2KVOsxPyDy7N0GD+jLKWFIBfHA8fSIEvTNPiRYyPkBQkuIsfY6N7wzlWygZspLTbWdmHqfJKeA+oU=; 5:dUU7F9e9FwJkZ63jUdxsTDIIy106shj7ujKbVY64b1tZs4GzoAdHLZ74Nrb9FVvsd8EXr9moKsJD0QjCe1wcqf3kyDq3msxhg5jw/bV9zZlF3WHQg7ZUdBe57w3lkD8X29uSfu8Veg3JDK01aj58nCobI5j5aONji0WvSdV1mOM=; 24:66+XstDsw+kbY2ru6kgfMLHb8DPZEUcSTyqR7qRzJTfzCLGnIYMvhqyPH9sWTBSG0pGxwNT0B5Vsp74BBQh3Rwx2AnkRH7Nhy4tXKdNfEi8=; 7:zj++0bXQnLpkzzJMTcbMnmh44c3qf8bDWjdfavdK3YC1zWLoaTymon0dvGiAptFDI498lXR2N3iD0oAi7nw7fM5nm5ifgA7DrhkRDWWw7+0VWCmHUtDiyg/w8yjG0HDurI6Z3pt4lKUKj20/stTFQfN6Nv4NRslbtMsBgFrMYMaPXrx+sUeU+2m+00LVFM7+DrmdZCCZjNPdwIh42DGaBakYWaN0Qb0yGWU+t4GO9zdSQoDrk7fvCoW9H65S/hgg x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SG2APC01HT030; x-ms-traffictypediagnostic: SG2APC01HT030: x-ms-office365-filtering-correlation-id: 5bd165a1-d043-418d-7625-08d57777b8cf x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SG2APC01HT030; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT030; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT030; H:PSXP216MB0181.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PSXP216MB0181312DCCA46A1F9A276D799DC80PSXP216MB0181KORP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5bd165a1-d043-418d-7625-08d57777b8cf X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 09:04:02.5710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT030 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Feb 2018 14:27:50 +0000 Subject: Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW 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 Feb 2018 09:04:07 -0000 --_000_PSXP216MB0181312DCCA46A1F9A276D799DC80PSXP216MB0181KORP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >1. Introducing state checkpoints into the chain itself could make it possi= ble for full nodes to skip verification of large sections of historical dat= a when booting up. What you are suggesting, unless I am mistaken, is that new full nodes shoul= d have no way of knowing if an output is spent or even if it exists. Since = large sections of the blockchain will potentially be skipped, the full node= will not have complete knowledge of utxo's just for starters. Regards, Damian Williamson ________________________________ From: bitcoin-dev-bounces@lists.linuxfoundation.org on behalf of Tao Effect via bitcoin-dev Sent: Monday, 19 February 2018 12:29:50 PM To: Bitcoin Protocol Discussion Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-s= pring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect@mastodon.social](https://mastodon.social/@taoeffect))* ---- The Bitcoin blockchain has a 10-minute target blocktime that is achieved by= a difficulty adjustment algorithm. I assert, or rather, pose the hypothesis, that the use of timestamps in Bit= coin's blockchain may be unnecessary, and that Bitcoin can operate with the= same security guarantees without it (except as noted in [Risks and Mitigat= ions](#risks-and-mitigations)), and therefore does not need miners to maint= ain global clock synchronization. The alternative difficulty adjustment algorithm would work according to the= following principles: - The incentive for miners is and always has been to maximize profit. - The block reward algorithm is now modified to issue coins into perpetuity= (no maximum). Any given block can issue _up to_ `X` number of coins per bl= ock. - The number of coins issued per block is now tied directly to the difficul= ty of the block, and the concept of "epocs" or "block reward halving" is re= moved. - The chain selection rule remains "chain with most proof of work" - The difficulty can be modified by miners in an arbitrary direction (up or= down), but is limited in magnitude by some maximum percentage (e.g. no mor= e than 20% deviation from the previous block), we call this `Y%`. ### Observations - Miners are free to mine blocks of whatever difficulty they choose, up to = a maximum deviation - The blockchain may at times produce blocks very quickly, and at other tim= es produce blocks more slowly - Powerful miners are incentivized to raise the difficulty to remove compet= itors (as is true today) - Whether miners choose to produce blocks quickly or slowly is entirely up = to them. If they produce blocks quickly, each block has a lower reward, but= there are more of them. If they produce blocks slowly, each block has a hi= gher reward, but there are fewer of them. So an equilibrium will be natural= ly reached to produce blocks at a rate that should minimize orphans. A timestamp may still be included in blocks, but it no longer needs to be u= sed for anything, or represent anything significant other than metadata abo= ut when the miner claims to have produced the block. ### Risks and Mitigations Such a system may introduce risks that require further modification of the = protocol to mitigate. The most straightforward risk comes from the potential increase in total tr= ansaction throughput that such a change would introduce (these are the same= concerns that exist with respect to raising the blocksize). The removal of= timestamps would allow a cartel of miners to produce high-difficulty block= s at a fast rate, potentially resulting in additional centralization pressu= res not only on miners but also on full nodes who then would have greater d= ifficulty keeping up with the additional bandwidth and storage demands. Two equally straightforward mitigations exist to address this if we are giv= en the liberty of modifying the protocol as we wish: 1. Introducing state checkpoints into the chain itself could make it possib= le for full nodes to skip verification of large sections of historical data= when booting up. 2. A sharded protocol, where each shard uses a "sufficiently different" PoW= algorithm, would create an exit for users should the primary blockchain be= come captured by a cartel providing poor quality-of-service. -- Please do not email me anything that you are not comfortable also sharing w= ith the NSA. --_000_PSXP216MB0181312DCCA46A1F9A276D799DC80PSXP216MB0181KORP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>1. Introducing state ch= eckpoints into the chain itself could make it possible for full nodes to sk= ip verification of large sections of historical data when booting up= .


What you are suggesting, unless I= am mistaken, is that new full nodes should have no way of knowing if an ou= tput is spent or even if it exists. Since large sections of the blockchain = will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters.


Regards,

Damian Williamson

From: bitcoin-dev-bounces@l= ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Tao Effect via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.org>
Sent: Monday, 19 February 2018 12:29:50 PM
To: Bitcoin Protocol Discussion
Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW
 
Copied from: https://githu= b.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13


# Blockchain Timestamps Unnecessary In Proof-of-Work?

*Author: Greg Slepak ([@taoeffect@mastodon.social](https://mastodon.social/@taoeffect))= *

----

The Bitcoin blockchain has a 10-minute target blocktime tha= t is achieved by a difficulty adjustment algorithm.

I assert, or rather, pose the hypothesis, that the use of t= imestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can = operate with the same security guarantees without it (except as noted in [R= isks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronizatio= n.

The alternative difficulty adjustment algorithm would work = according to the following principles:

- The incentive for miners is and always has been to maximi= ze profit.
- The block reward algorithm is now modified to issue coins= into perpetuity (no maximum). Any given block can issue _up to_ `X` number= of coins per block.
- The number of coins issued per block is now tied directly= to the difficulty of the block, and the concept of "epocs" or &q= uot;block reward halving" is removed.
- The chain selection rule remains "chain with most pr= oof of work"
- The difficulty can be modified by miners in an arbitrary = direction (up or down), but is limited in magnitude by some maximum percent= age (e.g. no more than 20% deviation from the previous block), we call this= `Y%`.

### Observations

- Miners are free to mine blocks of whatever difficulty the= y choose, up to a maximum deviation
- The blockchain may at times produce blocks very quickly, = and at other times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty = to remove competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly= is entirely up to them. If they produce blocks quickly, each block has a l= ower reward, but there are more of them. If they produce blocks slowly, eac= h block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce = blocks at a rate that should minimize orphans.

A timestamp may still be included in blocks, but it no long= er needs to be used for anything, or represent anything significant other t= han metadata about when the miner claims to have produced the block.

### Risks and Mitigations

Such a system may introduce risks that require further modi= fication of the protocol to mitigate.

The most straightforward risk comes from the potential incr= ease in total transaction throughput that such a change would introduce (th= ese are the same concerns that exist with respect to raising the blocksize)= . The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate,= potentially resulting in additional centralization pressures not only on m= iners but also on full nodes who then would have greater difficulty keeping= up with the additional bandwidth and storage demands.

Two equally straightforward mitigations exist to address th= is if we are given the liberty of modifying the protocol as we wish:

1. Introducing state checkpoints into the chain itself coul= d make it possible for full nodes to skip verification of large sections of= historical data when booting up.
2. A sharded protocol, where each shard uses a "suffic= iently different" PoW algorithm, would create an exit for users should= the primary blockchain become captured by a cartel providing poor quality-= of-service.


--
Please do not email me anything that you are not comfortable also sharing<= span class=3D"" style=3D"color:rgb(0,0,0); font-family:Helvetica; font-size= :14px; font-style:normal; font-weight:normal; letter-spacing:normal; text-a= lign:start; text-indent:0px; text-transform:none; white-space:normal; word-= spacing:0px; line-height:normal; orphans:2; widows:2"> with the NSA.

--_000_PSXP216MB0181312DCCA46A1F9A276D799DC80PSXP216MB0181KORP_--