Bitcoin Forum

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

 My proposed solution is, for example, when the last Bitcoin have been mined, I mean, when we reach 21.000.000 Bitcoins, we can measure how many Bitcoin are in the blackhole and append them to the total of Bitcoins in existance.

 So, if 100.000 Bitcoins are in the black hole on the day we mined the Bitcoin number 21.000.000, we can release a new version of Bitcoin, wich will have 21.100.000 Bitcoins.

 It can be done?!

 I do not talking about Bitcoins lost by formated harddrive... But only those Bitcoins that was lost in the "blackhole"... The Bitcoins we all can see, in the blockchain, that are lost anyway.

Cheers!
Thiago

Sense = your post makes none.

It's not that easy, the blockchain was setup with an algorithm that has a limit of 21,000,000.  You can't just add more onto that without changing the entire system.  Why would do you think the lost coins would even need to be re-introduced?

1) You can never definitively know they are lost if simply sent to a wrong address. 

2) Why do you care if some coins are lost?  What if 50 tons of gold was "lost".  Would you argue we need to go find an asteroid with no more or less than 50 tons of gold to replace the lost gold?  What would happen if we didn't?

It could be done, with a patch but 51% would have to agree to do it.  For most people it would not be in their interest as it would ever so slightly devalue their coins and add unnecessary complication to bitcoin. 

We could just as easily decide to to stop the blocks from dropping in value next year, but again, why change what seems to be working? 

Just because I have never spent my coins doesn't mean I don't still have them and want them. Dumb.

many things are wrong with this. one of the biggest is that the 'last' bitcoin will never be mined. it's asymptotic.

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

what's with the 2033 estimate then?

The curve may be asymptotic, but as long as the precision of bitcoin stays at 8 decimal places, we'll eventually see the "last" bitcoin mined.

You can check it out by using blockexplorer's stats page. It can tell you what the block reward will be for any block. At one point in the future, the reward goes from 0.00000001 btc one one block, straight to zero on the next.

*fiddles with blockexplorer*

Block 6929998 will produce a reward of 0.00000001 btc, block 6929999 will produce none. Only about 6.2M blocks to go (at an average of ten minutes a block, that's over 117 years from now. I suppose there's a chance bitcoin won't even still be around by then....)

So, we could say it hits its half life in 2033(ish) (last block above 0.50.... ish)

I suppose that's one way to look at it. Hopefully by then miners will be relying more on fees than the block reward for their profits.



Wow, it gets too late and I can't even do basic math.

With about 6.77M blocks to go, that's over 128 years from now... past 2140 A.D.

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

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


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~

a satoshi already exists.

1 satoshi = 0.00000001

Still your point is right.  If through either massive adoptions (hundreds of millions of users) or reduction in usable coin supply the value of a single coin was very high (millions of dollars) clients would simply price things in fractional BTC.

Satoshis is one option.  mBTC (milli Bitcoins) or uBTC (micro Bitcoins) is another possibility.

If one BTC had same buying power as $100K USD a $5 burger might be 0.0005 BTC.  For convenience the menu might show that as 0.5 mBTC. or 500 uBTC.  The formatting and naming convention will likely develop organically depending on relative values.

Banks, large institutions, corporate reports, and possibly large purchases like houses could still use BTC.  

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.

Interesting thought, but I don't see the benefit in doing this.

Those 'missing' coins will not be missed, and whatever minuscule effect they may have is to make the remaining coins fractionally more valuable. The 21m limit is not a magic number; it is arbitrary. Whether the actual number is 21,000,000 or 20,900,000 or 20,000,000 makes no difference.

Doing something like a split or revaluing the currency is impossible without creating a fork and once you do that there will be Bitcoin new and Bitcoin legacy and the confusion that goes with that (coins will still exists in both networks).  Bad idea.

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

One way to look at it is there are 21,000 2,100 trillion base units (satoshis) or 2.1 quadrillion satoshis.  It takes 100,000,000 of them to make 1 Bitcoin.   That is how the client and blockchain handle it internally.  If you have an address with a value of 1 BTC the internal code represents that as 100,000,000.

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

And the blockchain will be 100GB by then, assuming the same level of transactions as we have today...!

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

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.

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.

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.

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.

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 hadn't thought of that aspect... very true indeed!

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.

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?

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.

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.

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.

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?

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

Makes more sense. Thank you.

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.

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.

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

It is a one time pad.  It requires one bit of key for each bit of message, and no key bits are related so all potential decodes are equally likely.  Just make sure that the key bits really are unrelated.  That is, you must a have a real source of randomness like a geiger counter, not just pseudorandomness, otherwise the PRNG seed is the real key.

Thanks. I have heard of the one-time pad, and understand why it's uncrackable (and why it's rarely used.)

Didn't remember the name of the man (Vernam, thanks Epoch) who co-developed it.

Is the system designed so that the total amount of BTC in circulation does not exceed 21m or it will always be below that figure?
From what I've read 21m is an asymptote meaning total BTC will always be nearing this number but never reaching.

I must admit I do not know if it will be 21M on the dot, or some fractional number around it.  But does it really matter if it's 21M, or 20.999M?

The exact number, assuming we don't extend the unit size beyond 1E-8, will be 20,999,999.9769.

The subsidy shifts out of a 64 bit integer.  If we change to a 128 bit representation, there will be a miniscule extra amount.

I like the idea of going with the metric system for naming smaller amounts of BTC.