path: root/4b/1e2aa65e9b78d5869b1ff9a545b34f8d21e77a

Return-Path: <contact@taoeffect.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B15512F7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 18 Feb 2018 17:29:52 -0800 (PST)
From: Tao Effect <contact@taoeffect.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 =
<https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/p=
ull/13>


# Blockchain Timestamps Unnecessary In Proof-of-Work?

*Author: Greg Slepak ([@taoeffect@mastodon.social =
<mailto:taoeffect@mastodon.social>](https://mastodon.social/@taoeffect =
<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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"><meta http-equiv=3D"Content-Type" content=3D"text/html=
 charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">Copied from:&nbsp;<a =
href=3D"https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-sprin=
g2018/pull/13" =
class=3D"">https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-sp=
ring2018/pull/13</a></div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D""># Blockchain Timestamps =
Unnecessary In Proof-of-Work?</div><div class=3D""><br =
class=3D""></div><div class=3D"">*Author: Greg Slepak ([@<a =
href=3D"mailto:taoeffect@mastodon.social" =
class=3D"">taoeffect@mastodon.social</a>](<a =
href=3D"https://mastodon.social/@taoeffect" =
class=3D"">https://mastodon.social/@taoeffect</a>))*</div><div =
class=3D""><br class=3D""></div><div class=3D"">----</div><div =
class=3D""><br class=3D""></div><div class=3D"">The Bitcoin blockchain =
has a 10-minute target blocktime that is achieved by a difficulty =
adjustment algorithm.</div><div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">The alternative =
difficulty adjustment algorithm would work according to the following =
principles:</div><div class=3D""><br class=3D""></div><div class=3D"">- =
The incentive for miners is and always has been to maximize =
profit.</div><div class=3D"">- 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.</div><div class=3D"">- =
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.</div><div class=3D"">- The chain selection rule =
remains "chain with most proof of work"</div><div class=3D"">- 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%`.</div><div class=3D""><br class=3D""></div><div class=3D"">### =
Observations</div><div class=3D""><br class=3D""></div><div class=3D"">- =
Miners are free to mine blocks of whatever difficulty they choose, up to =
a maximum deviation</div><div class=3D"">- The blockchain may at times =
produce blocks very quickly, and at other times produce blocks more =
slowly</div><div class=3D"">- Powerful miners are incentivized to raise =
the difficulty to remove competitors (as is true today)</div><div =
class=3D"">- 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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div class=3D""><br class=3D""></div><div class=3D"">### =
Risks and Mitigations</div><div class=3D""><br class=3D""></div><div =
class=3D"">Such a system may introduce risks that require further =
modification of the protocol to mitigate.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Two equally =
straightforward mitigations exist to address this if we are given the =
liberty of modifying the protocol as we wish:</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">
<span style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; font-variant-ligatures: normal; =
font-variant-position: normal; font-variant-numeric: normal; =
font-variant-alternates: normal; font-variant-east-asian: normal; =
line-height: normal; orphans: 2; widows: 2;" class=3D""><br =
class=3D"Apple-interchange-newline">--</span><br style=3D"color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D""><span style=3D"color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 14px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">Please do not email me anything that you are not =
comfortable also sharing</span><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">&nbsp;with the NSA.</span>
</div>

<br class=3D""></body></html>=

--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--