> The first issue can be fixed by upping the proof of work required to send a message, although this will not stop a determined attacker who has lots of cycles to throw at the problem.
Could you implement something like IRC's "flood prevention" in a proof-of-work based consensus algorithm -- so sending messages closer together costs prohibitively more?
The network could require, say, the work in a transaction to be proportional to ∑(1/message dt) for the messages signed by the transaction.
> Could you implement something like IRC's "flood prevention" in a proof-of-work based consensus algorithm -- so sending messages closer together costs prohibitively more?
This seems easily circumvented by creating lots of identities. Though maybe creating an identity could be costly?
Could you implement something like IRC's "flood prevention" in a proof-of-work based consensus algorithm -- so sending messages closer together costs prohibitively more?
The network could require, say, the work in a transaction to be proportional to ∑(1/message dt) for the messages signed by the transaction.