open timestamps #51

New issue

Open

opened 2025-03-16 12:31:35 +13:00 by mikedilger · 4 comments

mikedilger commented

2025-03-16 12:31:35 +13:00

(Migrated from github.com)

Many theoretical attacks in proposed nostr improvements are based upon the fact that the created_at timestamp is free and can be a lie. Each network node knows when an event arrived, however, and can use that arrival time instead.

But it might be far better to build open timestamps into the protocol from the get go. Open timestamps are scalable and distributed.

Many theoretical attacks in proposed nostr improvements are based upon the fact that the `created_at` timestamp is free and can be a lie. Each network node knows when an event arrived, however, and can use that arrival time instead. But it might be far better to build open timestamps into the protocol from the get go. Open timestamps are scalable and distributed.

mikedilger commented

2025-03-16 12:36:28 +13:00

(Migrated from github.com)

https://petertodd.org/2016/opentimestamps-announcement
https://opentimestamps.org/

https://petertodd.org/2016/opentimestamps-announcement https://opentimestamps.org/

mikedilger commented

2025-03-16 12:44:17 +13:00

(Migrated from github.com)

Problem is these can be large and of varying size, for example from 175 bytes to 3812 bytes. And you need to connect to a bitcoin node.

petertodd commented

2025-03-19 07:57:29 +13:00

(Migrated from github.com)

Problem is these can be large and of varying size, for example from 175 bytes to 3812 bytes. And you need to connect to a bitcoin node.

Actually you don't need a full Bitcoin node. You can validate timestamps with just the block headers; OpenTimestamps proofs go all the way to the block header. For most timestamp validation tasks it's perfectly reasonable to accept any timestamp leading to a block with a decent amount of PoW.

> Problem is these can be large and of varying size, for example from 175 bytes to 3812 bytes. And you need to connect to a bitcoin node. Actually you don't need a full Bitcoin node. You can validate timestamps with just the block headers; OpenTimestamps proofs go all the way to the block header. For most timestamp validation tasks it's perfectly reasonable to accept any timestamp leading to a block with a decent amount of PoW.

mikedilger commented

2025-03-19 11:54:19 +13:00

(Migrated from github.com)

Oh ok, that is much less data.

👍 1