Possible solution for recovering lost Bitcoin to the "blackhole".

[DeathAndTaxes]

Much simpler to just use another unit like Satoshi or mBTC (micro Bitcoins).

I thought you had defined mBTC as milli Bitcoins before ...  

Typo.  m is the SI prefix for mili.  Micro would be 10^-9 which would be smaller than a satoshi.

Man it has been a long time since I used SI prefixes.  Utter fail on my part.

mBTC would be 10^-3 (or 100,000 satoshis)
uBTC would be 10^-6 (or 100 satoshis)
nBTC would be 10^-9 ( which is not possible as it would be 1/10th of a satoshi).

Thanks kjj

[1714828196]

1714828196

[1714828196]

1714828196

[1714828196]

1714828196

[1714828196]

1714828196

[MoonShadow]

Guys,

 I've already saw many threads talking about some Bitcoins that have been sent to the "Bitcoin Blackhole"...

 Those Bitcoins will never back and, the person who sent them, lost money.

 But, WE know that those Bitcoins are now in the Blackhole...

 

Actually, we don't know that.  All that we can really know for certain is that there are addresses in the blockchain that have not transfered funds away in a very long time.  We can't know if they are lost unless the owner of the address says so, and can prove that he is, in fact, the owner of that address.  However, the way the system is designed, if the person making the claim can prove that the address is his, then he has the secret key to that address, and thus the funds are not lost.

Also, we don't really need those lost coins, it doesn't really matter how many are lost, because the 21 million BTC limit is arbitrary anyway.

[MoonShadow]

Besides, there is a long term solution for the lost coins anyway.  Eventually, hashing hardware will continue to increase until SHA256 alone is no longer secure.  Long before this, another algo will be swapped into Bitcoin in it's place (or in addition to SHA256, the code in question is modular as well as there are already two 'modules' to use, both just happen to be SH256 at the moment).  Eventually, everyone who still has funds are going to move those funds to addresses using the more secure algos, and the lost coins will be exposed for being the only addresses left on the blockchain using oly SHA256.  That's when the 'salvage' process begins, and the treasure hunters of the electronic currency age will be doing everything that they can to be the first to force a SHA256 'collision' against those (now known) lost addresses.

[kjj]

Much simpler to just use another unit like Satoshi or mBTC (micro Bitcoins).

I thought you had defined mBTC as milli Bitcoins before ... 

Typo.  m is the SI prefix for mili.  Micro would be 10^-9 which would be smaller than a satoshi.

Micro (u or μ for the purists) is 1E-6.  1E-9 is Nano (n).  The current granularity is 10nBTC because we only represent down to 1E-8.

[beckspace]

One way to look at it is there are 21,000 trillion base units (satoshis).

21 trillion plus cents (,00).

or

(1 / 0.00000001) * 21,000,000 = 2,100,000,000,000,000 atomic units.


21 million BTC (bitcoins)

21 billion mBTC (milibitcoins)

21 trillion uBTC (microbitcoins)

That's 2.1 quadrillion satoshis.

[Phinnaeus Gage]

I resurrected an old thread to further discuss this issue so not to further hijack this thread:
https://bitcointalk.org/index.php?topic=13495.msg687909#msg687909

I would leave them lost, we have 8 decimal places so there are two quadrillion one hundred trillion units not twenty one million

Basically what I was going to pen after reading the OP.

There's virtually no need to recover the lost coins. If 1 BTC become too valuable to be a standard unit, then we'll just use 0.01 BTC as the standard (and give it a name too, like 1 satoshi).

I believe that 'Satoshi' is reserved for the 8th decimal place. There's a thread discussing name proposals for the other decimal places, but I didn't take time to hunt it.

If I'm not mistaken, there's going to be a problem if we start using .xxxx? Humans are accustomed to whole numbers, not fractions or decimals, when it comes to their medium of exchange--money. At the moment, there's 8M BTC in circulation. If next month a million new people joined the Bitcoin train, not only would the exchange rate be high, but everyone will be seeing .xxxxx no matter what name you call it (nano, being one that just came to mind).

