Is the ECDSA public key hashed as a extra level of protection?

[publickeyhash]

If I understand correctly the bitcoin adresses are
Base58(Version+RIPEMD160(SHA256(PublicKey))+FirstFourBytes(SHA256(SHA256(Version+RIPEMD160(SHA256(PublicKey))))))

Since Base58 is easily invertible (just encoding and not encrytion) we can ignore the inner outer brackets.

Now if ECDSA is considered trusted, why hide public key with a hash?

Consider the following use case: a web shop owner decides to use a fixed Bitcoin adress. The first time he receives bitcoins nobody can determine the public key, let alone its private keys. Suppose the shopkeeper spends some Bitcoins, now the public key must be known publicly to verify the transaction. Now if the shopkeeper keeps making money on the same Bitcoin adress, the extra "layer of protection" is gone so that an entity if existant can crack ECDSA keys, can steal the money from this point on.

I try to understand bitcoin better, but from nearly all perspectives, it is just already implemented, without the design considerations being public.

Perhaps it was done for extra layer of protection for those who decide to never reuse the same adress (call them paranoids or just cautious netizens)
But that is still me speculating, a lot of bitcoins design decisions stay a complete mistery.

In the end nobody knows if backdoors were planted in any algorithms, or vulnerabilities are about to show up.

Among all the bitcoin doom scenarios, perhaps the most effective one from goverment standpoint would be to make sure to produce the first convincing p2p money system, only to pull the plug, buying time before the majority of citizens will ever try to trust such a system again.
If this theory is correct, they would pull the plug as soon as it has been the major mode of payment. This could generate a lifelong distrust with a lot of citizens.

Assuming this theory is correct what we actually have is a race: the goverment/organisation that built bitcoin to undermine or delay the arrival of real cryptocurrencies by undermining the credibility in this category of money, they want the bitcoin community to grow quickly (convince people of cryptocurrency) right in time before they pull the plug (cold shower of hard-knock reality lesson to crypto currency users). The people who actually believe in cryptocurrencies, must try to identify the built-in kill switch(es?) and adapt the code. How much time is left before the organisation decides to pull the plug?

[1714217971]

1714217971

[1714217971]

1714217971

[1714217971]

1714217971

[grue]

did you create this account just to post this topic?

[Mike Hearn]

AFAIK it's for convenience of typing only. Satoshi envisioned direct-to-IP transactions being a lot more common than they actually are today (ie, they don't happen at all anymore). In those transactions there are no addresses and the public keys are used directly.

[theymos]

It's to make the public keys shorter. You could just truncate the key and say that any key with the same start is OK, but this is probably less secure than hashing the entire key.

[publickeyhash]

Ah that makes complete sense, i completely forgot about the ergonomic considerations of the adress...
But the public key would take about 64 bytes * 8bit/byte=512 bits compared to 8+160+32=200 bits, thats only 2.5 times bigger, I think few people actually type over an adress, the future will probably have bitcoin adress mime types...
It still seems a bit strange to care about a factor 2.5 in adress size when the main focus is security?

[ene]

Ah that makes complete sense, i completely forgot about the ergonomic considerations of the adress...
But the public key would take about 64 bytes * 8bit/byte=512 bits compared to 8+160+32=200 bits, thats only 2.5 times bigger, I think few people actually type over an adress, the future will probably have bitcoin adress mime types...
It still seems a bit strange to care about a factor 2.5 in adress size when the main focus is security?

It has basically no security implications and makes coding for bitcoins only a little bit more complicated. Seems like a win-win to me.

[gmaxwell]

If I understand correctly the bitcoin adresses are Base58(Version+RIPEMD160(SHA256(PublicKey))+FirstFourBytes(SHA256(SHA256(PublicKey))))

Since Base58 is easily invertible (just encoding and not encrytion) we can ignore the inner outer brackets.

Now if ECDSA is considered trusted, why hide public key with a hash?

As others have answered, it's a more secure way of making addresses shorter.

However— it does have a theoretical security benefit:  It makes bitcoin a little less brittle against weak but semi-practical attacks on ECDSA.

E.g. imagine if bitcoin used RSA-512 for signatures today.  RSA-512 is horribly week, many people (including myself) have cracked it on their own at home.  Even so,  if this weakness was known bitcoin users could change practices to only ever send once from an address (transferring all value to a new address) and so an attack would have to be performed in the narrow window between the transmission of the spending TXN and the mining of the block (or somewhat longer if also coupled with a high hash power attack).   This is _much_ harder, and while I can trivially crack RSA-512 at home or using EC2 I don't believe I could pull off that attack.

It's likely that when there is some practical attack on ECC it will creepy up slowly— initially taking a very long time and a lot of resources. When this happens concerned bitcoin users could move to more conservative practices (especially for large stores of wealth) while the long process of upgrading bitcoin happens.

[publickeyhash]

To the extent that there are basically no security implications (i.e. mapping larger public keys to smaller adresses), this reduction in combinatorial space is not dangerous. If it is not dangerous (and I probably agree) we could have simply used smaller keys (why then use secp256k1?). It does complicate matters for a potential attacker but it is certainly not advertisable as a security feature (suppose NSA can easily generate SHA256 collisions, then inspect the "public keys" for weak public keys, I dont think the signature check algorithms feature a check on how safe the key is).

In my original post I described how I feel that the original developer should have posted more design considerations, more documentation.

I can read a part of the code and concoct a reason why something is done a certain way. I can ask on the forums, but Satoshi (if it even is a single individual) is not around.

Simply coming up with an explanation does not mean it was the motivation.

