What happens to bitcoins sent to other addresses?

[achow101]

Thank you again to the Staff Member who responded. Some answers gave me information I had never been aware of. The burnt bitcoins for example:
"The Bitcoin goes to a normal output. Generally the coin is considered burned, but it is still possible to access it because the receiver of the transaction can simply import their private key from another coin and import it to the coin that was actually sent."

Did you mean to say I could retrieve mistakenly burnt Bitcoin by import my alt's private key into, for example, Electrum?

Yes. You can, and I believe it has actually been done before with multisig addresses with Litecoin.

[morantis]

Thank you again to the Staff Member who responded. Some answers gave me information I had never been aware of. The burnt bitcoins for example:
"The Bitcoin goes to a normal output. Generally the coin is considered burned, but it is still possible to access it because the receiver of the transaction can simply import their private key from another coin and import it to the coin that was actually sent."

Did you mean to say I could retrieve mistakenly burnt Bitcoin by import my alt's private key into, for example, Electrum?

Yes. You can, and I believe it has actually been done before with multisig addresses with Litecoin.

i did know a guy last year that thought the most final way to burn coins was to simply make up an address and never request it from the network, uisng the right two first digits.  he did have the sense to check the address balance and history online and used a basically random address as a burn wallet.

only thing with that is the fact that requesting an address from the network allows the network to consider that address used and not give it out again.  with the guy i was talking about, his method did indeed mean there was never a private key to get rid of, but by chance someone, someday day will get a little surprise in their new wallet address

[DannyHamilton]

requesting an address from the network allows the network to consider that address used and not give it out again.

This is not true.  This is not how bitcoin works.

Wallets do not "request addresses from the network".

Wallet generate a random 256 bit number (On their own, without communicating with the network about it at all)  They use that number as a private key.  Then they use elliptic curve point multiplication to calculate a public key from that private key.  Finally they use SHA256 and RIPEMD160 hashing algorithms along with base58 numeric representation to calculate the bitcoin address from the public key.

"The network" doesn't know anything about bitcoin addresses, and it doesn't check to see if an address is used yet or not.

This was already explained to you yesterday...

- snip -
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.
- snip -
Private keys are generated randomly, not using any other data except that used to seed the RNG.
- snip -

And also...

- snip -
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.
- snip -

The only reason that two people don't end up with the same address is because the random number generation is very good at being random AND the pool of valid numbers to choose from is so big.

It doesn't matter if you generate your address with a wallet, or if you generate your address completely offline with a calculator.  The odds of someone else getting the same address are exactly the same either way.  Those odds are so incredibly small that it is safe to consider it impossible as long as your random number generator is good enough.

by chance someone, someday day will get a little surprise in their new wallet address

No.  They won't.

[ArcCsch]

by chance someone, someday day will get a little surprise in their new wallet address

No.  They won't.

Actually, this has happened before, some wallet software was created by n00bs, who sometimes used poor random number generators, resulting in users generating a wallet and finding someone else's bitcoin, and someone else opening their wallet and finding it empty.

[DannyHamilton]

by chance someone, someday day will get a little surprise in their new wallet address

No.  They won't.

Actually, this has happened before, some wallet software was created by n00bs, who sometimes used poor random number generators, resulting in users generating a wallet and finding someone else's bitcoin, and someone else opening their wallet and finding it empty.

No.  THIS  has not happened before:

simply make up an address . . . using the right . . . digits . . . a basically random address as a burn wallet . . . there was never a private key . . . by chance someone, someday day will get a little surprise in their new wallet address

ArsCsch is talking about generating an address from a private key that wasn't securely random.  If your software has a flaw in the selection of private key, then it is possible that someone else could run get the same private key (accidentally or intentionally).  If that happens, then they will have the same address and be able to spend the bitcoins that are received at that address.

morantis is talking about creating a string of letters and numbers that matches the requirements to be a valid bitcoin address without using any private key or public key at all.  If you do that, and you don't intentionally just copy an existing address, then nobody is going to stumble into  the same address.

[buwaytress]

The only reason that two people don't end up with the same address is because the random number generation is very good at being random AND the pool of valid numbers to choose from is so big.

It doesn't matter if you generate your address with a wallet, or if you generate your address completely offline with a calculator.  The odds of someone else getting the same address are exactly the same either way.  Those odds are so incredibly small that it is safe to consider it impossible as long as your random number generator is good enough.

