📅 Original date posted:2018-02-18
📝 Original message:Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 <https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13>;
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect at mastodon.social <mailto:taoeffect at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180218/89e66ce8/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180218/89e66ce8/attachment-0001.sig>;
Tao Effect [ARCHIVE] /
npub1r0…vdpg3
2023-06-07 18:10:55
in reply to nevent1q…ly2g
Author Public Key
npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3Published at
2023-06-07 18:10:55Event JSON
{
"id": "ad225889e8b7b4919450d4ade2b78d3b06b667ad29c8deba2ea4892b1457a9cf",
"pubkey": "1bd05a5503fb6854f03714081df3970b79306bc9f28bd4ec35add5b3317755d7",
"created_at": 1686161455,
"kind": 1,
"tags": [
[
"e",
"33426837e4385de326988d65d4b12c529d51e1b81c10e509c6e1e5a5e31e15ce",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-02-18\n📝 Original message:Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 \u003chttps://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13\u003e\n\n\n# Blockchain Timestamps Unnecessary In Proof-of-Work?\n\n*Author: Greg Slepak ([@taoeffect at mastodon.social \u003cmailto:taoeffect at mastodon.social\u003e](https://mastodon.social/@taoeffect \u003chttps://mastodon.social/@taoeffect\u003e))*\n\n----\n\nThe Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm.\n\nI 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.\n\nThe alternative difficulty adjustment algorithm would work according to the following principles:\n\n- The incentive for miners is and always has been to maximize profit.\n- 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.\n- 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.\n- The chain selection rule remains \"chain with most proof of work\"\n- 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%`.\n\n### Observations\n\n- Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation\n- The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly\n- Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today)\n- 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.\n\nA 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.\n\n### Risks and Mitigations\n\nSuch a system may introduce risks that require further modification of the protocol to mitigate.\n\nThe 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.\n\nTwo equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish:\n\n1. 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.\n2. 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.\n\n\n--\nPlease do not email me anything that you are not comfortable also sharing with the NSA.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180218/89e66ce8/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180218/89e66ce8/attachment-0001.sig\u003e",
"sig": "d01b1df4adc41e046260ca104fe72e6436d455850c4c5e671028656fc3a7c3a2abd1a29f71b8acc2adadaa13744865f7ceb8cdaaed4a56d0bc044f2c99abcd78"
}