Topic: what's a compressed key (Read 552 times)
Ive never seen it happen. But the possibility is there.
Oh so a big miner can block you? And even block tainted coins?
@BurtW, I can't tell the diff, I don't have a GPU, only CPU. But in the vanitygen thread, they say compressed keys are generated faster.
@bitpop, I use vanity addresses for donations, for games, and as a sort of green address. The rest of my coins are hidden. Theoretically, those can be blacklisted, thus affecting fungibility. However, in my case, I actually get better exchange rates. My trades have a charity bonus.
@bitpop, I use vanity addresses for donations, for games, and as a sort of green address. The rest of my coins are hidden. Theoretically, those can be blacklisted, thus affecting fungibility. However, in my case, I actually get better exchange rates. My trades have a charity bonus.
What's the point? I guess I didn't notice because it didn't show those.
Btw why no vanity?
The point is that the public key takes up 1/2 the space when you use the compressed form. Same amount of information in half the number of bits.Btw why no vanity?
My stance on vanity addresses (against them) is a natural extension of my stance on address reuse (against it) which is a natural consequence of the fungibility stance in my signature (see below).
For information on the very real threats to unqualified fungibility faced by Bitcoin see this post:
https://bitcointalksearch.org/topic/m.3588908
And the entire thread where the post come from. I also wrote this summary of my position a while back:
https://bitcointalksearch.org/topic/m.3671886
(also in a pretty good thread).
Finally, gmaxwell's thread in response to the fungibility crisis:
https://bitcointalksearch.org/topic/coinjoin-bitcoin-privacy-for-the-real-world-279249
I understand the privacy and I only use it for certain cases and probably never even received on them.
But how does vanity effect fungibility?
You can make compressed vanity keys. It's actually a little bit faster.
Really? Is the hash of the 257 bit key really that much faster than the hash of the 512 bit key? It it even noticable? The second and third hashes will take exactly the same amount of time and the pub = priv * G operation will be exactly the same so we are really just talking about the computational difference in the first hash here.I can see that doing both would be a bit faster:
1) Generate the random private key
2) Calculate pub = priv * G
3a) Hash the uncompressed public key, check for the desired pattern
3b) Hash the compressed public key, check for the desired pattern
4) If no match go back to step 1)
So this way you get two attempts at the desired pattern per pub = priv * G operation.
You can make compressed vanity keys. It's actually a little bit faster.
What's the point? I guess I didn't notice because it didn't show those.
Btw why no vanity?
The point is that the public key takes up 1/2 the space when you use the compressed form. Same amount of information in half the number of bits.Btw why no vanity?
My stance on vanity addresses (against them) is a natural extension of my stance on address reuse (against it) which is a natural consequence of the fungibility stance in my signature (see below).
For information on the very real threats to unqualified fungibility faced by Bitcoin see this post:
https://bitcointalksearch.org/topic/m.3588908
And the entire thread where the post come from. I also wrote this summary of my position a while back:
https://bitcointalksearch.org/topic/m.3671886
(also in a pretty good thread).
Finally, gmaxwell's thread in response to the fungibility crisis:
https://bitcointalksearch.org/topic/coinjoin-bitcoin-privacy-for-the-real-world-279249
What's the point? I guess I didn't notice because it didn't show those.
Btw why no vanity?
Btw why no vanity?
The Bitcoin address is the same length because it is the hash of the public key. The compressed public key is what is smaller.
Standard Public key with both the X and Y coordinates: 512 bits + format overhead
Compressed Public key with the X coordinate and just the sign of the Y coordinate: 257 bits + format overhead
Bitcoin address: always 160 bits + checksum and format overhead
Standard Public key with both the X and Y coordinates: 512 bits + format overhead
Compressed Public key with the X coordinate and just the sign of the Y coordinate: 257 bits + format overhead
Bitcoin address: always 160 bits + checksum and format overhead
I thought they're smaller but they look the same or longer on bitaddress 
Jump to: