Private and Public Key Pair

[morantis]

What exact variables go into the algorithm that creates the private/public key pair?  I know that if in alternate twin universes I requested a wallet address and got X and another person in the other universe got the same public address, and all other factors remain the same the private key would also be the same, because it is a derived algorithm, not a random pairing, one derived from the other.

The purpose of the question is that I may have misinformed someone by telling them that a identical clone of the current Bitcoin code, compiled with the same merkle and everything could do no harm to the block chain, in fact those generated blocks would be unconfirmed, pushed to the side and ignored if they met on the network.  I went on to address several of his concerns that this alternate chain could take over the exchanges.  I told him the new fork may become a dominant accepted version, but that the exchanges would have to switch to the new fork and the addresses would be useless between the forks.

Am I wrong in the last part. If the address keys pairs are derived from the merkle and other hashed data, then a perfectly cloned fork would be useful in that any key pair it creates would be the same as the current fork.  With the right approach you could log into that wallet through the current fork and have access to the balance.

However, if data from the block chain is also used to generate these pairs, then that would not be possible.  BUT, I swear that in discussion we specifically said that pretty much all the key pairs are created in the very beginning and we are simply requesting the data.

The last place I may be not recalling correctly about forking is the merkle. I am pretty sure that the exact same code, merkle and all would create a nearly cloned fork that would start to differ on block 1, not block 0.

[1715275519]

1715275519

[1715275519]

1715275519

[1715275519]

1715275519

[1715275519]

1715275519

[1715275519]

1715275519

[1715275519]

1715275519

[achow101]

What exact variables go into the algorithm that creates the private/public key pair?  I know that if in alternate twin universes I requested a wallet address and got X and another person in the other universe got the same public address, and all other factors remain the same the private key would also be the same, because it is a derived algorithm, not a random pairing, one derived from the other.

The private key is a large integer that is randomly chosen. The public key is derived from the private key by performing elliptic curve multiplication by a scalar on the curve point where the private key is the scalar. The wikipedia article of ECDSA: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm describes what you need to know. The actual parameters for the secp256k1 curve is defined in http://www.secg.org/sec2-v2.pdf.

The purpose of the question is that I may have misinformed someone by telling them that a identical clone of the current Bitcoin code, compiled with the same merkle and everything could do no harm to the block chain, in fact those generated blocks would be unconfirmed, pushed to the side and ignored if they met on the network.  I went on to address several of his concerns that this alternate chain could take over the exchanges.  I told him the new fork may become a dominant accepted version, but that the exchanges would have to switch to the new fork and the addresses would be useless between the forks.

Am I wrong in the last part.

You are in a way. The addresses would exist on both forks and you can send to and from the addresses. However the balances of the addresses will not be identical across forks.

If the address keys pairs are derived from the merkle and other hashed data, then a perfectly cloned fork would be useful in that any key pair it creates would be the same as the current fork.  With the right approach you could log into that wallet through the current fork and have access to the balance.

Private keys are generated randomly, not using any other data except that used to seed the RNG.

The last place I may be not recalling correctly about forking is the merkle. I am pretty sure that the exact same code, merkle and all would create a nearly cloned fork that would start to differ on block 1, not block 0.

That depends on whether your clone uses the same genesis block or a different one. If you use a different genesis block, then you would have a completely separate blockchain (completely incompatible with Bitcoin due to the genesis block being different) but follows the exact same rules as Bitcoin.

[morantis]

Quote from: morantis on Today at 08:08:27 PM
If the address keys pairs are derived from the merkle and other hashed data, then a perfectly cloned fork would be useful in that any key pair it creates would be the same as the current fork.  With the right approach you could log into that wallet through the current fork and have access to the balance.
Private keys are generated randomly, not using any other data except that used to seed the RNG.

ok, this is the key part of the process for me.  there is no actual random data in computer code. there are numbers that are derived through so much complex math that they appear random to humans, but that same code, run over and over, receiving no outside data, will always produce the same result. Yes?

i am not very familiar with the rng, that is my next deep read.  i also want to reread the creation of the genesis block.  as i remember it the genesis block is basically the merkle hash with the algo applied, in this case SHA256.  from that a derived hash is sent to the next block and that is used as part of the hash of that block and so on.  if the new cloned fork's chain receives the same data in the beginning they match but as soon as the number of addresses requested or the precise time spent mining or whatever changes, every subsequent block will differ

[achow101]

ok, this is the key part of the process for me.  there is no actual random data in computer code. there are numbers that are derived through so much complex math that they appear random to humans, but that same code, run over and over, receiving no outside data, will always produce the same result. Yes?

Given exactly the same inputs, yes the RNG will return the same results.

i am not very familiar with the rng, that is my next deep read. 

There is no "the RNG". There are multiple RNGs, it does not matter what is used and there is not one that everyone on the Bitcoin network must use. For example, Bitcoin Core uses the RNG provided by OpenSSL. There are plans to change that. Blockchain.info at one time used (maybe still?) the RNG provided by random.org.

i also want to reread the creation of the genesis block.  as i remember it the genesis block is basically the merkle hash with the algo applied, in this case SHA256. 

The genesis block is like any other block except that the previous block hash is just all 0's. Because of this, it has to be hard coded into the software. It is a block with one transaction, the coinbase transaction, which is just like any other coinbase transaction.

from that a derived hash is sent to the next block and that is used as part of the hash of that block and so on.  if the new cloned fork's chain receives the same data in the beginning they match but as soon as the number of addresses requested or the precise time spent mining or whatever changes, every subsequent block will differ

