Thanks for your detailed reply.
The protocol for which I plan to use this does narrow down the list of possible public keys significantly. The way it would work is that a specially formatted transaction that we could call a “merchant registration message” is put into the blockchain that contains the public key of this merchant (as an OP_RETURN output (which can be used to include arbitrary data in a Bitcoin transaction)), and an amount of bitcoins that are destroyed (to prevent an excessive number of registrations). This establishes a merchant with a certain public key.
The other type of special transaction (that is put into the blockchain) is an “order message” (the protocol I’m trying to create is that of a decentralized marketplace), which includes a signature over the transaction itself (again in an OP_RETURN output), in order to establish who the merchant is for this order. This way, everyone can scan the blockchain and see how many open/pending orders exist for a certain identity (merchant).
So the number of possible public keys for the signature (in the “order message”) in question is limited to the public keys contained in the “registration messages”, and each client will decide for themselves what the adequate “burn amount” (amount of bitcoins destroyed in the registration message) is, in order to prevent a DoS attack through an excessive number of registrations.
But the whole point is sort of moot anyway, since Bitcoin transactions with an OP_RETURN output are only forwarded by the original Bitcoin client if they include no more than 40 bytes of data or less. But 64 bytes of data is certainly better than 64+32 bytes of data, in any case. The limit was previously 80 bytes – enough to include a signature but not a signature plus public key. So if the limit is ever raised back to 80 bytes, this protocol would only work if the public key can be derived from the signature.
Mind you, it’s certainly possible to split the signature in two, and include the second part in separate transaction, which references the first one, but the Bitcoin developers don’t like that – and I can understand why – so I would really prefer to keep it as clean as possible.
Thinking about this some more, using your concept of a “key-id”, it would be trivial to add a unique ID in each registration message. Then each merchant would have a public key and a unique ID associated with it. Then the order messages can just reference this ID, and clients know which public key to use when verifying a signature. Although this would introduce the problem of how to handle ID collisions.
Anyway, I’m just thinking out loud. Thanks for your answer :).
