Good morning Karl,

> > > Reddit claims two entities controlled 62% of the hashrate recently: 
> > >
> > >  .  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 
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 
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 (, 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 
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.


> 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.


bitcoin-dev mailing list

Reply via email to