 Show Posts
|
|
Pages: [1]
|
2. Perhaps there are other very valuable uses, but Bitcoin does have half a trillion market cap. You could for example place a gigantic leveraged short on BTCUSD just before publishing your proof that SHA-256 is broken. Or you could rebuild the chain unchanged except for reassigning the Satoshi wallet to yourself.
The latter is not possible. As for the former, if you were to approach NSA or related organizations directly, you would probably have a guaranteed payout rather than to attack the chain and risk being labelled a criminal and getting yourself investigated. You'd probably have much better things to do if you could discover a feasible way to generate collisions anyways (at low costs of course). Why would the latter not be possible? Assuming that I can mine essentially for free, I can just re-create a version of the full blockchain, keeping all transactions identical to the original, except for the destination address in some coinbase transactions (those which are attributed to Satoshi in the original chain). Not sure what would prevent me from doing this. Why would all of cryptography be dead if this was possible for a specific hash function?
Because historically well studied algorithms has never been broken with very little computational power/efforts. If you were to prove that one-way function don't exist, ie. P=NP, then any other cryptography functions would also be dead. Ok, but breaking SHA-256 would not imply that one-way functions don't exist (and neither would breaking ten or a hundred different hash functions). Anyway, it still seems to me that there is a lot (too much) riding on the fact that SHA-256 will not be broken, or if so, that it would be broken in a slow, and visible fashion. I am quite surprised by this, seeing as Bitcoin's main tenet is immutability guaranteed by PoW, which falls apart in case of a break. Admittedly I don't know anything about cryptography, but the single point of failure strikes me as strange. |
|
|
|
There is no such thing as producing a valid block hash with little computations, that is not within our reach for the near future. If that happens, you can be sure that cryptography is dead.
Why would all of cryptography be dead if this was possible for a specific hash function? |
|
|
|
Also defeating (not weaken) SHA256 or any cryptography like that is quite valuable, certainly not valuable enough to use on Bitcoin.
1. Would it be useful in other contexts to be able to find "small enough" hashes? 2. Perhaps there are other very valuable uses, but Bitcoin does have half a trillion market cap. You could for example place a gigantic leveraged short on BTCUSD just before publishing your proof that SHA-256 is broken. Or you could rebuild the chain unchanged except for reassigning the Satoshi wallet to yourself. |
|
|
|
As my friend always said: "we can do everything, the question is: should we?". And here you have the same situation: if you really want to add some hash function, then of course you can. You always can protect things by more restrictive rules, and make it a soft-fork or no-fork. You can start with no-fork, so your node will keep everything and will warn you that you have a block where SHA-256 is broken.
Technically, all you need is re-hashing everything with your hash function, and then add commitments for that. You can even hide your commitments in r-values of your signatures, then they still will be hashed by SHA-256, and you can always un-wrap them later, and then easily show that you have some additional Proof of Work protection that can be deployed immediately. Because it will give you no coins, there will be no problem with "mining without other people", as you will only hash some old blocks.
Thanks! Most of your post is going straight over my head, so I will invest in self-study to try and understand it. But from what I gather in your no-fork proposal, you are saying that I could be (privately) building a parallel chain with alternative hash function, and accumulating some Proof-of-Work in that, which could be used as a bootstrap if a sudden break of SHA-256 appeared, correct? If so, I guess that is an interesting point to consider, although it would basically mean that this work would go unrewarded by the network, and hence likely the accumulated PoW could only be very small, and would not last long vs. an adversary who had the means to break SHA-256. |
|
|
|
First of all it depends on what "broken" means. For example we call SHA1 broken and you can't reverse it or find a collision if you can't control the message, also it is still used in git for integrity of commits without any problem.
Secondly, I'd say if something is "broken" it has to be replaced instead of creating a band-aid where it still is used alongside something else. Adding the secondary hash requires a hard fork so why not just replace it?
Good point, I did not define "broken" with any degree of precision. In this context I would call SHA-256 broken if someone is able to find valid block hashes with a much decreased amount of work compared to brute force. If I understand correctly from my Wikipedia readings, breaking pre-image resistance would entail the ability to create a block for any desired hash value, whereas what I refer to is a weaker condition, i.e. finding a block whose hash value is small enough. Concerning the point of replacing vs. creating a band-aid. I am thinking of scenarios in which it is not apparent that someone has managed to "break" the algo, until it is revealed in a catastrophic fashion when a longer chain is published as an adversarial attack on the Bitcoin network (resulting in sudden destruction of trust and collapse of price), at which point it may be too late to operate a replacement. |
|
|
|
The crux idea is about pre-image resistance of SHA256 but a bigger issue would be a collision resistance, which is weaker than the pre-image.
Any breaks in a pre-image resistance is incremental and slow over time it is simply too difficult and unrealistic to expect the entire algorithm to be broken overnight. In addition, because we require the inputs to be a specific format and also ensures that it is valid at the current state, it wouldn't be a stretch to think that the pre-image wouldn't necessarily result in a valid Bitcoin block.
Having alternate PoW schemes would provide no additional tangible security benefits while making it more complicated.
Thank you, I will now spend a few days learning the concepts required to understand your response  |
|
|
|
Hmm... Doesn't the danger remain?
Alright, so let's say we used SHA-256 for even blocks and Keccak-256 for odd blocks. Now let's assume SHA-256 is broken. Now all the even blocks can be generated at will, without (the same) work. The attacker can still use half of his computational power to reverse transactions. In fact, he can still cheat the entire bitcoin economy by solving blocks within seconds, censoring/emptying the block's content.
Edit: He can actually reverse transactions with much less hashrate than half of it. If he's broken SHA-256, he can create one block whose work equals thousands'.
Yes true, there doesn't seem to be any possible immunity from someone using a break for adding blocks very profitably. However, they could only add *new* transactions, and not rewrite the entire blockchain from genesis to suit their fancy. |
|
|
|
|
Dear Bitcointalkers,
I apologize if this question has been dealt with, but I haven't found a good answer to it:
Why is it not a terrible idea to rely on a single hash function (i.e. SHA256)?
Supposing that SHA256 was broken, wouldn't the entire accumulated Proof-of-Work become irrelevant all at once? And thus, wouldn't the entire transaction history be at immediate risk of being replaced by a longer chain?
I am sure there must be a good reason, but why not use at least two hash functions? Say, using function 1 for even numbered blocks, and function 2 for odd numbered blocks. That way, if function 1 is broken, it can be switched out with a better one, and during this time the transaction history is still protected by the accumulated PoW of function 2. I can see a drawback with this scheme: specialized hardware for function 1 may be utilized only 50% of the time, likewise for function 2. Perhaps a scheme in which two chains are constructed in parallel, one chain per function, but 'braided' together (a new block referring to the latest block of each chain) could avoid this problem.
I can certainly see potential issues in either case, it would complicate the design, and KISS is a good principle in general. However, what of the fundamental danger? Am I missing something? (Probably).
Humbly,
LH
|
|
|
|
|
