đ
Original date posted:2013-05-08
đ Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 9, 2013 at 1:57 AM, Peter Todd <pete at petertodd.org> wrote:
> Remember that interpreting the timestamp on a block for the purposes of
> timestamping is a lot more subtle than it appears at first.
I actually just meant how Pieter Wuille was talking about a blocktime accurate
to only within 18 hours. :) But it is a nice writeup!
In any case, for many things simple relative ordering is enough rather than
absolute time.
> There are two types of timestamps possible: proofs that data existed
> before a time, and proofs that data existed after. With the former type
> the *later* the proof says the data existed, the more conservative the
> assumptions behind the proof. So simply adding two hours to the block's
> timestamp is relatively reasonable. (this assumes the attack managed to
> mine a single block, and all nodes have accurate clocks)
Nope. The attacker can make the timestamp on the block they mine as little as
the minimum from GetMedianTimePast(), and adding two hours to that number could
easily be well before true time.
What you probably need to do is some sort of median time calculation for the
blocks around your timestamp. The proof becomes probabalistic based on the % of
hashing power the attacker controls and in turn depends on if the time they
created their timestamp was of their own choosing.
IE, if you just want to create an inaccurate timestamp, but don't care when,
you can just mine blocks and wait until you get lucky. If you need to create an
inaccurate timestamp *now* the problem is much harder.
But all this analysis can be developed later, and data timestamped now. :)
> Back to the block header time... Frankly, the easiest thing to do is
> just have a flag day where blocks after a certain height are considered
> to have a different epoch from the standard 1970 one when computing
> their time. Boring, but it works fine and only needs to be updated every
> few decades.
Oh, right, yes, that is a much more simple idea and far less prone to bugs.
Many SPV clients wouldn't even need upgrades if they don't acturally validate
the blocks they receive and just look for the biggest PoW.
>
> You're midstate idea is very clever though and could come in handy in
> the future for different purposes. Eventually we should discuss this
> with the ASIC manufacturers - if it can be implemented as a firmware or
> FPGA upgrade in the field all the better.
Yes
Anyway, you are being distracted from what we were talking about before, get
back to work!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRiwrGAAoJEEWCsU4mNhiPvYAH/3kjlg5diWeyYUJlKPKRpygQ
XAU8a2D3h9bABacmmhx5yW3AmtV0QqLgKlB76t41JB4O6Jer5FT8tBBwPnjDijtI
KrBWwPqNhVZiyTSDZQTF6BR1a0DDCZVtOXlpOTj6NL1+hy7NYTYsqxAVzS8QgZUH
RXt7QTYGrrmMbmm75NdWhK59mbv22UEaDHfDW0qqgSzdb7f1EQv1fou3MfKScQSd
7OsGU3k5PM+KQ/FGBy+r+07GY5yj85YMooGky0MCjtkOiU/qr+pxfs1uT2R8/512
TyZxzn1vtgWUEGOUeMCml+bgjUOvOgcIvAarzZmyLyAAY15S/LT8MvAr2RUjAfY=
=UDyE
-----END PGP SIGNATURE-----
John Dillon [ARCHIVE] /
npub15zâŚkn0zr
2023-06-07 15:01:33
in reply to nevent1qâŚ7rnx
Author Public Key
npub15z6e9t07ugx267aj3s3c487pln852ydytzlgu0vkkqxfznyvx4jq4kn0zrPublished at
2023-06-07 15:01:33Event JSON
{
"id": "2fb9b5ec6a1349aa6905577257a2089a578f445e659fe41eb8d9718e8a0daff3",
"pubkey": "a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564",
"created_at": 1686150093,
"kind": 1,
"tags": [
[
"e",
"94096a540659922fb308765fd366df049294303f58802ee2f87aef70df5f594b",
"",
"root"
],
[
"e",
"3053eec6f76a84e927aeec9846b206bbbd9a3f54e15c5789e17bc85f3c176c0e",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "đ
Original date posted:2013-05-08\nđ Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn Thu, May 9, 2013 at 1:57 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e Remember that interpreting the timestamp on a block for the purposes of\n\u003e timestamping is a lot more subtle than it appears at first.\n\nI actually just meant how Pieter Wuille was talking about a blocktime accurate\nto only within 18 hours. :) But it is a nice writeup!\n\nIn any case, for many things simple relative ordering is enough rather than\nabsolute time.\n\n\u003e There are two types of timestamps possible: proofs that data existed\n\u003e before a time, and proofs that data existed after. With the former type\n\u003e the *later* the proof says the data existed, the more conservative the\n\u003e assumptions behind the proof. So simply adding two hours to the block's\n\u003e timestamp is relatively reasonable. (this assumes the attack managed to\n\u003e mine a single block, and all nodes have accurate clocks)\n\nNope. The attacker can make the timestamp on the block they mine as little as\nthe minimum from GetMedianTimePast(), and adding two hours to that number could\neasily be well before true time.\n\nWhat you probably need to do is some sort of median time calculation for the\nblocks around your timestamp. The proof becomes probabalistic based on the % of\nhashing power the attacker controls and in turn depends on if the time they\ncreated their timestamp was of their own choosing.\n\nIE, if you just want to create an inaccurate timestamp, but don't care when,\nyou can just mine blocks and wait until you get lucky. If you need to create an\ninaccurate timestamp *now* the problem is much harder.\n\nBut all this analysis can be developed later, and data timestamped now. :)\n\n\u003e Back to the block header time... Frankly, the easiest thing to do is\n\u003e just have a flag day where blocks after a certain height are considered\n\u003e to have a different epoch from the standard 1970 one when computing\n\u003e their time. Boring, but it works fine and only needs to be updated every\n\u003e few decades.\n\nOh, right, yes, that is a much more simple idea and far less prone to bugs.\n\nMany SPV clients wouldn't even need upgrades if they don't acturally validate\nthe blocks they receive and just look for the biggest PoW.\n\n\u003e\n\u003e You're midstate idea is very clever though and could come in handy in\n\u003e the future for different purposes. Eventually we should discuss this\n\u003e with the ASIC manufacturers - if it can be implemented as a firmware or\n\u003e FPGA upgrade in the field all the better.\n\nYes\n\n\nAnyway, you are being distracted from what we were talking about before, get\nback to work!\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQEcBAEBCAAGBQJRiwrGAAoJEEWCsU4mNhiPvYAH/3kjlg5diWeyYUJlKPKRpygQ\nXAU8a2D3h9bABacmmhx5yW3AmtV0QqLgKlB76t41JB4O6Jer5FT8tBBwPnjDijtI\nKrBWwPqNhVZiyTSDZQTF6BR1a0DDCZVtOXlpOTj6NL1+hy7NYTYsqxAVzS8QgZUH\nRXt7QTYGrrmMbmm75NdWhK59mbv22UEaDHfDW0qqgSzdb7f1EQv1fou3MfKScQSd\n7OsGU3k5PM+KQ/FGBy+r+07GY5yj85YMooGky0MCjtkOiU/qr+pxfs1uT2R8/512\nTyZxzn1vtgWUEGOUeMCml+bgjUOvOgcIvAarzZmyLyAAY15S/LT8MvAr2RUjAfY=\n=UDyE\n-----END PGP SIGNATURE-----",
"sig": "1fd410e364ae0f726458e48ea323eca52e8d22319113edae9e59bf0611cc4217758b3f9cfc45745f4701944d20538c21b0f2bd5bf1e87aab8a3ffb3f8b019181"
}