Yes, you may be thinking of OpenTimestamps. And Inkan does i...

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
hex
753e301dd33313eeacec4747bae0f46d4f1d3f59076fa9413ad27b7d76c92b92nevent
nevent1qqs8203srhfnxylw4nkyw3a6ur6x6nca8avswmafgyady7mawmyjhysprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcu8ssmwKind-1 (TextNote)
↳ 回复 事件不存在
273ae59e0ee852af072c3dc57c1d0616408b194e95e3c512eece345f64b6fc6a...
Yes, you may be thinking of OpenTimestamps. And Inkan does in fact use OpenTimestamps to timestamp individual Nostr events on Bitcoin. Inkan only works when there is proof that a signed version of an event existed as of some particular time, and this proof is provided through BTC timestamping using OpenTimestamps.
However, the declarations of "delegation of signing authority" and "revocation of signing authority" that I mentioned also need to be timestamped. Unlike in the case of regular Nostr events, this timestamping needs to be done in a manner that allows you to later retrieve the substantive content of the declaration by querying the blockchain. Bitcoin timestamping does not allow for this, at least not in any straightforward way, because what's actually recorded on Bitcoin is a hash that is the root of a Merkle tree. And you can't extract the content of the timestamped items from that hash. Ethereum, on the other hand, has easy mechanisms for recording these "delegations of signing authority" and "revocations of signing authority" in a manner that makes their content queriable / retrievable.
So in both cases, the ultimate purpose of using blockchains is to provide timestamps. The reason Ethereum is used for delegation and revocation declarations is that Ethereum provides straightforward methods for retrieving the content of these declarations from the chain.
原始 JSON
{
"kind": 1,
"id": "753e301dd33313eeacec4747bae0f46d4f1d3f59076fa9413ad27b7d76c92b92",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1774552220,
"tags": [
[
"e",
"dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277",
"wss://relay.primal.net",
"root",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"e",
"273ae59e0ee852af072c3dc57c1d0616408b194e95e3c512eece345f64b6fc6a",
"wss://theforest.nostr1.com/",
"reply",
"0689df5847a8d3376892da29622d7c0fdc1ef1958f4bc4471d90966aa1eca9f2"
],
[
"p",
"0689df5847a8d3376892da29622d7c0fdc1ef1958f4bc4471d90966aa1eca9f2"
]
],
"content": "Yes, you may be thinking of OpenTimestamps. And Inkan does in fact use OpenTimestamps to timestamp individual Nostr events on Bitcoin. Inkan only works when there is proof that a signed version of an event existed as of some particular time, and this proof is provided through BTC timestamping using OpenTimestamps.\n\nHowever, the declarations of \"delegation of signing authority\" and \"revocation of signing authority\" that I mentioned also need to be timestamped. Unlike in the case of regular Nostr events, this timestamping needs to be done in a manner that allows you to later retrieve the substantive content of the declaration by querying the blockchain. Bitcoin timestamping does not allow for this, at least not in any straightforward way, because what's actually recorded on Bitcoin is a *hash* that is the root of a Merkle tree. And you can't extract the content of the timestamped items from that hash. Ethereum, on the other hand, has easy mechanisms for recording these \"delegations of signing authority\" and \"revocations of signing authority\" in a manner that makes their content queriable / retrievable.\n\nSo in both cases, the ultimate purpose of using blockchains is to provide timestamps. The reason Ethereum is used for delegation and revocation declarations is that Ethereum provides straightforward methods for retrieving the content of these declarations from the chain.",
"sig": "d8d2f8eebadb71fc489fbb1e58f372140ef7853470d0bc2d561317b2cbce8640ee6c6708f008eaf7ded80780451924b270361cbbc086c183ca3d4692d1a5f1ac"
}