Show HN: Toy Haskell blockchain with variable hash functions for ASIC resistance | Hacker News Reader

Show HN: Toy Haskell blockchain with variable hash functions for ASIC resistance

github.com

15 pointspgustafs7 comments

If both mining and non-mining nodes must manually (subjectively) adjust their criteria for block acceptance, what impetus is there for the network to stabilize to any sort of objective state?

Thanks for commenting. First let me say that with current blockchains, we achieve "objective state" at the cost of centralized control of the algorithm by some core group of developers. This results in perverse incentives to maintain the status quo (c.f. bitcoin transaction cost problems).

Getting back to your question, I have no idea if the scaling functions will stabilize on a singular chain or not. However, I think it would be a Pareto improvement over the status quo. Indeed, you could embed BTC and ETH into DCC (with the proviso that all users must use the core-developer-chosen hash functions and scaling functions), and both chains could live side-by-side.

As far as I understand there is no such thing like ASIC resistance. Whenever there is an incentive people will build ASICs. It doesn’t matter how complicated your algorithm is.

Right, but this approach solves that by not defining any hashing algorithm at all. Every block includes its own hash algorithm source code. Every node decides for itself whether to accept the hash algorithm and how much to value it. If people suspect an algorithm is getting ASIC'd, they can devalue it (if they want -- maybe the majority of nodes want ASICs for some reason, and that's fine too). The point is to let the users to choose the algorithm, not a core group of developers.

1) If every block includes source code for an arbitrary hashing algorithm, do you expect arbitrary nodes to run arbitrary code to synchronise with your block? How do you know if some block provider's hashing algorithm terminates? How does your blockchain become trustless if hashing involves arbitrary code execution?

2) An essential property of hashing algorithm is uniform distribution. Future block hashes depend on past block hashes. In PoW this implies compute difficulty scales dynamically. If a block provider gets to choose their hashing algorithm arbitrarily, they could pick a non-uniform hashing algorithm that is easy for themselves and hard for others. In PoS this often affects who gets picked as the next block provider; having control over the hashing function in either case means you can pick yourself again.

If your claim is to let market forces pick the most trusted hashing algorithms, why not just settle on a fixed-but-extensible list of hashing algorithms that are known to work well today?

Making governance a part of the protocol is all the hype.

But there has to exist a protocol with boundaries.

Otherwise, your blockchain is just the internet.

You can download my block now.

1) A node _could_ run arbitrary code, but unless it trusts the code's provenance then it should use a white-list as you mention.

> why not just settle on a fixed-but-extensible list of hashing algorithms that are known to work well today?"

Sure, that's what a whitelist will be, but with one major difference: each node gets to pick its own whitelist, there's no built-in centralization via the "one true source code."

2) Yes, miners will choose hashing algorithms that are easy for themselves and hard for others, but the nodes get to value each block from their own perspective. If they think a miner is using a weird hash function, they can penalize it or just blacklist the function.

Check out the RandomX PoW algorithm for Monero. To get around the ASIC resistance issue, they instead targeted a particular component (the CPU) and designed the algorithm around it.

It works really well, FPGAs and ASICs seem to have been stopped in their tracks.

Reply on news.ycombinator.com