What about replacing proof of work by small bitcoin donations to predetermined addresses? This should be possible by using micropayment channels.
Potential donation addresses: atheros, bitcoin100, bitcoineater
Too centralized, and would greatly stifle adoption. People expect electronic message systems to be free, and not many would be willing to both have to pay per e-mail, and actually be able to obtain bitcoin in whatever hellhole part of the world they may be in where they would actually need Bitmessage.
Both arguments are valid and beside of this the bitcoin chain is to overloaded for this purpose.
What about destroying small Namecoin fees ( for ex 0.005 NMC/10 message) or just blocking a small amount of NMC (for ex 0.005 NMC/message) for 1/2 year which would be received back to the same address after that time ?
But that would bloat the Namecoin blockchain.
Three major challenges here:
1) broadcasting of the transaction would in many cases be just as resource intensive as sending your original message in the first place.
Not at all with micropayment channels:
https://bt.irlbtc.com/view/244656.02) even if you got the money back there would still be fees
No fees with micropayment channels besides the initial fee.
3) Creating dust ultimately means you will be spending these outputs (and paying higher fees) along with some of your other addresses and thus compromise your identity.
If you don't lock the fee but donate or destroy there is no spending thus no compromising.
I spent a long time trying to find a way to make the system 'for-pay' and not just 'burn' CPU cycles... but then I realized something critical:
1) everyone needs to propagate other peoples messages to hide their own. Therefore, everyone is already doing an even bandwidth barter to simply forward the messages along. Statistical analysis can detect leaches and cut them off.
2) the proof of work should not be required as long as the bandwidth is below a fixed limit. Just like bitcoin limits block production, bitmessage can limit bandwidth consumption on any given channel/stream. With a fixed bandwidth stream and the ability to spawn new streams as necessary to balance load, the proof of work should only become a factor in times of congestion or when there is a need to compete with spam. Of course, spam is just as good as real traffic for hiding in the crowd and as long as the channel/stream you are listening on is within spec for bandwidth usage, there is really no problem what-so-ever.
I thought the whole point was blocking spam...