There is one way I can see it working out for all concerns, and it's not meant as a proposal--just a brain fart, if you will. Currently there are 8M+ BTC. Let's say a million new people join. The rate becomes 1 BTC = $100 USD. Even though a $2 USD purchase equates to only .02 BTC, people are less prone to purchase 1 BTC for $100 USD. But if it 1 BTC = $10 USD, all is well again. That can be done by a split. There will then be 80,000,000 MAIN units in play, units that will be called Bitcoin (bitcoins). And when we reach the 10M original bitcoins mined, and there's another doubling or so new users, split again to having 1,000,000,000 units now referred to Bitcoin(s).

This way it's always called Bitcoin or bitcoins or BTC for the main units. Perhaps this can all be done at the mining level during the awarding of BTC blocks.

As I've said earlier, it's just an idea, and I real don't know how to do this or, for that matter, what I'm talking about, let alone trying to relay. But. hopefully, the gist of it comes across, even if the whole thing is shot down.

~Bruno~

[SgtSpike]

Besides, there is a long term solution for the lost coins anyway.  Eventually, hashing hardware will continue to increase until SHA256 alone is no longer secure.  Long before this, another algo will be swapped into Bitcoin in it's place (or in addition to SHA256, the code in question is modular as well as there are already two 'modules' to use, both just happen to be SH256 at the moment).  Eventually, everyone who still has funds are going to move those funds to addresses using the more secure algos, and the lost coins will be exposed for being the only addresses left on the blockchain using oly SHA256.  That's when the 'salvage' process begins, and the treasure hunters of the electronic currency age will be doing everything that they can to be the first to force a SHA256 'collision' against those (now known) lost addresses.

I hadn't thought of that aspect... very true indeed!

[DeathAndTaxes]

Besides, there is a long term solution for the lost coins anyway.  Eventually, hashing hardware will continue to increase until SHA256 alone is no longer secure.  Long before this, another algo will be swapped into Bitcoin in it's place (or in addition to SHA256, the code in question is modular as well as there are already two 'modules' to use, both just happen to be SH256 at the moment).  Eventually, everyone who still has funds are going to move those funds to addresses using the more secure algos, and the lost coins will be exposed for being the only addresses left on the blockchain using oly SHA256.  That's when the 'salvage' process begins, and the treasure hunters of the electronic currency age will be doing everything that they can to be the first to force a SHA256 'collision' against those (now known) lost addresses.

Unless a cryptographic flaw is found I doubt SHA-256 will ever become insecure.  Any insecurity will be due to a flaw which allows cryptographers to cheat not due to more powerful computers.

Vanity gen brute forces private keys.  A top of the line GPU will handle about 20MH/s.  Now lets assume vanity gen is inefficient and you developed a treasure hunter software which was 10x as efficient at trying random private keys, building public address and checking for value.  Also lets say a SHA-256 28nm (current gen) ASIC came out which was 20x as fast as fastest GPU at the same pricepoint.  Now lets also say Moore's law stays alive for the next century (doubling every 24 months).    In 2112 you would have a chip which is 4.5 YH/s (Yottahashes).

That would be roughly equal to all the computing power (in all forms) on the planet right now in a single chip.  Now say you built a cluster of 100,000 of these (would have equivalent cost as 100,000 GPU today) and hashed SHA-256 private keys for the next millennium (till year 3112).

In that millennium you would be able to check 1.4x10^34 private keys.  Which is roughly 0.00000000000000000000000000000000000000001227% of the SHA-256 keyspace.  Now lets sweeten the pot.  Lets say that there are 10 billion active users and 1 quadrillion active and lost private keys.  You would still have only a roughly a 1 in a quadrillion quadrillion chance of finding any key with value after searching for a 1000 years with 100,000 chips each w/ the computing power of the planet today.

SHA-256 is big.  Far bigger than most people can comprehend.  It won't be brute forced.  Not today, not in a century.   The pysical world equivelent would be like saying we might run out of matter in the universe if we keep building things.  SHA-256 may be BROKEN due to cryptographic flaws but it won't be due to increasing hashing power.

[rjk]

SHA-256 is big.  Far bigger than most people can comprehend.  It won't be brute forced.  Not today, not in a century.   The pysical world equivelent would be like saying we might run out of matter in the universe if we keep building things.  SHA-256 may be BROKEN due to cryptographic flaws but it won't be due to increasing hashing power.

Cool story. My understanding is that the blockchain uses SHA256, but the keypairs are ECDSA. Is ECDSA still 2^256, or is it something else?

[kjj]

