what's a compressed key

[bitpop]

I thought they're smaller but they look the same or longer on bitaddress 

[BurtW]

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

[bitpop]

What's the point? I guess I didn't notice because it didn't show those.

Btw why no vanity?

[BurtW]

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.

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://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908

And the entire thread where the post come from.  I also wrote this summary of my position a while back:

https://bitcointalk.org/index.php?topic=342773.msg3671886#msg3671886

(also in a pretty good thread).

Finally, gmaxwell's thread in response to the fungibility crisis:

https://bitcointalk.org/index.php?topic=279249.0

[Dabs]

You can make compressed vanity keys. It's actually a little bit faster.

[BurtW]

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.

[bitpop]

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.

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://bitcointalk.org/index.php?topic=334316.msg3588908#msg3588908

And the entire thread where the post come from.  I also wrote this summary of my position a while back:

https://bitcointalk.org/index.php?topic=342773.msg3671886#msg3671886

(also in a pretty good thread).

Finally, gmaxwell's thread in response to the fungibility crisis:

https://bitcointalk.org/index.php?topic=279249.0

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?

[Dabs]

@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]

Oh so a big miner can block you? And even block tainted coins?

[Dabs]

Ive never seen it happen. But the possibility is there.