path: root/52/e17ed0d4b4c64c26cee41fa33a48b590addff4

Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 31EA11126
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <willtech@live.com.au>
To: Tao Effect <contact@taoeffect.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
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: <PSXP216MB0181312DCCA46A1F9A276D799DC80@PSXP216MB0181.KORP216.PROD.OUTLOOK.COM>
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 <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 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 <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Tao Effect via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.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://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<mailto: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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">&gt;<span>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</span>=
.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">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.<br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Tao Effect via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoun=
dation.org&gt;<br>
<b>Sent:</b> Monday, 19 February 2018 12:29:50 PM<br>
<b>To:</b> Bitcoin Protocol Discussion<br>
<b>Subject:</b> [bitcoin-dev] Some thoughts on removing timestamps in PoW</=
font>
<div>&nbsp;</div>
</div>
<div class=3D"" style=3D"word-wrap:break-word">
<div class=3D"">Copied from:&nbsp;<a href=3D"https://github.com/WebOfTrustI=
nfo/rebooting-the-web-of-trust-spring2018/pull/13" class=3D"">https://githu=
b.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/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@mastodo=
n.social" class=3D"">taoeffect@mastodon.social</a>](<a href=3D"https://mast=
odon.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 tha=
t 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 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.</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 maximi=
ze 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 &quot;epocs&quot; or &q=
uot;block reward halving&quot; is removed.</div>
<div class=3D"">- The chain selection rule remains &quot;chain with most pr=
oof of work&quot;</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 percent=
age (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 the=
y 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 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.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">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.</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 modi=
fication of the protocol to mitigate.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">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.</div>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">Two equally straightforward mitigations exist to address th=
is 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 coul=
d 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 &quot;suffic=
iently different&quot; 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 class=3D"" style=3D"color:rgb(0,0,0); font-family:Hel=
vetica; font-size:14px; font-style:normal; font-weight:normal; letter-spaci=
ng:normal; text-align:start; text-indent:0px; text-transform:none; white-sp=
ace:normal; word-spacing:0px; line-height:normal; orphans:2; widows:2"><br =
class=3D"x_Apple-interchange-newline">
--</span><br class=3D"" style=3D"color:rgb(0,0,0); font-family:Helvetica; f=
ont-size:14px; font-style:normal; font-weight:normal; letter-spacing:normal=
; text-align:start; text-indent:0px; text-transform:none; white-space:norma=
l; word-spacing:0px; line-height:normal; orphans:2; widows:2">
<span class=3D"" style=3D"color:rgb(0,0,0); font-family:Helvetica; font-siz=
e:14px; font-style:normal; font-weight:normal; letter-spacing:normal; text-=
align:start; text-indent:0px; text-transform:none; white-space:normal; word=
-spacing:0px; line-height:normal; orphans:2; widows:2">Please
 do not email me anything that you are not comfortable also sharing</span><=
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">&nbsp;with
 the NSA.</span> </div>
<br class=3D"">
</div>
</body>
</html>

--_000_PSXP216MB0181312DCCA46A1F9A276D799DC80PSXP216MB0181KORP_--