Post
Topic
Board Bitcoin Discussion
Re: John Nash created bitcoin
by
dinofelis
on 13/04/2017, 13:28:52 UTC
Why hashing a public key could have been brilliant, and how bitcoin's design totally missed it.
=========================================================

I outlined before that hashing the public key as a bitcoin address was a faux good idea, but now I realize that it could have been a good idea.

The reasons I stated that it was a faux good idea were:
1) if you need the hash to protect a broken crypto system (elliptic curve crypto), you are making a fundamental mistake.  In as much as hashes can protect better against quantum computers and elliptic crypto is essentially TOTALLY DEAD, you can't use your private key any more because one can change your transaction on the fly if one has a quantum computer.  So instead of "protecting a broken system", one should have used one that isn't broken ; and in as much as one thinks that elliptic curve crypto isn't broken, there's no need to protect it.

2) I indicated that introducing the hash was wasting room on the chain, because if you hash the public key in the output (the address), you have to provide the key in spending input (as is the case today) ; while if you provided directly the public key in the output, you didn't need to copy it again in the spending input.

--> now it turns out that this argument is wrong.  So YES, introducing the hashed key IS winning room on the block chain.  However, this feature IS NOT USED.
 
In ECDS, with a key of N bits (and a security of N/2 bits classically), the signature contains 2N bits.  Essentially, the first N bits are related to a chosen random number, and the second N bits are the actual signature.  However, it is possible to derive the public key (actually a small set of public keys) most of the time from the signed message and the signature.

As such, the publication of the public key is not necessary !

The verifier can derive it (up to a few candidates) from the signature and the message.  In fact, for the curve that Satoshi chose, with cofactor 1, there are only two candidate public keys.

It is explained here.
https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work

In this very case, there is no need, EVER, to publish the public key on the block chain: the signature gives you two candidates, and if one of them hashes to the public key hash, that's a proof that the signature came from that address owner.
And then you WIN by hashing the public key, because the hash can be half as short as the public key (given that the hash security is the length of the hash output - we are after pre-image security ; and the public key security is half of the key length classically).

So, yes, it is a good idea to hash the public key after all, if you don't publish the public key in the spending input !  But in bitcoin, one does, so one has totally wasted this advantage.  Moreover, there's no point in making the hash bigger than 128 bits.

--> this indicates that the bitcoin designer wasn't aware of this economy of bits and hence, cannot have designed the crypto for that reason, given that he didn't use its potential.

So, the most economical design in bitcoin would:

1) have used a 128 bit hash of the public key in the output (instead of 160 bits), saving 32 bits
2) have imposed a single address usage in the protocol (eliminating the need for transaction references, saving  288 bits)
3) having used only the signature in the spending input, not the public key (saving 256 bits)

A transaction would hence have saved 576 bits, or 72 bytes, would have had consistent 128 bit security level, wouldn't have had the hassle of transaction hashes and malleability, and would not have exposed same address UTXO to different levels of security (once the first signature is out, the 160 bit long term hash security drops in any case to 128 bit key security).

Now, a full transaction in bitcoin (one output and one corresponding input) consist of the order of 24 + 8 = 32 bytes (output) and 32 + 4 + 36 + 36 + 4 =  112 bytes (input), so in total 144 bytes.

If we can save 72 bytes, we can reduce the volume of the block chain BY HALF, if we were using crypto correctly and consistently in the idea of optimizing consistent security (128 bit level) and maximum economy of room.

In fact, the original design even published the (x,y) coordinates in full of the public key, doubling the room used, but that was a total waste: you can recover y from x (and a single extra bit).  This is done now.