If we ever expand beyond the current 64 bit integer representation of 1e-8 BTC, then mining could go on for quite a while, if I recall correctly.  I'll poke through the source code in a bit, but if I recall, the subsidy is right shifted off the end until it goes to zero.  Switching to 128 bit integers would let it keep shifting off longer than the current setup.  Of course, we are talking about tiny amounts, even with massive deflation.

Code:

int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}

Yup, the subsidy is right-shifted out (without carry).  Which means that the end of the subsidy depends on the size of the integer we are using.  So, unless there is a further code change, the subsidy will last about 128 more years (4 * log₂ 50E+8).  An expansion to 128 bit integers will give roughly 64 more shifts, or about 256 more years.  This would have a negligible impact on the total amount of coins.

Actually, we are really only using the bottom 51 bits right now, so if we are changing formats, we could change the pseudo-mantissa from 10e-8 to 10e-30 rather than 10e-17.  21,000,000 * 10^30 just barely allows exact representation in 127 bits (allowing signed math).  If we want to contemplate projects with costs that are many multiples of the total amount of money in the world (which isn't as silly as it sounds), but still allow them to use 128 bit signed representation, we could pick 10e-24 or 10e-21.

Oh, but the value of the subsidy starting in block 2,310,000 will be different in 128 bits than it is in 64 bits.  So, we really should plan how we want to expand sometime in the next 30 years or so.

Sorry, this is mostly off topic, but interesting.  I sometimes get carried away when I calculate.

[kjj]

SHA-256 is big.  Far bigger than most people can comprehend.  It won't be brute forced.  Not today, not in a century.   The pysical world equivelent would be like saying we might run out of matter in the universe if we keep building things.  SHA-256 may be BROKEN due to cryptographic flaws but it won't be due to increasing hashing power.

Cool story. My understanding is that the blockchain uses SHA256, but the keypairs are ECDSA. Is ECDSA still 2^256, or is it something else?

The private key is a 256 bit random number, the public key is derived from that random number.  His discussion is still totally valid, since he is really talking about any 256 bit keyspace.  It is even more valid since you don't have to recover the original private key, just any private key that corresponds to one of the public keys in the chain.

[rjk]

SHA-256 is big.  Far bigger than most people can comprehend.  It won't be brute forced.  Not today, not in a century.   The pysical world equivelent would be like saying we might run out of matter in the universe if we keep building things.  SHA-256 may be BROKEN due to cryptographic flaws but it won't be due to increasing hashing power.

Cool story. My understanding is that the blockchain uses SHA256, but the keypairs are ECDSA. Is ECDSA still 2^256, or is it something else?

The private key is a 256 bit random number, the public key is derived from that random number.  His discussion is still totally valid, since he is really talking about any 256 bit keyspace.  It is even more valid since you don't have to recover the original private key, just any private key that corresponds to one of the public keys in the chain.

Thanks, that clears it up for me.

[DeathAndTaxes]

Cool story. My understanding is that the blockchain uses SHA256, but the keypairs are ECDSA. Is ECDSA still 2^256, or is it something else?

Yes.  Although if you want to get into the weeds generating a single address is a "little" complex (not sure what Satoshi was smoking )
1. Start with a 256 bit nonce (cryptographically secure pseudo-random number).
2. Use ECDSA to generate a corresponding public key.
3. Perform SHA-256 hash of the public key
4. Perform RIPEMD-160 hashing on the result of SHA-256
5. Add network byte in front of RIPEMD-160 hash (0x00 for Main Network)
6. Perform SHA-256 hash on the extended RIPEMD-160 result
7. Perform SHA-256 hash on the result of the previous SHA-256 hash
8. Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
9. Add the 4 checksum bytes from point 7 at the end of extended RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin Address.

Of the 3 algorithms used SHA-256 is the most computationally intensive and it is performed 3 times in each key generation which is why I focused on that.  The reason vanity gen can "only" try 20 million private keys (as opposed to 80 trillion) is primarily due to computational "cost" of the SHA-256 steps.

It is possible one or more of the algorithms will be BROKEN due to a flaw but 256 bit is far too large to brute force even with planetary sized super computers.

To put it into perspective.
Number of potential private keys in 256 bit keyspace: 1.15792E+77
Number of atoms in our entire galaxy: 1.25E+69

It would take ~90 million (average sized ) galaxies to have as many atoms as there are keys in a 256 bit keyspace.

PS:
Technically my math above was off because I forgot that due to RIPEMD-160 hash there are potentially 7x10^28 private keys for each public address so the problem is 10^28 times "easier" but still computationally infeasible without a cryptographic flaw.

[rjk]

Yes.  Although if you want to get into the weeds generating a single address is a "little" complex (not sure what Satoshi was smoking )
1. Start with a 256 bit nonce (cryptographically secure pseudo-random number).
2. Use ECDSA to generate a corresponding public key.
3. Perform SHA-256 hash of the public key
4. Perform RIPEMD-160 hashing on the result of SHA-256
5. Add network byte in front of RIPEMD-160 hash (0x00 for Main Network)
6. Perform SHA-256 hash on the extended RIPEMD-160 result
7. Perform SHA-256 hash on the result of the previous SHA-256 hash
8. Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
9. Add the 4 checksum bytes from point 7 at the end of extended RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin Address.

Of the 3 algorithms used SHA-256 is the most computationally intensive and it is performed 3 times in each key generation which is why I focused on that.  The reason vanity gen can "only" try 20 million private keys (as opposed to 80 trillion) is primarily due to computational "cost" of the SHA-256 steps.

Jebus that is complex. So if I understand correctly, the first seven steps (not including step 2) are like this: SHA256(SHA256(0x00 + RIPEMD160(SHA256(nonce))))
Yay? Nay?

[DeathAndTaxes]

So if I understand correctly, the first seven steps (not including step 2) are like this: SHA256(SHA256(0x00 + RIPEMD160(SHA256(nonce))))

Yes except to say it is SHA256 of the nonce would confuse someone who didn't already know what you were trying to say.

More accurately it is (steps 3 to 7)
SHA256(SHA256(0x00 + RIPEMD160(SHA256(public key))))


Put all together:
base address = 0x00 + RIPEMD160(SHA256(public key))))
checksum = left 4 bytes (SHA256(SHA256(base address)))
full address = (base address) + (checksum)     <- don't add just append

