Some ECC signing systems can do grouping operations where you can compose all the keys and all the data being signed and validate the whole thing with negligible probability of accepting if any were invalid and zero possibility of rejecting if all were valid. But AFAIK ECDSA is not such a scheme, and the ones I know of have larger signatures. (uh, though if you were to use it to always merge all the signatures in a block— that might be interesting).
Maybe we are speaking of different things but doesn't ECDSA allow creating a composite key by simply adding the two private keys together. The signature (which would be the same size as the individual keys) can be verified by completing the same ECC arithmetic on the public keys. For example say a hypothetical transaction (not in Bitcoin network and not necessarily in the same format) has the following information in the transaction. At this point the format/structure isn't really important.
Transaction Body:
Version
NumInputs
ArrayOfInputs[]
NumOutputs
ArrayOfOutputs[]
Each Input is in the following format:
PrevTxHash
PrevTxIndex
PubKey
So far this is very similar to Bitcoin however there are no scripts in the tx inputs. Each input simply consists of the information necessary to identify and authenticate it (tx id, index, and public key). At this point lets ignore the format of the outputs as it isn't particularly important for this discussion. Now unlike Bitcoin where each input has a signature (the simplified tx is signed w/ private key corresponding to the pubkey listed for the input) could we instead have a single signature for the entire transaction. Also lets ignore coinbase/generation tx for the moment.
So for a transaction with more than one public key in the inputs we first create a composite key by performing ECC arithmetic. Lets call the composite key the tx key. We would take a list of the inputs, remove the duplicate private keys and create the tx key by adding the private keys together.
tx.privkey = privkey[0] + privkey[1] + ... privkey[2]
Then we sign the entire tx once with the tx key. The single tx signature would be appended to the tx.
Version
NumInputs
ArrayOfInputs[]
NumOutputs
ArrayOfOutputs[]
Signature
To validate we would take the list of inputs, remove duplicate pubkeys, and create a composite in the same manner as the privkeys.
tx.pubkey = pubkey[0] + pubkey[1] + ... pubkey[2]
The tx (composite) pubkey will validate the signature created by the tx (composite) privkey.
This method would be more limiting than the Bitcoin script system however it would (with a few other changes) result in an up to 50% savings in terms of bandwidth and storage requirements. The computing power requirements should be roughly the same. Given that over 99%+ of the transactions to date on the Bitcoin network are "standard" pay to pubkeyhash we are sizable savings. With the use of versioning other more advanced tx would still be possible so it would be possible for an alternative crypto-currency to have the best of both worlds. For "simple" transactions a significant reduction in resource requirements while still having the ability to create more complex transactions.
Is there any security risk to a format like this? Any reduction in key strength? I can't seem to find anything that would indicate it is the case but this really isn't my area of expertise.... its certainly possible to— in a single transaction— expose a bunch of public keys, compose them, and sign with the composition. But the space reduction is reduced by the need to expose the public keys... and it would make taint analysis more potent because you multiple parties cannot securely sign in that model. It's also incompatible with sighash single. If you wanted an incompatible ECC specific change— you could instead add public key recovery. This would get similar space savings, but also save on transactions with a single input while not breaking the ability to confuse taint analysis with joint transactions, or breaking alternative sighashes.
I assume by "compose" you mean ECC addition of the private keys (as well as a separate ECC addition of the pubkeys). Right? I agree there is a need for public key for each input to validate the signature however the signature is significantly larger. For Bitcoin the pubkey is 34 bytes for compressed pubkey (66 bytes for uncompressed pubkeys). An alternative CC could simply mandate the use of compressed public keys in the protocol. The signature is 72 bytes.
Bitcoin Tx Input Format
TxOutHash - 32 bytes
TxOutIndex - 4 bytes
ScriptLength - variable (1-9 bytes, 1 most common)
Signature - 72 bytes (including encoding)PubKey - 34 bytes (compressed keys)
Sequence - 4 bytes
Total: 147 bytes (Signature is 48% of Input size)
and it would make taint analysis more potent because you multiple parties cannot securely sign in that model. It's also incompatible with sighash single.
Agreed.
If you wanted an incompatible ECC specific change— you could instead add public key recovery. This would get similar space savings, but also save on transactions with a single input ...
Interesting. Can you provide information or reference on public key recovery?
One thing that I do sometimes wish is that transactions were themselves hash trees internally. It would be very nice to be able to give to someone all the data they need to build a current UTXO securely (and thus also verify that there is no permitted inflation in the chain) without sending them a bunch of deeply burred signature data which isn't personally interesting to them and which they believe has adequate hashpower security to only do randomized spot checks.
I read this a couple of times and still couldn't conceptualize how hash tree in transaction would add security. I bookmarked it though.
Show Posts
