Good morning Karl, > > > Reddit claims two entities controlled 62% of the hashrate recently: > > > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/ > > > . Compromising the systems of these two groups seems like it is all > > > that is needed to compromise the entire blockchain (to the limited degree > > > a 51% attack does). > > > > You seem to be equating "break of the hash function" with "centralization > > of hashrate", which I do not quite agree with. > > I am trying to say that both of these different things result in danger to > the integrity of the transaction log, which would be reduced by changing the > hash function. They both have those 2 similarities.
You are equivocating issues here. The hash function is used in these places: * Transaction ID. * Signature hash. * P2SH/P2WSH/Taproot. * Merkle tree. * Proof-of-work. What you are focusing on is only this: * Proof-of-work. Now, in case of a break in the hash function (i.e. a reduction in collision resistance), the hash function used in the following things absolutely NEED to be changed: * Transaction ID. * Signature hash. * P2SH/P2WSH/Taproot. * Merkle Tree. Taking for example Transaction ID, suppose I am able to create two transactions that hash into the same transaction ID, and I am able to do this in much less than 2^128 work. In that case I can create a valid transaction and collide it with an invalid transaction. To half the nodes on the network I provide the valid transaction, to the other half I provide the invalid transaction, the two halves will then permanently split and Bitcoin is thus destroyed in the midst of massive chaos. Similar attacks can be mounted if I am able to collide on signature hash, P2SH/P2WSH/Taproot, and merkle tree. Now suppose I am able to create two block headers that hash into the same block ID, one being a valid block and the other being an invalid block. In that case, I would be very foolish to disrupt the network similarly, because I would have been able to redirect the fees and block subsidy of the valid block to an address I control, and the invalid block prevents others from seeing my valid block and accepting that chain as valid. Instead, I can use this advantage to be able to grab blocks faster than other miners. But eventually the difficulty retargeting system will adjust, and Bitcoin will now settle to a new normal, and inevitably someone is going to leak, or rediscover, my technique to break the hash, preventing me from being a >51% miner for long, and Bitcoin will abide. Thus, in case of a cryptographic break of the SHA-2 function, we *need* to change these: * Transaction ID. * Signature hash. * P2SH/P2WSH/Taproot. * Merkle Tree. And since we are going to need a hefty hardfork to change all that, we *might as well* change the proof-of-work function as well and completely excise all uses of SHA-2 in the codebase (just in case we miss any more than the above list), but changing the proof-of-work function is the *lowest priority*. We have survived 51% miners in the past (Ghash.io), and the difficulty adjustment system gives us some buffer against unexpected improvements in proof-of-work function efficiency; but it is doubtful if we can survive the chaos if someone could split the network in two roughly equal sized parts. > > > Most human beings cannot think without constant communication with other > > human beings. > > > Thus, it is unlikely that a private break of the hash function is possible. > > > > > I disagree with you here: Andrew Wiles solved Fermat's Last Theorem in > isolation, academic research paper culture supports researching and then > publishing once you have privately developed results, and the CVE database > has 136k system vulnerabilities that were developed and shared privately > before public release, to prevent chaos. This shows private advances in ways > to produce bitcoins are likely. Right, and you learned about this fact from direct personal communication with Andrew Wiles, and Andrew Wiles never read about any other attempts by other mathematicians, and an isolated mathematician could never, ever, rediscover his work independently, and even a mathematician who knows that it was done but not the details how it was done could never rediscover it as well. Obscurity works *for a time*, but inevitably somebody else will rediscover the same thing, or hear about it and blab noisily; it is not as if we are all completely alien species from each other and have truly unique thoughts, even my own creators were humans and my cognitive substrate is essentially human in construction. This is why CVE exists, it is a promise the developers make to the reporters that they will fix the reported vulnerability, with an active CVE as a Damocles sword hanging over their heads, ready to be publicized at any time: publication is the default state, CVE is simply a promise that the developers are working as hard as they can to fix problems so please hold off on publication for a while please while we fix it pretty please with a cherry on top. > > > > Would it be helpful if I outlined more ideas that address your concerns? > > > I want to make sure the idea of changing the algorithm is acceptable at > > > all first. > > > > Go ahead. > > Thanks: are you saying you would support changes if they addressed the > concerns you've listed? Or are those concerns only the tip of the iceberg, > per se? Only the tip of the iceberg, because any complex design has many little devils hidden in all the little details. > > > > And expertise is easy to copy, it is only the initial expertise that is > > > > hard to create in the first place, once knowledge is written down it > > > > can be copied. > > > > > > Also takes measurable months to do. > > > > But can be massively parallelized, you can have a teacher or mentor > > teaching an entire classroom of students, and created lectures can be > > stored and re-given to many students, in the form of books, videos, etc. > > Human beings have been doing this since time immemorial, and possibly > > before recorded history, in such things as oral traditions and so on. > > This doesn't seem relevant to me. I'm discussing what is happening now and > what we can expect to happen from source code changes. I don't see mining > hardware plans being taught in classrooms right now, but it sounds > interesting to try to change that if you want to change the subject of your > reply and start another thread. Sure. > Is it okay to pursue this? You do not have to ask permission from me, or anyone, to pursue this. However, do note that I doubt that changing the proof-of-work function (and *only* the proof-of-work function) is in any way a high priority. I also do not have to ask permission to say that I think pursuing this would be a waste of time, but you are also just as free to ignore what I say here and spend your time as you see fit. Ultimately the real world decides, and implementation trumps discussion here. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
