Yes the coins are lost forever. No amount of hash-power that we could reasonably posses will ever find all or even a few of the priv keys.
nothing that we could possess TODAY. Technology marches on
Topic: Lost Bitcoins - page 3. (Read 14211 times)
nothing that we could possess TODAY. Technology marches on
Back to the question:
Is it possible that sometime in the future there may be a way crack private keys of lost coins?
Maybe because those lost coins are less protected then the not lost ones?
you can crack them now with vanitygen, good luck doing it though.
For the naive (or superlucky) ones:
the 2^256 Deep Space Vagabond awaits you (my little timesink project)
Back to the question:
Is it possible that sometime in the future there may be a way crack private keys of lost coins?
Maybe because those lost coins are less protected then the not lost ones?
you can crack them now with vanitygen, good luck doing it though.
satohsidice is holding over 16 of my BTC hostage. Dont ask me why 
The whole hard limit will kill BTC all by itself one day. No one needs to do anything but wait and sell BTC to suckers err, investors.
Probably because headroom is useful too. It means that 64 bit accounting systems, for example, can be exact even when dealing with values many times larger than the bitcoin market cap.
What you should argue is, if you are going to make the change, make the change smart. Doubling the size of every integer in the block chain so that you can go to 30 zeroes seems a bit odd from that standpoint. I wonder why satoshi didn't just go to 11 decimals though since that wouldn't have changed anything.
A 64 bit int can hold the entire supply (8 decimals in all) in one integer, 8,700 times over. 4 more decimals could be added and still almost hold the entire supply in one int64 (18.5 vs 21 with a bunch of zeroes). If you limit the left hand side, you could go much further than 4 more decimals.
But why would you do that? Changing the way you interpret the integer is what breaks everything, not the size of the field. If you are going to make the change, make the change big.
A 64 bit int can hold the entire supply (8 decimals in all) in one integer, 8,700 times over. 4 more decimals could be added and still almost hold the entire supply in one int64 (18.5 vs 21 with a bunch of zeroes). If you limit the left hand side, you could go much further than 4 more decimals.
Requiring a hard fork to add extra decimal places is a significant, breaking change to the bitcoin protocol and should not be taken lightly or assumed to be part of the specification.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
Fair enough. In any event, it's difficult to imagine 8 decimal places not being sufficient. I still don't understand why it isn't possible to always be able to add one more decimal place to the right.
The protocol currently uses integer math. Values are 64 bit. If I send 1 BTC to myself, in the transaction that shows up at 100,000,000.
In other words, the fundamental unit of the system is 1/100,000,000 of a BTC (commonly nicknamed "one satoshi"). The software does all math in terms of satoshis, but displays BTC to the user by scaling.
I sorta suspect that we'll switch to a 128 bit representation for technological reasons (wider CPUs) long before we need more digits for economic reasons. Such a switch would give us some combination of more headroom and more dividing room. It would also require a more-or-less hard fork.
Yes they are lost for good. The currency is divisible to 8 decimal places and potentially further if there is a significant need and a code change. So the currency can adapt in its silly way.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
What is the limit on the potential divisibility that you admit exists?
The value isn't stored in the blockchain as a decimal at all. It is stored as an integer . . .
Technically the blockchain doesn't store values it stores unspent outputs . . .
Yes they are lost for good. The currency is divisible to 8 decimal places and potentially further if there is a significant need and a code change. So the currency can adapt in its silly way.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
What is the limit on the potential divisibility that you admit exists?
The value isn't stored in the blockchain as a decimal at all. It is stored as an integer. The client just creates a decimal 8 places to the left when it displays it to you. The client can be modified to create that decimal less places to the left if desired (display in mBTC or uBTC rather than BTC), but none of that changes how the value is actually stored.
As I understand it, to change how much the value represents will require changing how the value is stored in the blockchain. Potentially you could have some miners storing their newly minted coins in the old format, and some storing them in the new format if they don't all upgrade simultaneously. The upgraded wallets would recognize the new format as valid, while those people who don't upgrade their wallets in time would see the old format as valid. This would split the blockchain into 2 types of bitcoin.
Technically the blockchain doesn't store values it stores unspent outputs. While all unspent outputs are currently in the same format it would be possible to have new "high precision" addresses which say store Bitcoins in a new format. This new format would only be used on new addresses.
The migration process would be similar to P2SH:
1) Hash out the details, test, debate, etc.
2) Request miners put a tag in the codebase of solved blocks indicating they support the protocol change.
3) When sufficient majority of miners support the change (I think Gavin looked for 80% in P2SH) release a new version of the client.
4) The new version(s) of the client have a changeover block coded into the client. The client would have the ability to support the new address type but it would reject them as invalid if seen prior to the changeover block.
5) On the change over block the new address type would be supported.
At that point older nodes (both miners and non-miners) would be forked off. The main main chain seen as the longest by upgraded nodes would be seen as invalid by them (they would see the new high precision addresses as invalid txs). As long as they represent a minority there is no real harm. They simply need to upgrade to the new version. There is no issue of their client's being "confused" (showing wrong amounts, etc) they simply would reject block & tx involving the new incompatible address.
It worked well with P2SH and IIRC Gavin brought up some ideas that would make future transitions easier (like coding a version number into the blocks & clients so that client would warn users when they see a future incompatible version on the network.
Since Bitcoin doesn't store values it stores unspent outputs (which are used as a single unit) it is possible to support newer high precision addresses while at the same time also supporting "legacy" addresses. User could keep using their old addresses or have a new version of the client generate a new address for them and move their funds to the new address.
Back to the question:
Is it possible that sometime in the future there may be a way crack private keys of lost coins?
Maybe because those lost coins are less protected then the not lost ones?
Is it possible that sometime in the future there may be a way crack private keys of lost coins?
Maybe because those lost coins are less protected then the not lost ones?
The answer is complicated, but yes it is possible and may even be profitable at some point. While SHA256 has 256 bits of effective security, the ECDSA curve that bitcoin uses only has 128 bits of effective security, 3.4^38 times easier to crack. And that is still beyond the realm of all the computing power in the world to crack in less than several hundred years. But that is assuming computing power doesn't increase. 128-bit security is predicted to be secur-ish until 2030 or so. It will still be viable for some time after that most likely, but eventually accounts will have to upgrade to 144 bits or 160 bits of security in the future, while lost coins would be vulnerable. There is an extra complication/protection though that many balances are stored as RIPEMD160 (160 bits) hashes rather than ECDSA public keys. This means an attacker would have to find a private key that works for a public key that hashes to a known RIPEMD160 hash, and this is exceedingly unlikely. But not all addresses are stored this way.
There is an algorithm that would allow a quantum computer with sufficient qubits to crack RSA or ECDSA key within minutes. But that's another topic and not something to worry about just yet.
Also, there is still a possibility that we solve the "hard problems" associated with digital signatures and it would make cracking them almost instant. (again they would be protected if they were RIPEMD160 hashed though)
Fair enough. In any event, it's difficult to imagine 8 decimal places not being sufficient. I still don't understand why it isn't possible to always be able to add one more decimal place to the right.
Of course its possible. Same as increase block reward to 500btc. There is just one thing, rest of the network must agree.
Requiring a hard fork to add extra decimal places is a significant, breaking change to the bitcoin protocol and should not be taken lightly or assumed to be part of the specification.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
Fair enough. In any event, it's difficult to imagine 8 decimal places not being sufficient. I still don't understand why it isn't possible to always be able to add one more decimal place to the right.
Is it possible that sometime in the future there may be a way crack private keys of lost coins?
If you can crack lost coins and be profitable, then you'd also be able to crack anyone's coins.
As I understand it, what will happen far in the future is SHA-256 will be broken (Computing power keeps increasing) and bitcoin will have moved onto a better encryption method. If you don't move to the new encryption method with everyone else, then you will have people "mining" for your bitcoins.
Is this accurate at all? I know my terms may be off.
Is this accurate at all? I know my terms may be off.
256 bits is the sweet spot where it would take every joule of the sun's energy produced in an entire year just to COUNT from zero to 256 bits given the completely impractical idea that moving a bit would require the smallest unit of energy possible. Now consider that SHA256 is an algorithm that involves many operations with many rounds (way harder than just counting). As long as a significant weakness is not discovered in SHA256 (there have been some very minor ones), it will likely be forever impossible to break. The SHA3 competition from NIST though looks to address some of the shortcomings of SHA256 and make an even more secure hashing algorithm with less potential weaknesses. But 256 bits will still always be more than enough bits except in the case of quantum computing which could effectively render SHA's 256 bit protection to 128 bits. The counter to that is using a 512 bit algorithm, but that is the end of the road.
But SHA256 is not used for storing your bitcoins, that is done by a digital signature algorithm and those have significantly more weaknesses and few if any are rated as "rock solid, can't be broken" secure by cryptanalysists. Certain properties can be proven secure, but not the algorithm as a whole because they are making use of NP hard type math problems that might have solutions that we just don't know about yet. QC will also make finding solutions significantly easier for things like RSA and ECDSA (what bitcoin uses).
Back to the question:
Is it possible that sometime in the future there may be a way crack private keys of lost coins?
Maybe because those lost coins are less protected then the not lost ones?
Yes they are lost for good. The currency is divisible to 8 decimal places and potentially further if there is a significant need and a code change. So the currency can adapt in its silly way.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
What is the limit on the potential divisibility that you admit exists?
The value isn't stored in the blockchain as a decimal at all. It is stored as an integer. The client just creates a decimal 8 places to the left when it displays it to you. The client can be modified to create that decimal less places to the left if desired (display in mBTC or uBTC rather than BTC), but none of that changes how the value is actually stored.
As I understand it, to change how much the value represents will require changing how the value is stored in the blockchain. Potentially you could have some miners storing their newly minted coins in the old format, and some storing them in the new format if they don't all upgrade simultaneously. The upgraded wallets would recognize the new format as valid, while those people who don't upgrade their wallets in time would see the old format as valid. This would split the blockchain into 2 types of bitcoin.
Requiring a hard fork to add extra decimal places is a significant, breaking change to the bitcoin protocol and should not be taken lightly or assumed to be part of the specification.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
I was only making that clear.
And they will never be infinitely divisible as there would have to be an infinite number of bits.
Yes they are lost for good. The currency is divisible to 8 decimal places and potentially further if there is a significant need and a code change. So the currency can adapt in its silly way.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
Bitcoins are not "infinitely divisible" as a lot of people will say though. A hard fork of the code is required to add additional decimal places. This is not a simple matter in the least.
What is the limit on the potential divisibility that you admit exists?
Jump to: