Updated Middleware and Dapp Project Ideas (markdown)

Middleware-and-Dapp-Project-Ideas.md

@@ -98,4 +98,15 @@ Some developer resources that can help with this include:
 * http://eid.eesti.ee/index.php/Authenticating_in_web_applications
 * https://e-estonia.com/e-residents/for-developers/
 * https://sk.ee/en/services/testcard/
-* http://id.ee/index.php?id=30469
+* http://id.ee/index.php?id=30469
+
+### Security Deposit-backed Conditional Hashcash
+
+The key piece of technology that later spawned the advent of blockchains starting with Bitcoin, proof of work, was originally devised for quite a different application: email spam prevention. In order to send an email that would be viewed by recipients' email interfaces, users would need to complete a certain amount of computational work on their computers that could quickly be verified. This would impose a small cost in electricity and CPU power to sending an email (say, $0.01) that would in theory be no problem for ordinary messages, but would be so expensive as to make spam no longer worth it. In practice, this idea never succeeded, in large part because people did not want to pay for their email and because it would only lead to spammers paying more in order to send more well-crafted emails to fewer parties, which would be more likely to receive attention because users think that they already passed the proof of work filter.
+
+Here, I propose a proof of stake twist on the algorithm that would solve this problem. The key insight is that instead of making the sender _always_ pay the cost, we make the cost a security deposit, and the recipient has the right, only if they wish, to destroy the security deposit at no benefit to themselves (in an actual implementation, "destroy" will hopefully mean something like "donate to protocol developers"). Ordinary "useful" messages would get through unscathed, and spam would be punished in proportion to the percentage of people that find it scammy. The conditional nature of the protocol can theoretically allow the deposits to be increased much higher than the cost of proof of work; deposits of $1 or even higher are quite reasonable.
+
+There are two possible extensions to this idea:
+
+1. Use techniques similar to [anti-pre-revelation games](https://blog.ethereum.org/2015/08/28/on-anti-pre-revelation-games/#comment-2230211912) (or possibly other techniques) to allow users to destroy other users' security deposits (either probabilistically or fully) without the victim knowing who did it. This allows the mechanism to be used more effectively in intra-organizational and social situations, so that you can punish people for being annoying without extra-protocol repercussions. Aside from information-theoretic strategies, there may be routes to doing this using Chaumian blinding schemes, cryptographic accumulators and/or zk-SNARK proofs; the goal to target would be in a scenario with one sender and N recipients, with the sender having a deposit of $NX, giving each recipient the right to destroy $X exactly once without revealing which one of the N they are; the main challenge is the sender gleaning this information by simulating the process of each single recipient destroying their deposit and seeing which one(s) fail, and so private information on the recipients' part and perhaps even an interactive protocol is required.
+2. Have different levels of deposits, where higher levels of deposits can be used to signal more importance/urgency in the interface; at the highest levels, one could imagine a deposit of $500 leading to one's phone ringing maximally loudly whereas a deposit of $0.1 would only lead to an email appearing next time one opens one's mailbox.