At first I could only think up: an added layer of security, to only publish the public key once after which you never intend to use it again.
This made some but not enough sense to me (it is basically a cryptographic claim that it must be easier to crack secp256k1 public key, than it is to collide sha256/RIPEMD combo to generate compatible public keys, of which one might be much easier to crack)

Then I get a reply which makes a lot more sense: adresses become shorter for usability...

Then somebody elaborates my first interpretation and advertises it as a security feature...

This shows my prediction that I would like to see more DESIGN CONSIDERATIONS (think S-boxes) instead of having to resort to speculation.

The person/group that created bitcoin originally, could still elaborate their design considerations, perhaps write a book about it.

Now we have 2 reasons. Perhaps if we can find enough different explanations/speculations for why the public keys are hashed into adresses, Satoshi might feel the need to explain some of his decisions?

[gmaxwell]

suppose NSA can easily generate SHA256 collisions,

There is a lot less reason to suppose that the NSA, or anyone else, can currently generate collisions on RIPEMD160(SHA256()) then can shortcut ECDSA.

I mean— we already know how to compromise ECDSA in about 4 billion operations. It's "Just an engineering problem".

[ByteCoin]

RSA-512 is horribly week, many people (including myself) have cracked it on their own at home.

.... and while I can trivially crack RSA-512 at home ....

That's a very interesting claim considering that the a 512 bit factorization would come in at number 5 on the GNFS records page on
http://xyyxf.at.tut.by/records.html#gnfs

If you can really factor 512 bit numbers trivially, then the project would greatly benefit from your ability.
Please let me know the size and weight of an average matrix for the linear algebra step for your 512-bit factoring program.

I mean— we already know how to compromise ECDSA in about 4 billion operations. It's "Just an engineering problem".

Even using the British "billion" = million million, 4 billion operations is less than a 42 bit keyspace. Please outline the attack you have in mind.

ByteCoin

[publickeyhash]

I wrote "suppose".
I am only clarifying that [advertising the design choice to encode the hash of the public key is a safety feature] corresponds to [claiming it is harder to generate enough collisions to find a weak key with same bitcoin adress than it is to crack ECDSA of the public key (requiring to crack a specific public key)].

I do not actually believe these are planted backdoors, but it is our duty to consider all angles of attack, that is what security is about.

How do you make money these days if you find a fundamental security flaw in any crypto system? The prizes like RSA-Challenge numbers are symbolic and often discontinued. Even if you had the ability to generate a false transfer to your account in the fiat system, how long would it be before things get noticed. It seems like one would prefer to attack an anonymous banking system.

[gmaxwell]

RSA-512 is horribly week, many people (including myself) have cracked it on their own at home.

.... and while I can trivially crack RSA-512 at home ....

That's a very interesting claim considering that the a 512 bit factorization would come in at number 5 on the GNFS records page on
http://xyyxf.at.tut.by/records.html#gnfs

If you can really factor 512 bit numbers trivially, then the project would greatly benefit from your ability.
Please let me know the size and weight of an average matrix for the linear algebra step for your 512-bit factoring program.

I think may be misunderstanding what I meant by 'trivally'.  I can't do it in under a day, for example.  Using EC2 prior to spot pricing I cracked RSA-512 for about $160 for the sieveing step and then did the linear algebra at home. in the total of about ~40 hours.

It only takes about 4gb memory or so for the linear algebra. On some random _single core_ machine, e.g. not using the MPI block-wiedemann you can extract a candidate solution in an hour or two once you've done enough sieving.

I can do the whole process at home in about three days now— though I'm perhaps a bit more overpowered compared to most homes.

I'll gladly prove this to you in private (e.g. by signing a message using a key or two I previously compromised from the pgp well connected set), if you'll share confirmation of this with the forum.

The point being— RSA-512 is too weak for any non-ephemeral usage, and yet even if bitcoin was using it right now it wouldn't be completely fatal to the system, but sure as hell would be if the public keys were disclosed. E.g. The coin at 1PZjfkLZBT7Q3UFmyEWH8QtuzTMi3MUiBj would be mine by now if the system used RSA-512 and the public key were disclosed. But without they public key I'd still be stuck even though I can compromise RSA-512.

I mean— we already know how to compromise ECDSA in about 4 billion operations. It's "Just an engineering problem".

Even using the British "billion" = million million, 4 billion operations is less than a 42 bit keyspace. Please outline the attack you have in mind.

Modified Shor's algorithm on the EC discrete logarithm problem of n=256bits takes a system of around 1500 error free q-bits (god knows how many for a error correcting system) and something like 6e9 operations (http://cdsweb.cern.ch/record/602816/files/0301141.pdf). I was _abundantly clear_ than I am not claiming that there _currently exists_ an effective attack, and that the benefit was purely a theoretical reduction in brittleness. At the same time no one of any repute is arguing that large scale quantum systems are physically impossible, we just don't know how to build one yet.

Publickeyhash raises a point I hadn't considered: I'd thought of the collision attack as being both a full collision across the big composite hash _and_ a ecc compromise, I hadn't considered the possibility of colliding to a weak key.  Thats interesting. I'm cluessless about how common weak keys would be on the curve bitcoin uses.

[Mike Hearn]

In private discussions I had with Satoshi some time ago, he had this to say on key sizes:

I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues.  I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new.  I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security.  I didn't find anything to recommend a curve type so I just... picked one.  Hopefully there is enough key size to make up for any deficiency.

At the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA.  RSA's huge keys were out of the question.  Storage and bandwidth seemed tighter back then.  I felt the size was either only just becoming practical, or would be soon.  When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved.

As it turns out, ECDSA verification time may be the greater bottleneck.  (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second)  Client versions bypass the problem.

As things have evolved, the number of people who need to run full nodes is less than I originally imagined.  The network would be fine with a small number of nodes if processing load becomes heavy.