📅 Original date posted:2018-01-29
📝 Original message:On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> *2.* Timestamps are not necessary to avoid double-spending. A simple
> ordering of blocks is sufficient, so exchanging timestamps with enumeration
> would work double-spending wise. Permissioned consensus protocols, such as
> hyperledger, indeed have no timestamps (in version 1.0).
>
The timestamps simply needs to be reasonably accurate. Their main purpose
is to allow difficulty updates.
They can also be used to check that the node has caught up.
> It uses a simple average of block time in the last 2016 blocks. But such
> averages ignore any values besides the first and last one in the interval.
> Hence, if the difficulty is constant, the following sequence is valid from
> both the protocol and the miners incentives point of views:
>
> 1, 2, 3,…., 2015, 1209600 (time of two weeks), 2017, 2018, 2019,….,
> 4031, 1209600*2, 4033, 4044, …
>
Much of Bitcoin operates on the assumption that a majority of miners are
honest. If 50%+ of miners set their timestamp reasonably accurately (say
within 10 mins), then the actual timestamp will move forward at the same
rate as real time.
Dishonest miners could set their timestamp as low as possible, but the
median would move foward if more than half of the timestamps move forward.
> If we want to be pedantic, the best lower bound for a block timestamp is
> the timestamp of the block that closes the adjustment interval in which it
> resides.
>
If you are assuming that the miners are majority dishonest, then they can
set the limit to anything as long as they don't move it more than 2 hours
into the future.
The miners could set their timestamps so that they increase 1 week fake
time every 2 weeks real time and reject any blocks more than 2 hours ahead
of their fake time. The difficulty would settle so that one block occurs
every 20 mins.
>
> Possible improvement:
> -----------------------------
> We may consider exchanging average with standard deviation in the
> difficulty adjustment formula. It both better mirrors changes in the hash
> power along the interval, and disables the option to manipulate timestamps
> without affecting the difficulty.
>
> I'm aware that this change requires a hardfork, and won't happen any time
> soon. But does it make sense to add it to a potential future hard fork?
>
For check locktime, the median of the last 11 blocks is used as an improved
indicator of what the actual real time is. Again, it assumes that a
majority of the miners are honest.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180129/0d61ce0b/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 18:10:24
in reply to nevent1q…q28l
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 18:10:24Event JSON
{
"id": "cdeffe9646ce3d7200304a3aa1f04e773fb2c7aa39dbad35cc76f8e0eb7e8e5b",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686161424,
"kind": 1,
"tags": [
[
"e",
"88c58d5589d7722de84cdc11e2eba2693b3168f189e3827879c0e97e565301e9",
"",
"root"
],
[
"e",
"a2cd3583ce97d6b9654992c2d700e9f39bbb5283cf2664c04c644165efcc8757",
"",
"reply"
],
[
"p",
"b7863e8861937daee021c7681ab393394b1921b5ff9a7aa179cddb3749d3457a"
]
],
"content": "📅 Original date posted:2018-01-29\n📝 Original message:On Mon, Jan 29, 2018 at 1:34 PM, Neiman via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e *2.* Timestamps are not necessary to avoid double-spending. A simple\n\u003e ordering of blocks is sufficient, so exchanging timestamps with enumeration\n\u003e would work double-spending wise. Permissioned consensus protocols, such as\n\u003e hyperledger, indeed have no timestamps (in version 1.0).\n\u003e\n\nThe timestamps simply needs to be reasonably accurate. Their main purpose\nis to allow difficulty updates.\n\nThey can also be used to check that the node has caught up.\n\n\n\u003e It uses a simple average of block time in the last 2016 blocks. But such\n\u003e averages ignore any values besides the first and last one in the interval.\n\u003e Hence, if the difficulty is constant, the following sequence is valid from\n\u003e both the protocol and the miners incentives point of views:\n\u003e\n\u003e 1, 2, 3,…., 2015, 1209600 (time of two weeks), 2017, 2018, 2019,….,\n\u003e 4031, 1209600*2, 4033, 4044, …\n\u003e\n\nMuch of Bitcoin operates on the assumption that a majority of miners are\nhonest. If 50%+ of miners set their timestamp reasonably accurately (say\nwithin 10 mins), then the actual timestamp will move forward at the same\nrate as real time.\n\nDishonest miners could set their timestamp as low as possible, but the\nmedian would move foward if more than half of the timestamps move forward.\n\n\n\u003e If we want to be pedantic, the best lower bound for a block timestamp is\n\u003e the timestamp of the block that closes the adjustment interval in which it\n\u003e resides.\n\u003e\n\nIf you are assuming that the miners are majority dishonest, then they can\nset the limit to anything as long as they don't move it more than 2 hours\ninto the future.\n\nThe miners could set their timestamps so that they increase 1 week fake\ntime every 2 weeks real time and reject any blocks more than 2 hours ahead\nof their fake time. The difficulty would settle so that one block occurs\nevery 20 mins.\n\n\n\u003e\n\u003e Possible improvement:\n\u003e -----------------------------\n\u003e We may consider exchanging average with standard deviation in the\n\u003e difficulty adjustment formula. It both better mirrors changes in the hash\n\u003e power along the interval, and disables the option to manipulate timestamps\n\u003e without affecting the difficulty.\n\u003e\n\u003e I'm aware that this change requires a hardfork, and won't happen any time\n\u003e soon. But does it make sense to add it to a potential future hard fork?\n\u003e\n\nFor check locktime, the median of the last 11 blocks is used as an improved\nindicator of what the actual real time is. Again, it assumes that a\nmajority of the miners are honest.\n\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180129/0d61ce0b/attachment.html\u003e",
"sig": "82d900fe87408db0d10814ac87370ee2730d1f51b49fb891100c00960d440c6864d64f3e4e3e88f6e15b3c37cbaa56985acb34144a6dfe2a27a91db0dbb66775"
}