John Dillon [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-08 📝 Original message:-----BEGIN PGP SIGNED ...
📅 Original date posted:2013-05-08
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:
>> Guffaw :) The year 2038 is so far in the future that it is not really
>> relevant, from that angle.
>
> "Meh". I think it's highly unlikely we'll break the block header format, as it
> pretty much means invalidating all mining hardware.
Doesn't most mining hardware at the ASCI level start with a SHA256 midstate
given that the nonce is at the end? Adding further information to the block
should be possible at the beginning of the block without major changes to the
mining hardware.
> There's also no need: 32 bits is plenty of precision. Hell, even 16 bits would
> do (assuming there's never more than a 65535s (about 18 hours) gap between two
> blocks). Just assume the "full" 64-bit time is the smallest one that makes
> sense, given its lower 32 bits.
I feel somewhat uncomfortable about the "after-the-fact" auditing possible in
this scenario. Besides the timestamping provided by the block headers appears
to be useful in some payment protocols, not to mention in general.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRivnmAAoJEEWCsU
4mNhiPUIYH/AlxK4DHvIdq0khNH0nfK65E
F1ZyYZTGLNHKqrJLCU2kc7zteGadQuccmFsYpmViIr14tzpU7xMImUHpj7fEHO3R
S/1zy59rx2+VYcevYdwMDTywanjeForRpli93Hz570GfwfG/D7VPejfLo6iq5dOt
EG5m3Z8F7wNzWBmfBYBHKLrNBJe6iw0qJ2nNiHXcELt6gaqG3C9wI9NAPtQWQKjB
57h7yTnFCRmjA3HDdCe2s0FVJgRP5cJqz3e62qZrY/BRmw/Vrx8ExuX1LJFqUx3k
5tg+BxXH4DJbNIojuq9lLl5lWxKOI1iSJJuCAixo/6s/manLFggJv7KtYgzhhjI=
=BxDb
-----END PGP SIGNATURE-----
Published at
2023-06-07 14:56:44Event JSON
{
"id": "995a56cfa3e0c95539db65667e1fd25164b124b75ef0989ae092b598cec46b60",
"pubkey": "a0b592adfee20cad7bb28c238a9fc1fccf4511a458be8e3d96b00c914c8c3564",
"created_at": 1686149804,
"kind": 1,
"tags": [
[
"e",
"59e8288cfac09e08109e0e4bdade3ca2c22f16fca22317c30b00a3ccaafc304b",
"",
"root"
],
[
"e",
"1f961d384142f6940c19d69d584ce5134285591884ff47ec1067f62e5b7b63c5",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2013-05-08\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nOn Thu, May 9, 2013 at 1:13 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote:\n\u003e\u003e Guffaw :) The year 2038 is so far in the future that it is not really\n\u003e\u003e relevant, from that angle.\n\u003e\n\u003e \"Meh\". I think it's highly unlikely we'll break the block header format, as it\n\u003e pretty much means invalidating all mining hardware.\n\nDoesn't most mining hardware at the ASCI level start with a SHA256 midstate\ngiven that the nonce is at the end? Adding further information to the block\nshould be possible at the beginning of the block without major changes to the\nmining hardware.\n\n\u003e There's also no need: 32 bits is plenty of precision. Hell, even 16 bits would\n\u003e do (assuming there's never more than a 65535s (about 18 hours) gap between two\n\u003e blocks). Just assume the \"full\" 64-bit time is the smallest one that makes\n\u003e sense, given its lower 32 bits.\n\nI feel somewhat uncomfortable about the \"after-the-fact\" auditing possible in\nthis scenario. Besides the timestamping provided by the block headers appears\nto be useful in some payment protocols, not to mention in general.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.11 (GNU/Linux)\n\niQEcBAEBCAAGBQJRivnmAAoJEEWCsU\n4mNhiPUIYH/AlxK4DHvIdq0khNH0nfK65E\nF1ZyYZTGLNHKqrJLCU2kc7zteGadQuccmFsYpmViIr14tzpU7xMImUHpj7fEHO3R\nS/1zy59rx2+VYcevYdwMDTywanjeForRpli93Hz570GfwfG/D7VPejfLo6iq5dOt\nEG5m3Z8F7wNzWBmfBYBHKLrNBJe6iw0qJ2nNiHXcELt6gaqG3C9wI9NAPtQWQKjB\n57h7yTnFCRmjA3HDdCe2s0FVJgRP5cJqz3e62qZrY/BRmw/Vrx8ExuX1LJFqUx3k\n5tg+BxXH4DJbNIojuq9lLl5lWxKOI1iSJJuCAixo/6s/manLFggJv7KtYgzhhjI=\n=BxDb\n-----END PGP SIGNATURE-----",
"sig": "18b00ffb9ee1c0c7d6fa32cd80c3af3909083f4d9f95b173e10931f92dc6b7b9cf8f658c67c557e267f71f72932693b028b62730397212d4aee99d8edea962f3"
}