# Bitcoin Private Key Question

If Bitcoin can be forked, and the same address can exist on both blockchains, what stops the re-generation of a privatekey on one blockchain that would also work on the other?

For that matter, what stops someone from forking the technology, starting from the genesis block, and using a program to endlessly create addresses > Search those addresses on the Bitcoin blockchain > if the address on the Bitcoin blockchain contains funds > use the newly generated privatekey to access the funds on the bitcoin blockchain?

• Why would the private key need to be re-generated? With the fork, whoever owned the private key on the original blockchain will also own it on the new blockchain. As for your second question, what stops someone from doing that is entropy. There is so much entropy in the private addresses, that generating one that already has some coin on it would be really, really, really hard. So hard that we expect the universe to end before someone can do it (baring any implementation issues or breakthroughs in cryptanalysis). – mikeazo Nov 6 '17 at 19:52
• I guess what I'm not understanding is how the private key is generated in the first place. If someone forks Bitcoin's tech but starts from the genesis block, and generates a privatekey for an address that exist on the Bitcoin Blockchain, wouldn't that privatekey also work on the bitcoin blockchain? If a privatekey works for an address for Bitcoin and Bitcoin Cash/Gold/Segwit2x then if someone is generating addresses on their own fork of Bitcoin starting at the genesis block - wouldn't they eventually be able to generate a key for an address currently in-use on the Bitcoin blockchain? – AaronD Nov 6 '17 at 20:04
• A bitcoin address is just a hash of a public key. So, generating the private key for an address already used in the blockchain is computationally infeasible. – mikeazo Nov 6 '17 at 20:50

A Bitcoin address is computed as follows, according to the Bitcoin wiki:

1. A private key is a 256-bit integer $k$ below 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141, the order of the group $E(\mathbb F_p)$ of $\mathbb F_p$-rational points on the curve secp256k1, $E/\mathbb F_p: y^2 = x^3 + 7$ where $p$ is the prime $2^{256} - 2^{32} - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1$.

2. A public key is the standard encoding $\underline P$ of a point $P = [k]B$ on secp256k1, the scalar multiplication by $k$ of the standard base point $B \in E(\mathbb F_p)$.

3. An address is the ‘base58’ encoding of the string $\text{‘1’} \mathbin\Vert h \mathbin\Vert c$, where $h = \operatorname{RIPEMD160}(\operatorname{SHA256}(\underline P))$ and $c$ is the first four bytes of $\operatorname{SHA256}(\operatorname{SHA256}(\text{‘1’} \mathbin\Vert h))$.

If you could find $\underline P$ given $h$, you would be given top billing in a top-tier cryptology journal. This is because it would tear down the widely held conjecture that both RIPEMD160 and SHA256 are preimage-resistant.

If you could find $k$ given $P$, you would also be given top billing in a top-tier cryptology journal. This is because it would tear down the widely held conjecture that discrete logarithms are hard to compute in well-understood elliptic curves like secp256k1.

You would alternatively be able to make money from exploitation of much more lucrative markets than your own private blockchain or cryptology journals. But there are lots of very very smart people in cryptology who aren't doing that, and it's not just because they're all paragons of morality.

If Bitcoin can be forked, and the same address can exist on both blockchains, what stops the re-generation of a privatekey on one blockchain that would also work on the other?

The number of possible private keys is astronomically large. The keys are 256 bits long, so there are roughly 2256 possible private keys. This is a large enough number that the odds of randomly generating a private key that has already been used are effectively zero.

It's possible to intentionally reuse a private key belonging to you on another network, but doing so only introduces risks, so there's no reason to do it.