What do you mean by "addresses requested"? Addresses requested by who? Given by who? The blockchain does not do any of this, it does not care about addresses.

The forked blockchain will differ from the real one because presumably the miner of that fork wants to send the coins to himself, so the merkle root will be different.

[morantis]

from that a derived hash is sent to the next block and that is used as part of the hash of that block and so on.  if the new cloned fork's chain receives the same data in the beginning they match but as soon as the number of addresses requested or the precise time spent mining or whatever changes, every subsequent block will differ

What do you mean by "addresses requested"? Addresses requested by who? Given by who? The blockchain does not do any of this, it does not care about addresses.

The forked blockchain will differ from the real one because presumably the miner of that fork wants to send the coins to himself, so the merkle root will be different.
[/quote]

this is hard for me to describe right. ok, the public key is a result of a math function performed on the private key.  technically, the moment the chain starts moving, the math function exists and does not change, so, in essence, every result of every key pair is "known" to the software from block 0 on, the software is simply calculating the key pair when you go to the command line and request a new address.  ANY number combination could be put in as a private key and a result would come out as the public key, its just math.  when you ask the daemon for a new address, the private key is force chosen using parameters so they meet "standards" that work. 

my point is this.  this would have been much easier two years back, but here goes.  i clone and fork bitcoin, without a single code change.  we will let the new fork run for some time and mine some of my forked coins, just something to get the chain moving.  now, i go into cli on my forked bitcoin and ask for a new address.  I receive a key pair.  if logic is right, that public/private key pair is identical to a pair on the "consensus" block chain.  so, while others are beating their heads trying to find a way to get their forked coins into the other network.  I sit back and generate the equivalent of username/password pairs to the consensus bitcoin system. 

would that work? maybe.... but before anyone goes and tries this, even if it is true, the odds of hitting a wallet address with a balance is right up there with cpu mining bitcoin.  you might as well download the right software wallet and simply push random private keys into it, same odds.  again, this is where i need to study RNG.  it is another bit of random data for security, but again, nothing is really random in computer code

[achow101]

this is hard for me to describe right. ok, the public key is a result of a math function performed on the private key.  technically, the moment the chain starts moving, the math function exists and does not change, so, in essence, every result of every key pair is "known" to the software from block 0 on, the software is simply calculating the key pair when you go to the command line and request a new address.  ANY number combination could be put in as a private key and a result would come out as the public key, its just math.  when you ask the daemon for a new address, the private key is force chosen using parameters so they meet "standards" that work. 

my point is this.  this would have been much easier two years back, but here goes.  i clone and fork bitcoin, without a single code change.  we will let the new fork run for some time and mine some of my forked coins, just something to get the chain moving.  now, i go into cli on my forked bitcoin and ask for a new address.  I receive a key pair.  if logic is right, that public/private key pair is identical to a pair on the "consensus" block chain. 

Yes.

so, while others are beating their heads trying to find a way to get their forked coins into the other network.  I sit back and generate the equivalent of username/password pairs to the consensus bitcoin system. 

would that work? maybe.... but before anyone goes and tries this, even if it is true, the odds of hitting a wallet address with a balance is right up there with cpu mining bitcoin.  you might as well download the right software wallet and simply push random private keys into it, same odds.  again, this is where i need to study RNG.  it is another bit of random data for security, but again, nothing is really random in computer code

Yes. You don't even need a forked blockchain at all. You can just generate keypairs until you get a hit. There are multiple projects that basically do this.

[morantis]

right, thanks so much, and final answer for confirmation, the math that calculates the public key from a private key is created at the beginning of the block chain and does not change.  this may be one of the few pieces of data that will be perfectly shared between two identical forks.  from block 0 forward, even identical circumstances will cause differing blocks because the timestamp is tossed into the mix multiple times in every block.

final hacking project for ninja's out there.........

generating key pairs and hoping to get a balance is near impossible, no matter what method you generate the keys....better off just mining.  BUT........

if you fork the code, isolate the rule set for output of private keys and narrow it, you may be able to enter a specific address wallet or set of wallets.  i don't know the order, but one of two things happens when you request a new address. either a random number is generated as the private key and then checked to make sure that it matches the bitcoin protocol or rules are used to supply the seed for the random number.  bitcoin might try to give you a private key of "2" and toss it based on the rules.  run through the code and change the rules for private keys to match a set of key pair you have pre-researched and your fork may then spit out a key pair that you want.  of course, all of these rules are sets of hashing, lol.  there are loads of coders that use trial and error in the lines governing addresses until they get the first two letters they want.

[achow101]

right, thanks so much, and final answer for confirmation, the math that calculates the public key from a private key is created at the beginning of the block chain and does not change.  this may be one of the few pieces of data that will be perfectly shared between two identical forks. 

Basically yes. That ECDSA should be used is defined with the first release of the software, i.e. the start of the blockchain. ECDSA was defined long before Bitcoin.

[morantis]

I think that this thread has come to an awesome point to end.  I want to thank our staff member for correcting my errors and hopefully providing information that is useful and helpful to everyone.  I am going to lock the thread down and if anyone feels life and death needs to add something hear, PM me.  Again thanks to achow101.  i find that most things i believe i fully understand can only be tested by talking about it. we are exploring bitcoin itself, in its beauty and not encouraging hacking or stealing. you have to look at all important things from all views and if a simple thread on a forum can prompt a hacker to beat bitcoin, then we need to see it can be done and work on solutions.  the greatest code writers in the world want people to test, to hack and to put their code and software through the wringer. 

satoshi, you done good