I don't know the statistical odds of a person getting an address that was already generated for someone else previously - from your explanation this is very, very small to the point of virtual impossibility. But, this is not a theoretical impossibility, am I correct?

Does this pool of valid numbers grow bigger or is it stagnant? What if, for argument's sake, the rate of address generation multiplies a million-fold in 50 years? When we have 20 billion population and a trillion computers generating addresses at the rate of trillions a day? Surely this impossibility suddenly becomes only extremely unlikely?

Only curious=)

[achow101]

I don't know the statistical odds of a person getting an address that was already generated for someone else previously - from your explanation this is very, very small to the point of virtual impossibility. But, this is not a theoretical impossibility, am I correct?

Yes, in theory there is a non-zero probability that there will be an address collision. This probability is just so low that it is in effect zero.

Does this pool of valid numbers grow bigger or is it stagnant?

It is stagnant. There are 2^160 possible addresses.

What if, for argument's sake, the rate of address generation multiplies a million-fold in 50 years? When we have 20 billion population and a trillion computers generating addresses at the rate of trillions a day? Surely this impossibility suddenly becomes only extremely unlikely?

Only curious=)

Suppose addresses were generated at a rate of 1 trillion addresses per day since the beginning of Bitcoin (or now for that matter, it wouldn't make a difference). It would take 4.0041141*10^33 years to run out of addresses. To put that into context, that is the sun's lifespan 4.0041141*10^23 times over.

[morantis]

I don't know the statistical odds of a person getting an address that was already generated for someone else previously - from your explanation this is very, very small to the point of virtual impossibility. But, this is not a theoretical impossibility, am I correct?

Yes, in theory there is a non-zero probability that there will be an address collision. This probability is just so low that it is in effect zero.

Does this pool of valid numbers grow bigger or is it stagnant?

It is stagnant. There are 2^160 possible addresses.

What if, for argument's sake, the rate of address generation multiplies a million-fold in 50 years? When we have 20 billion population and a trillion computers generating addresses at the rate of trillions a day? Surely this impossibility suddenly becomes only extremely unlikely?

Only curious=)

