Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B15512F7 for ; Mon, 19 Feb 2018 01:29:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a1.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9107AF8 for ; Mon, 19 Feb 2018 01:29:53 +0000 (UTC) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 1DBD734806D for ; Sun, 18 Feb 2018 17:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:mime-version:subject:message-id:date:to; s= taoeffect.com; bh=j2TsQp1sazXweFjoucBT1ue5/bU=; b=W1bvhjduFBSmE4 KDhwgvS3yrDGeDix8NXsGEwi4z34ottrbXkqpw27zzErBbJVDzY+4WrE3I9bJAIa uDTWjGxHiqtmgNHgf+SycKNwc60K6/yuNo3YB6Hoax7FvvC79ctz/bEn2LL3VZAc EH15fbFcmapdbzGaZJ+Ff9O3IdT7k= Received: from [10.0.0.144] (unknown [98.204.186.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 8C88334806C for ; Sun, 18 Feb 2018 17:29:52 -0800 (PST) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_F48E5B27-5B1F-4DC1-A2EA-A6C5B7A8C210"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 540696590.017848-24cad1fc5e8abd8773746eb3e1e400b2 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> Date: Sun, 18 Feb 2018 20:29:50 -0500 To: Bitcoin Protocol Discussion X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 03:01:27 +0000 Subject: [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 01:29:54 -0000 --Apple-Mail=_F48E5B27-5B1F-4DC1-A2EA-A6C5B7A8C210 Content-Type: multipart/alternative; boundary="Apple-Mail=_CD2E08A2-E0A6-4EDF-9A75-AFAE8F1D4DA1" --Apple-Mail=_CD2E08A2-E0A6-4EDF-9A75-AFAE8F1D4DA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Copied from: = https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pu= ll/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 = Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate = with the same security guarantees without it (except as noted in [Risks = and Mitigations](#risks-and-mitigations)), and therefore does not need = miners to maintain 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 block. - The number of coins issued per block is now tied directly to the = difficulty of the block, and the concept of "epocs" or "block reward = halving" is removed. - 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 more 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 = 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 lower = reward, but there are more of them. If they produce blocks slowly, each = 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 longer needs to = be used for anything, or represent anything significant other than = metadata about 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 = transaction 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 blocks at a fast rate, potentially resulting in = additional centralization pressures not only on miners 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 this if we are = given the liberty of modifying the protocol as we wish: 1. Introducing state checkpoints into the chain itself could 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 "sufficiently 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 with the NSA. --Apple-Mail=_CD2E08A2-E0A6-4EDF-9A75-AFAE8F1D4DA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-sp= ring2018/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 Bitcoin's blockchain may be unnecessary, and that Bitcoin = can operate with the same security guarantees without it (except as = noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore = does not need miners to maintain 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 block.
- = The number of coins issued per block is now tied directly to the = difficulty of the block, and the concept of "epocs" or "block reward = halving" is removed.
- 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 = more 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 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 = lower reward, but there are more of them. If they produce blocks slowly, = each 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 longer = needs to be used for anything, or represent anything significant other = than metadata about 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 transaction 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 blocks at a fast rate, = potentially resulting in additional centralization pressures not only on = miners 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 this if we are given the = liberty of modifying the protocol as we wish:

1. Introducing state checkpoints into = the chain itself could 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 = "sufficiently 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 with the NSA.

= --Apple-Mail=_CD2E08A2-E0A6-4EDF-9A75-AFAE8F1D4DA1-- --Apple-Mail=_F48E5B27-5B1F-4DC1-A2EA-A6C5B7A8C210 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgYtgnomHliYDCUth7GcgK+kJUkcFAlqKKI4ACgkQ7GcgK+kJ Uke1EQ/+KMJmHmFpUNF/c7jGtiKQRf5O0Cqc6mIUZSyJbUC8Nr8EiAdTUT50kUhL KKlZXKN5FNJKRNMG/Ug78821Z9qNEwBA9twkZoKB5U2ZOlq/mzPlyCBTNt+MJfr/ VGnrPdEZTkvf1VtACouAPAZV6WOjEQS801bFUehX4eAdfT3YR8yfURDpLDo14Pdb kvZKWJTLZeLXRzek/RbzsO20orpcqY6J37E70tLY5/0rE2S97D+jtWaCsbZ0fiGy YgDV+HURFr8zyl7SrkBUw1Rp8G31xfGBUMKjB4dUI5uRQxqv7nuPpMKxsASmXUEB 4HISoMLBF2wiHw3CFgzxV80W3vpmTE5bWyAN41Wi3EAsbpryvXf9ZnYqJl/k9CRf EyYfDuhS2IsPHuQR7WYL+YM12U1/SY50WhNOf6zdB/PHMxmG/RlARp9Ya6vBH2KL zIxEea6vrJW4pipCnctdpX+AiwYKme7hA4+iAr43NkOLOMWe8fjGY57jItX8QreV Tnk1KlZ1ibLHAru8q1lm9FhCjtEXiayi1yOhJiZCmScnC89S9WsY/59fwglZaa/0 r53y0y3/HyTxYGTKNpJ6lRfzZnDENqzuebI3DaOf4NnsDjOQzeJCVBNKxX2DEnKf bVL7CBEHSVkQkmIr1pWkAjQOlS8Q/iMXpMP6YZzNQISBRf9+J24= =smY0 -----END PGP SIGNATURE----- --Apple-Mail=_F48E5B27-5B1F-4DC1-A2EA-A6C5B7A8C210--