just had a remembering about how #bitcoin compactly combines the signature with the pubkey in transactions

i forget what the procedure was exactly, but it can also be done to schnorr signatures also

essentially, the normal route you have to combine the signature and pubkey to get either zero or one, true or false

the method used by bitcoin transactions (ecdsa ones, up to segwit) instead you get the pubkey when you combine the hash and the signature

someone was talking about how it's silly that nostr events have the IDs in them, well, you can even go further and bundle the pubkey into the signature, though that also means you have to omit the pubkey from the canonical form

i'm thinking, if i'm gonna make a binary form of the protocol, that i should use both features, and sign on the binary canonical form, which would require an alteration in the NIPs to designate the canonical hash derivation type

it's certainly not going to be friendly to application runtimes like the web browser, even with wasm, but that shit needs to die long ago, such a waste of resources

if you are an environmentalist and you aren't campaigning against web browsers you are a hypocrite, such a total waste

Reply to this note

Please Login to reply.

Discussion

also, i should just point out that this compact format incurs more processing cost... in a database, for example, you still have to have all the truncated pubkey in the indexes still, but in the database you don't need to verify it, it is only on the submission process that this all has to be derived

plus, having the pubkey in the part that generates the hash acts as a namespace that reduces the chances of a two messages from different keys ever colliding, so, probably there is no logic to switching to this type of compact signature

if it was to be done, probably you'd need to anyway add a 8 byte (64 bit) pubkey prefix which would serve as an adequate namespacer and work to quickly check the signature pubkey derivation is consistent... 8 bytes is still a lot of hash grinding to discover a collision and the only purpose of it is to reduce the chances of an in-protocol collision between two messages in any reasonable timespan

that would work, i think, i'll keep thinking about this of course, i'm a bit weird like that