This also illustrates that if we had made this change earlier, they would not have designed the system to create unspendable public keys in the first place.

They have no financial incentive to deviate from the original design. And once such a system goes live, assuming it has any uptake, their engineers will be busy with all sorts of more urgent things.

Any typical corporate CTO would look at this situation and say: hey look, there's a bunch of drama here, let's assume the brigaders win and the OP_RETURN limit stays in place. So let's just stick to the original design. We're not price sensitive, so it's the safest option. It also saves us a bunch of engineering hours. Also, it protects our engineers from being harassed.

Finally, this also goes to show that we really need to make progress on Utreexo, because UTXO set growth is a sitting duck. All we can do is ask people nicely to not grow it needlessly.

Reply to this note

Please Login to reply.

Discussion

What’s the status on Utreexo these days? It seemed like a cool project but I never see any mention of it these days.

Looks like there's a beta? https://bitcoinops.org/en/topics/utreexo/

Supposed to be a spec update any day now maybe?

Yes :)

We have specs for the accumulator and basic p2p stuff. Working on cache rn. We should have something public soon.

We also have:

A Golang lib at https://github.com/utreexo/utreexo

A rust lib at https://github.com/mit-dci/rustreexo

And two implementations of the bitcoin consensus that uses utreexo:

Utreexod: https://github.com/utreexo/utreexo

Floresta: https://github.com/vinteumorg/floresta