Pages:
Author

Topic: Possible impacts of ASIC mining and hypothetical scenarios - page 2. (Read 3442 times)

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.
Then it should not be a variation, but a completely different hashing function.
That probably doesn't come free. Since it is impossible to know in advance just how SHA256 will be broken (if it ever is), it is also probably not worth any cost to try to add a complete alternative to it, since it could just as well also be vulnerable.
LOL - do some reading about hashing algorithms please Smiley
hero member
Activity: 756
Merit: 501
There is more to Bitcoin than bitcoins.
  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.
Then it should not be a variation, but a completely different hashing function.
That probably doesn't come free. Since it is impossible to know in advance just how SHA256 will be broken (if it ever is), it is also probably not worth any cost to try to add a complete alternative to it, since it could just as well also be vulnerable.

Ok, I think I get it now. I just wasted my time with this whole discussion. Everyone pretty much agrees, even Luke-Jr - but he can't stop there but goes on meaningless and confused tangents. I'm out of here.

legendary
Activity: 2576
Merit: 1186
  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.
Then it should not be a variation, but a completely different hashing function.
That probably doesn't come free. Since it is impossible to know in advance just how SHA256 will be broken (if it ever is), it is also probably not worth any cost to try to add a complete alternative to it, since it could just as well also be vulnerable.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.

Then it should not be a variation, but a completely different hashing function.

As I said Smiley
...
Yes that is the risk with using ASIC hardware - if sha256 is broken, then it will need to be replaced and all ASIC hardware at the time will become useless.
Damn shame about that hey.

The only reasonable solution to this would be to plan ahead for the failure of sha256 and decide in advance what will be used after sha256 fails.
The word 'secret' doesn't come in there in any way for any reason at all.

That solution, however, would require foresight and planning by the bitcoin devs ... which is not readily apparent in most of what they do ... and is completely missing in most of what you do Luke-jr.
...
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
Bitcoin protocol changes require support from the economic majority, not the miner majority. That is, hashrates are irrelevant and the only thing that matters is "who people want to pay".
...
No. it requires both.

Yes if no one uses bitcoin, then there will be little future for it.

However, if the blockchain doesn't get securely verified - no one can use it Tongue
donator
Activity: 994
Merit: 1000
  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.

Then it should not be a variation, but a completely different hashing function.
legendary
Activity: 2576
Merit: 1186
The thinking goes that if the algorythm needed to be changed to one that ASICs cant use and they are the majority of the network then they could vote not to change the algo simply be owning the majority of the hashing power.
We would get stuck on a broken/substandard algo because of it.
  • There is not (AFAIK) any reasonable excuse to lock out ASICs in general.
  • Bitcoin protocol changes require support from the economic majority, not the miner majority. That is, hashrates are irrelevant and the only thing that matters is "who people want to pay".
  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
What does "who people want to pay". Can you define or explain this statement?
For example, if you want to pay BitVOIP for some nice VoIP services*, the only thing that matters for that transaction is what Bitcoin protocol they are willing to accept. Inevitably, for Bitcoin to work at any scale, it is the merchants people want to do business with the most who matter.

* No, I don't know anything about BitVOIP or anything like that. I just quickly peeked at the Trade wiki page for a quick example I'm not biased on.

  • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
I'm assuming that if SHA256 gets broken, any backup variation of it automatically is also broken. The algorithm might need to change anyway, but it would break all ASICs.
donator
Activity: 994
Merit: 1000
    • Bitcoin protocol changes require support from the economic majority, not the miner majority. That is, hashrates are irrelevant and the only thing that matters is "who people want to pay".
    As far as I understand it this is correct. But turning the mining community against each other would probably result in a hard fork, where the economy gets splits into two coexisting realities: In one chain my coins might be spent, in the other one they are not.

    • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
    Why would you exclude a broken SHA256 scenario? It's a perfectly valid reason to have a backup hashing algo in case the first one breaks.
    hero member
    Activity: 988
    Merit: 1000
    The thinking goes that if the algorythm needed to be changed to one that ASICs cant use and they are the majority of the network then they could vote not to change the algo simply be owning the majority of the hashing power.
    We would get stuck on a broken/substandard algo because of it.
    • There is not (AFAIK) any reasonable excuse to lock out ASICs in general.
    • Bitcoin protocol changes require support from the economic majority, not the miner majority. That is, hashrates are irrelevant and the only thing that matters is "who people want to pay".
    • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).

    What does "who people want to pay" mean. Can you define or explain this statement specifically?
    legendary
    Activity: 2576
    Merit: 1186
    The thinking goes that if the algorythm needed to be changed to one that ASICs cant use and they are the majority of the network then they could vote not to change the algo simply be owning the majority of the hashing power.
    We would get stuck on a broken/substandard algo because of it.
    • There is not (AFAIK) any reasonable excuse to lock out ASICs in general.
    • Bitcoin protocol changes require support from the economic majority, not the miner majority. That is, hashrates are irrelevant and the only thing that matters is "who people want to pay".
    • The backup algorithms would only be useful in a scenario where SHA256 is not itself broken, but a single miner with the "cannot easily change algorithm" weakness is doing something harmful (such as forcing the network to trust them).
    hero member
    Activity: 686
    Merit: 500
    Wat
    The thinking goes that if the algorythm needed to be changed to one that ASICs cant use and they are the majority of the network then they could vote not to change the algo simply be owning the majority of the hashing power.
    We would get stuck on a broken/substandard algo because of it.
    hero member
    Activity: 756
    Merit: 501
    There is more to Bitcoin than bitcoins.
    Since consumer ASICs would be online the new algorithm(s) first (as in, immediately), it won't be so simple to 51% attack at that point. If you could, however, I'm not sure any way for Bitcoin to ever really recover - any reason to justify switching to new algorithm(s) is extreme enough that it would never make sense to switch back by force.

    I don't understand all the fuss about "secret" backup hashing algorithms (in the ASICMINER thread), and I don't see a problem with implementing a backup algorithm in hard-wired miners (ASICs). For years we've been mining with configurable hardware (CPUs, GPUs, FPGAs) that has practically infinite number of secret algorithms "embedded" - simply reprogramming the devices to a hashing algo of your choice would do. Why is the thought of hard-wired backup hashing algorithm in ASICs so scary?
    donator
    Activity: 994
    Merit: 1000
    This thread is a spin-off from:
    https://bitcointalksearch.org/topic/m.1154935

    Please use it to discuss the implications of the emerging field of ASIC mining and the role of ASIC hardware companies. Mentioned topics are interest of conflict between using the chips and selling them, secret algorithms and back-doors.

    Enjoy!
    Pages:
    Jump to: