Inkan allows users to record the following types of declarat...

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
hex
78921b55d948ec5e3075fc351696f1ff6ecb5328cafd58bfc429fa8e91c85408nevent
nevent1qqs83ysm2hv53mz7xp6lcdgkjmcl7mkt2v5v4l2chlzzn75wj8y9gzqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gchj9vdlKind-1 (TextNote)
↳ 回复 HaloKat (npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac)
What does this mean? How does ETH enable key rotation? Why?
Inkan allows users to record the following types of declarations on Ethereum:
(i) Declarations of delegation of signing authority, whereby a pubkey declares that it delegates signing authority to another pubkey;
(ii) Declarations of revocation of signing authority, whereby a pubkey declares that it revokes signing authority from another pubkey.
The reason a blockchain is needed for this is that these declarations must be given objectively verifiable placement in time.
In principle any old blockchain will do, but I couldn't think of a straightforward way to do it on Bitcoin. It's not enough to simply record a hash of the declaration. The actual content of the declaration needs to be easily retrievable from the chain, and it seemed easiest to implement this on Ethereum, at least for prototyping.
See below for some screenshots from Inkan. The fourth screenshot gives you an idea of what these declarations look like, and the second and third one give you some hints as to how Inkan uses them to attribute events signed by delegatee keys to delegator keys.
nostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqyghwumn8ghj7mn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qqsdhe5x8zgg5e4mvq0ksx66j2jpm87edqlmjues58mw0787dpa5yacsudv3r
原始 JSON
{
"kind": 1,
"id": "78921b55d948ec5e3075fc351696f1ff6ecb5328cafd58bfc429fa8e91c85408",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1776249901,
"tags": [
[
"q",
"dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277",
"wss://nostr.land/",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"e",
"e038c5a65139ed22574e33d336eeb128eb91376189e87eb14da15db44064eab7",
"wss://nostr.land/",
"root",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"e",
"f5c9dafd33e57277e53d2c64a3f61ec6ccb1de020151cfb379be30dd238ff00b",
"wss://relay.primal.net/",
"reply",
"1bc70a0148b3f316da33fe3c89f23e3e71ac4ff998027ec712b905cd24f6a411"
],
[
"p",
"1bc70a0148b3f316da33fe3c89f23e3e71ac4ff998027ec712b905cd24f6a411"
]
],
"content": "Inkan allows users to record the following types of declarations on Ethereum:\n\n(i) Declarations of delegation of signing authority, whereby a pubkey declares that it delegates signing authority to another pubkey;\n\n(ii) Declarations of revocation of signing authority, whereby a pubkey declares that it revokes signing authority from another pubkey.\n\nThe reason a blockchain is needed for this is that these declarations must be given objectively verifiable placement in time.\n\nIn principle any old blockchain will do, but I couldn't think of a straightforward way to do it on Bitcoin. It's not enough to simply record a hash of the declaration. The actual content of the declaration needs to be easily retrievable from the chain, and it seemed easiest to implement this on Ethereum, at least for prototyping.\n\nSee below for some screenshots from Inkan. The fourth screenshot gives you an idea of what these declarations look like, and the second and third one give you some hints as to how Inkan uses them to attribute events signed by delegatee keys to delegator keys.\n\n\nnostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqyghwumn8ghj7mn0wd68ytnvv9hxgtcppemhxue69uhkummn9ekx7mp0qqsdhe5x8zgg5e4mvq0ksx66j2jpm87edqlmjues58mw0787dpa5yacsudv3r",
"sig": "798500408bdaabf91d4c9fbe71d72f42b54784e87c3936b80b87f27e28c5ec687231248263d152ab16ac44a98043ac9bd566da282f8f6e1d3a962ac221a88cd6"
}