Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not sure if this is how it works, but it should be possible to avoid the "re-roll" problem:

Each node picks a random value, and publishes the hash of it to the blockchain, then, when the network has reached finality on what all the hashes are, the nodes publish the random values themselves, and the network takes the XOR of all of them.



Nodes can simply choose not to publish their value if the result is unfavorable to them, and this tanks the whole procedure. This isn’t a problem unique to your scheme; they all suffer from things like this.


If a node publicly commits to providing a random value, but then doesn't follow the protocol by actually revealing it, then that node's stake can be distributed to the honest nodes and the procedure started again.

The protocol could even increase the stake needed to be one of these random value providing nodes, every time such a failure occurred, to make such an attack more and more expensive.


Then the node that had their stake forfeited simply allocates their resources to a competing blockchain where that didn’t happen.


I think you're suggesting that a rogue node disobeying the protocol creates a chain split, allowing the node to just orphan the chain where they got caught.

That's probably true in general, but I was assuming that the random number generation would be decoupled from the process of actually building the consensus.

As long as the loss of stake can happen and be finalised as part of the transaction history, then eventually the attackers will run out of money and the random number generation process can catch up and start generating more entropy.


Usually a double spend attacks on PoS might need a collusion reaching upwards of 66%. That seems fairly improbable to me.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: