Statistical analysis of Bitcoin public key distribution

[hhanh00]

Some other queries:
Top 10 richest addresses:

Code:

select address, balance / 1e8 from balances order by balance desc limit 1,10;
1i7cZdoE9NcHSdAL5eGjmTJbBVqeQDwgw	144341.53393243
13Df4x5nQo7boLWHxQCbJzobN5gUNT65Hh	134033.21518705
1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF	79957.05831838
1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx	69471.09995224
16ZbpCEyVVdqu8VycWR8thUL2Rd9JnjzHt	61693.55853673
1PB4xXUFyy4kSNqroCBVaQuCuw9VcN3be4	61544.25018469
1PnMfRF2enSZnR6JSexxBHuQnxG8Vo5FVK	61534.65308581
18f1yugoAJuXcHAbsuRVLQC9TezJ6iVRLp	61517.02586555
1DiHDQMPFu4p84rkLn6Majj2LCZZZRQUaa	61442.99572266
1AhTjUMztCihiTyA4K6E3QEpobjWLwKhkR	61387.07600804

Code:

select count(*) from balances;
3460367

The median is only 1 mbtc

Code:

select address, balance / 1e8 from balances order by balance asc limit 1730183,1;
1H6c1fDEzJBhvViHhtrW5L9YTuSfRNp44w	0.001

Total balance

Code:

select sum(balance) / 1e8 from balances;
13316310.28675084

The top 18 (0.0005 %) addresses own 10% of the total

Code:

select sum(balance) / 1e8 from (select balance from balances  order by balance desc limit 18) as T;
1345428.14052543

The top 3000 (0.09%) own more than half

Code:

select sum(balance) / 1e8 from (select balance from balances  order by balance desc limit 3000) as T;
6820871.23187743

[1715217159]

1715217159

[1715217159]

1715217159

[1715217159]

1715217159

[Reynaldo]

I dont know which algorithm it is using,

Clearly.  Please explain how random guessing and tossing out words that you think might be associated with cryptography would be helpful at all?

if its gpg,

It's not.  The public key is ECDSA using the secp256k1 curve. The bitcoin address is a RIPEMD-160 hash of a SHA-256 hash.

should be totally random and nothing could be found if its not then the flaw might be from GPG and about the entropy that each system used to generate the key.

The entropy is in the choosing of the private key.  The questions being asked, as I understand them, are if a statistical analysis has been attempted to determine if there are any flaws in any of ECDSA, SHA-256, or RIPEMD-160 that might lead to discovery that either public keys or bitcoin addresses are less random than believed.

In theory you could generate an address that is already done but then the private key would not be the same, therefor you wouldnt be able to spend the funds.. correct me if im wrong.

You are wrong.  If you have a private key that generates a particular bitcoin address then you can spend all bitcoins that are received at that address, even if that private key isn't the same private key that was used by the intended recipient to originally generate the address.

(Note: The only way that you "could generate an address that is already done" with a different private key is if there is a flaw in ECDSA, SHA-256, or RIPEMD-160.  There are currently no known flaws that would cause this, and with nearly 6 years of use bitcoin has not ever had a recorded instance of this happening.)

Thanks alot, this clears alot of things to me

[Phrenico]

You are wrong.  If you have a private key that generates a particular bitcoin address then you can spend all bitcoins that are received at that address, even if that private key isn't the same private key that was used by the intended recipient to originally generate the address.

(Note: The only way that you "could generate an address that is already done" with a different private key is if there is a flaw in ECDSA, SHA-256, or RIPEMD-160.  There are currently no known flaws that would cause this, and with nearly 6 years of use bitcoin has not ever had a recorded instance of this happening.)

Correct my misunderstanding then:

Private keys are intended to be one-to-one with public keys, so that would certainly be a flaw in ECDSA if two private keys correspond to one public key, but since you turn the 256 bit public key into a 160 bit digest, it would just be incredibly unlikely, not impossible, for an ideal hash function to map two different inputs 256 bit to a single 160 bit output.

What's wrong with my understanding?

[hhanh00]

1. The hash function maps billions of 256 bits input to the same value.  It's just that it's not computably easy to find a collision.
2. Bitcoin verifies that you can spend from an output by checking that the public key that you provide has the same hash the address and that you have the private key.
In other words, when the money was sent out, only the hash was given. To claim the money, you show the public key.

[DannyHamilton]

Correct my misunderstanding then:

Private keys are intended to be one-to-one with public keys, so that would certainly be a flaw in ECDSA if two private keys correspond to one public key, but since you turn the 256 bit public key into a 160 bit digest, it would just be incredibly unlikely, not impossible, for an ideal hash function to map two different inputs 256 bit to a single 160 bit output.

What's wrong with my understanding?

There is nothing wrong with your understanding.

When I say:
the only way you "could" do something

I mean it in the same way as when I say:
"The only way all the air molecules in the room could spontaneously collect in one corner instantly suffocating everyone in the room is if there is a flaw in our current understanding of physics."

Sure, there is an "incredibly unlikely, not impossible" probability of it happening, but in terms that the typical human being understands it can't happen.

Meanwhile when you say "not impossible", you are simply using a non-zero probability number (regardless of how extremely small that number is) as an indication of "possibility".

[amaclin]

Private keys are intended to be one-to-one with public keys, so that would certainly be a flaw in ECDSA if two private keys correspond to one public key

It will be flaw in basic arithmetic, not in ECDSA.
X * 7 = 28
How many values of X do you know? Two? Give me both, please!

but since you turn the 256 bit public key into a 160 bit digest, it would just be incredibly unlikely, not impossible, for an ideal hash function to map two different inputs 256 bit to a single 160 bit output.

What's wrong with my understanding?

That is correct. There is 2⁹⁶ addresses for each private key. No problem.

UPD: sorry, this sentence has mistake. see replies below.

[hhanh00]

Private keys are intended to be one-to-one with public keys, so that would certainly be a flaw in ECDSA if two private keys correspond to one public key

It will be flaw in basic arithmetic, not in ECDSA.
X * 7 = 28
How many values of X do you know? Two? Give me both, please!

Elliptic curve mathematics is much more complicated than this. Besides, there are technically multiple values because the EC forms a cyclic group but we choose the normalized value. anyway Why the sarcastic comment?

[BurtW]

Private keys are intended to be one-to-one with public keys, so that would certainly be a flaw in ECDSA if two private keys correspond to one public key

It will be flaw in basic arithmetic, not in ECDSA.
X * 7 = 28
How many values of X do you know? Two? Give me both, please!

but since you turn the 256 bit public key into a 160 bit digest, it would just be incredibly unlikely, not impossible, for an ideal hash function to map two different inputs 256 bit to a single 160 bit output.

What's wrong with my understanding?

That is correct. There is 2⁹⁶ addresses for each private key. No problem.

No.  On average there approximately 2⁹⁶ key pairs mapped to each Bitcoin address.

Your statement has it backwards.

To spend the BTC at a Bitcoin address you need to have one of the approximately 2⁹⁶ possible key pairs that will properly map to that Bitcoin address.

[amaclin]

No.  On average there approximately 2⁹⁶ key pairs mapped to each Bitcoin address.
Your statement has it backwards.

Thank you. I am very sorry. Thinking in English is quite hard for me. Thanks for correcting my mistake