For what it is worth, I am an expert in both cryptography and economics, and I have developed a widely used cryptosystem and written many academic papers on related topics.
For what it is worth, this declaration is worth nothing in a discussion where credentials cannot be verified, and as such, any contributor that is genuinly concerned about the questions discussed in a thread would never resort to that kind of sterile attempt. Then again, reading you all over this thread showed but one thing:
You reveal no understanding of cryptographics or coding in general. Else, you could at least provide one strong example of what a positive externality resulting from hashing cryptographic problem is?
I have not, anywhere, insisted on "reusing the data processed for the hashes," but your disrespectful tone makes it hard to continue the conversation. You might consider listening to what people are saying and possibly learning from it, rather than rejecting it jingoistically.
What are positive externalities but a beneficial byproduct? What possible beneficial byproduct could result from the use of a piece of software but to reuse part of the data it has processed? Go ahead and name a single piece of software which resulting data can be used for a different, beneficial process than the one it is intended for. None comes to my mind. If your concept of "positive externalities" encompasses the recuperation and reuse of the power dissipated by the hardware, then your question isn't limited to the "design of the network", is it? If you are taking in account the power the consumption, then the problem extends to power efficiency, in which case you need to be more rigorous. Or wait, next you're gonna tell me this isn't about mining anymore, right?
The question is one about how to design the network.
If I had not understood this question, why would I have bothered explaining every step that results in the existence of mining is necessary for this system to be sound? My point, that you obviously missed, is that the design so far works, and that there are no superficial elements in this design. And on this regard, you provide me with another proof that you have no idea what you are talking about:
The particular choice -- as the developer of the network, not a client of it! -- is arbitrary, or at least arbitrary within some constrained range. As a very simple example, imagine that one candidate hash algorithm favors hardware produced by a violent, morally repugnant regime and another favors hardware produced by a regime you want to support; why would you -- again, as the developer of the system, not a user of it! -- choose the former over the latter?
No choices in this process is arbitrary. Your pretense that developer choices are somehow arbitrary shows that you think Bitcoin is just a crapshoot. Your pretended expertize level in economics would indicate that you know the conditions needed for a commodity to be a sound currency. Your expertize in cryptography implies you know the list of steps necessary to secure a decentralized, p2p network that is continuously producing fresh data from within while blocking outside injections.
If you had those pretended skills you would know that there a predefined set of NECESSARY steps in order for such network to function, and the only remotely arbitrary development decision made would be in regards of the seeding constants and hashing algorithm. And even those are established with efficiency in mind. In what world can a voluntary, open source, p2p project afford to randomly choose its mechanics and expect to be adopted?
Once again, your point about the hardware favoring speaks volume about your understanding of Bitcoins. These kind of externalities are absurd. There is a unique nature to the calculation that has to be processed, that's the whole point of cryptography. You can't just go around changing it without hurting its ability to secure your data, nor can you choose something weaker. But hell, you're an expert in cryptography, you should know that shouldn't you?
Your pretense that externalities resulting from the very fabric of the Bitcoin system should be weighted in the design of said system shows that you think the problematic and conditions the Bitcoin project is trying to address are indeed loose and replaceable at a whim. Again, if you were truly an expert cryptographer and economist, you would know better, or you would present us with the better alternative.
Nobody is suggesting that Bitcoin, in any form similar to its current one, could exist without the need for mining.
If you are discussing design, you are discussing form. Why can't you wrap your mind around the fact that the different parts of Bitcoin form a whole and that changing one would require to compensate with another part or add a whole new concept to it unless one of the foundation of the system is to be compromised, which isn't an option.
If you're interested, please reconsider the point I made earlier about the broad possible positive externalities from GPU mining.
You made no such valid points. A bunch of 'ifs' thrown in by someone uneducated to the matter do not consist in a valid point. I could just as well walk to a car manufacturer and ask him why he isn't building antigrav vehicules in order to save friction wastes and tires. He'd have the same reaction as I am having with you. Do you really think that if such encryption algorithm that emphasis general computing unit architecture (cpu) against parallel, raw power processing power processors (gpu), that the developers of Bitcoin would have made a point of choosing the GPU one for the single purpose of limiting access to a
P2P open source project?Your disrespect is coming from ignorance of the economic point I'm making
Your economic point is the result of your ignorance. What do you expect me to do, praise you for it?
You might consider listening to what people are saying and possibly learning from it, rather than rejecting it jingoistically.
Says the troll... Also a jingoist provides no rationale to his rejection. I gave you a proper counter argument. l2troll.