Suppose addresses were generated at a rate of 1 trillion addresses per day since the beginning of Bitcoin (or now for that matter, it wouldn't make a difference). It would take 4.0041141*10^33 years to run out of addresses. To put that into context, that is the sun's lifespan 4.0041141*10^23 times over.

  if you soft fork the code line where a hash is supplied to determine the address format, say just change a single digit and now newly generated addresses start with whatever "24" instead of "14" does that affect the previous addresses that have been generated causing them to be invalid or simply alter the new addresses?

[achow101]

if you soft fork the code line where a hash is supplied to determine the address format, say just change a single digit and now newly generated addresses start with whatever "24" instead of "14" does that affect the previous addresses that have been generated causing them to be invalid or simply alter the new addresses?

That's not how addresses work. Addresses are determined by the output type they represent. 1... addresses represent p2pkh outputs which are of the form

Code:

OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG

3... addresses represent p2sh outputs which are of the form

Code:

OP_HASH160 <redeemscript hash> OP_EQUAL

The limiting factor here is the hash160. With p2sh hash collisions can result in the loss of Bitcoins. With p2pkh, public key hashes have to collide to result in Bitcoin loss.

A new output type (say segwit outputs, or replace the OP_HASH160 with OP_HASH256) can be defined and a subsequent address version number assigned to that output to get more than 2^160 addresses.

[morantis]

if you soft fork the code line where a hash is supplied to determine the address format, say just change a single digit and now newly generated addresses start with whatever "24" instead of "14" does that affect the previous addresses that have been generated causing them to be invalid or simply alter the new addresses?

That's not how addresses work. Addresses are determined by the output type they represent. 1... addresses represent p2pkh outputs which are of the form

Code:

OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG

3... addresses represent p2sh outputs which are of the form

Code:

OP_HASH160 <redeemscript hash> OP_EQUAL

The limiting factor here is the hash160. With p2sh hash collisions can result in the loss of Bitcoins. With p2pkh, public key hashes have to collide to result in Bitcoin loss.

A new output type (say segwit outputs, or replace the OP_HASH160 with OP_HASH256) can be defined and a subsequent address version number assigned to that output to get more than 2^160 addresses.

maybe i am saying it wrong or the latest fork is different, but let me use litecoin as an example.  the address start letter is determined by a base8 hash that is hard coded in the source.  i agree that it is absolutely impossible to run out of addresses

[DannyHamilton]

maybe i am saying it wrong or the latest fork is different, but let me use litecoin as an example.  the address start letter is determined by a base8 hash that is hard coded in the source.  i agree that it is absolutely impossible to run out of addresses

In bitcoin (and litecoin) the address actually consists of 3 separate numerical values that are represented in the wallet software as integers.

• A 1 byte script indicator
• A 20 byte RIPEMD160 hash
• A 4 byte checksum

These 25 bytes are concatenated together, and the resulting 25 byte (200 bit) integer is converted from binary to base58.  This base58 value is what we humans call an "address".  At the blockchain level, and the network communications level, addresses aren't used.  The addresses are converted into the data that they represent.

For instance, in bitcoin, a script indicator with a hex value of 0x00 indicates to the wallet software that it should use the P2PKH script, while a script indicator with a decimal value of 0x05 indicates to the wallet that it should use the P2SH script.  When converting the 25 byte value to base58, the P2PKH script (first byte = 0x00) results in a base58 value with a first character of a "1" whereas the P2SH script (first byte = 0x05) results in a base 58 value with a first character of "3".

Your question about "if you soft fork the code line where a hash is supplied to determine the address format" doesn't make any sense.  Changing the first character would mean adding a new script type for bitcoin to use.  Whether or not this affects the number of distinct possible ways to secure some value of bitcoins would depend on that that new script type is.

[morantis]

maybe i am saying it wrong or the latest fork is different, but let me use litecoin as an example.  the address start letter is determined by a base8 hash that is hard coded in the source.  i agree that it is absolutely impossible to run out of addresses

In bitcoin (and litecoin) the address actually consists of 3 separate numerical values that are represented in the wallet software as integers.

• A 1 byte script indicator
• A 20 byte RIPEMD160 hash
• A 4 byte checksum

These 25 bytes are concatenated together, and the resulting 25 byte (200 bit) integer is converted from binary to base58.  This base58 value is what we humans call an "address".  At the blockchain level, and the network communications level, addresses aren't used.  The addresses are converted into the data that they represent.

For instance, in bitcoin, a script indicator with a hex value of 0x00 indicates to the wallet software that it should use the P2PKH script, while a script indicator with a decimal value of 0x05 indicates to the wallet that it should use the P2SH script.  When converting the 25 byte value to base58, the P2PKH script (first byte = 0x00) results in a base58 value with a first character of a "1" whereas the P2SH script (first byte = 0x05) results in a base 58 value with a first character of "3".

Your question about "if you soft fork the code line where a hash is supplied to determine the address format" doesn't make any sense.  Changing the first character would mean adding a new script type for bitcoin to use.  Whether or not this affects the number of distinct possible ways to secure some value of bitcoins would depend on that that new script type is.

you are right, it is very late here and i am getting very tired, thanks

[buwaytress]

I don't know the statistical odds of a person getting an address that was already generated for someone else previously - from your explanation this is very, very small to the point of virtual impossibility. But, this is not a theoretical impossibility, am I correct?

Yes, in theory there is a non-zero probability that there will be an address collision. This probability is just so low that it is in effect zero.

Does this pool of valid numbers grow bigger or is it stagnant?

It is stagnant. There are 2^160 possible addresses.

What if, for argument's sake, the rate of address generation multiplies a million-fold in 50 years? When we have 20 billion population and a trillion computers generating addresses at the rate of trillions a day? Surely this impossibility suddenly becomes only extremely unlikely?

Only curious=)

Suppose addresses were generated at a rate of 1 trillion addresses per day since the beginning of Bitcoin (or now for that matter, it wouldn't make a difference). It would take 4.0041141*10^33 years to run out of addresses. To put that into context, that is the sun's lifespan 4.0041141*10^23 times over.

Now that is something that I'd add to any proper "curious facts about bitcoin" document. Thanks very much for the answer. I personally can't quote any other more improbably event. This is the type of answer/comparison that helps people like me put perspectives into the "why" of bitcoin.

It's a cold comfort that our sun would likelier die first before an address identical to a previously generated one is generated again.