[rjk]

So if I understand correctly, the first seven steps (not including step 2) are like this: SHA256(SHA256(0x00 + RIPEMD160(SHA256(nonce))))

Yes except to say it is SHA256 of the nonce would confuse someone who didn't already know what you were trying to say.

More accurately it is (steps 3 to 7)
SHA256(SHA256(0x00 + RIPEMD160(SHA256(public key))))


Put all together:
base address = 0x00 + RIPEMD160(SHA256(public key))))
checksum = left 4 bytes (SHA256(SHA256(base address)))
full address = (base addres)s + (checksum)

Makes more sense. Thank you.

[MoonShadow]

SHA-256 is big.  Far bigger than most people can comprehend.  It won't be brute forced.  Not today, not in a century.   The pysical world equivelent would be like saying we might run out of matter in the universe if we keep building things.  SHA-256 may be BROKEN due to cryptographic flaws but it won't be due to increasing hashing power.

Cool story. My understanding is that the blockchain uses SHA256, but the keypairs are ECDSA. Is ECDSA still 2^256, or is it something else?

Yes, sorry.  Address keypairs are created by ECDSA, while the hashing is done by SHA256.  The bruteforcing would have to be done by ECDSA hardware to create any address collision.  Basicly a huge rainbow table would have to be built and the list of lost addresses would be compared against it.

[MoonShadow]

I don't doubt that the bruteforcing of addresses, as they presently exist, would require a truely astronomical computational ability, and is certainly safe for decades.  That was the point of the design, after all.  However, I think that it's also a bit silly to assume that such astronomical computational abilities will remain out of reach for humanity forever.  The only cryptographic algo that is provablely secure from brute force forever is the simple Vernon Cypher, which has no applications here.

[westkybitcoins]

The only cryptographic algo that is provablely secure from brute force forever is the simple Vernon Cypher, which has no applications here.

Is that known by another name? Searching Google and Wikipedia for "vernon cypher" didn't return useful results.

[Epoch]

The only cryptographic algo that is provablely secure from brute force forever is the simple Vernon Cypher, which has no applications here.

Is that known by another name? Searching Google and Wikipedia for "vernon cypher" didn't return useful results.

You might have better luck with 'Vernam cipher'.