added a few crypto ideas

README.md

@@ -271,26 +271,30 @@ If you want to be added to the list of people that have completed a project, req
 
 - **Truly random NFT drops** The problem is that you can predict randomness and mint the best NFTs by simulating the chain. Some solutions [exist](https://www.paradigm.xyz/2021/10/a-guide-to-designing-effective-nft-launches#phase-4-metadata-reveal). However, a better way to do this is, on mint, you generate a 24+ second (2+ block) VRF seeded by the previous blockhash. Minters pay gas upfront for anyone to send a second reveal transaction. MEV searchers calculate the VDF and send the result to the chain for that gas money + a small bonus, in return for updating the NFT values on chain first. More description at this hackmd: https://hackmd.io/xgR6mtWyQYC_SZYtZTdoDA .
 - **Futarchy On-Chain**: Build the first prediction markets for governance, like [MerkleDao](http://www.ralphmerkle.com/papers/DAOdemocracyDraft.pdf)'s plan. Add features like also betting reputation points proportional to money, where higher reputation leads to higher investment limits, which will help institutional players to be long-term aligned with the project instead of financial manipulators. This will also help elect legislators who consistently have high reputation, meaning they accurately predict long term impact of legislation on people.
-- [Not my ideas, but still excellent] The four ideas at the bottom of https://bitcoinmirror.org/ have not been created yet and are technically feasible as an intermediate-level project, and could be the first trustless applications of Bitcoin on Ethereum! They haven't been built yet because this was only possible a few months ago and isn't marketed very widely. Would likely quality for Gitcoin/Eth Uni grant for much more funding. WBTC uses a centralized minting system with a 10B$ market cap and can be replaced by this.
+- **Bitcoin on Chain**: [Not my ideas, but still excellent] The four ideas at the bottom of https://bitcoinmirror.org/ have not been created yet and are technically feasible as an intermediate-level project, and could be the first trustless applications of Bitcoin on Ethereum! They haven't been built yet because this was only possible a few months ago and isn't marketed very widely. Would likely quality for Gitcoin/Eth Uni grant for much more funding. WBTC uses a centralized minting system with a 10B$ market cap and can be replaced by this. Can do as well with [ZK proof of BTC headers](https://devfolio.co/projects/bls-pil-865f), which will be substantially cheaper.
 - Run automated static analysis and formal verification tools on all existing and new smart contracts: I have a more [fleshed-out proposal here](https://docs.google.com/document/d/1D9extlCKq0qbroTjv6FD-JHstpAulRylVM0hpOuZsyM/edit). Can add bespoke checks like seeing if code calls unsafe oracles like [keep3rV2Feed.current](https://kyrianalex.substack.com/p/the-inverse-finance-hack?s=r). Can also use more recent powerful tools like [Veridise](https://veridise.com/), which likely haven't been run very widely.
-- RISC0 verifier in Solidity. Due to gas costs, the team building verifiable RISC execution has only verifiers for non-EVM chains. It should be easy to convert this verifier generator to use solidity syntax instead and run on an L2, letting you do stuff like verifiable Pytorch execution on chain. Code is even OSS as of Q2 2022.
-- An L2 whose only feature is account abstraction on top of the Ethereum L1.
+- **RISC0 verifier in Solidity** Due to gas costs, the team building verifiable RISC execution has only verifiers for non-EVM chains. It should be easy to convert this verifier generator to use solidity syntax instead and run on an L2, letting you do stuff like verifiable Pytorch execution on chain. Code is even OSS as of Q2 2022. Idk if it exists yet, it might already.
+- **AA L2**: An L2 whose only feature is account abstraction on top of the Ethereum L1.
 - A Vitalik-style blog post on accumulators. Explaining the difference between RSA accumulator, merkle trees, hashed prefix tries, etc along with time and space complexity for set inclusion and set exclusion, with and without ZK. Might also inspire a new idea for a ZK friendly accumulator (although Merkle trees are already quite efficient).
-  - Edit: Vitalik put up a similar one, [this post](https://ethresear.ch/t/arithmetic-hash-based-alternatives-to-kzg-for-proto-danksharding-eip-4844/13863) would be a great model for it.
+  - Edit: Vitalik has now put up a similar one, [this post](https://ethresear.ch/t/arithmetic-hash-based-alternatives-to-kzg-for-proto-danksharding-eip-4844/13863) would be a great model for it.
 - **ZK Mao On Chain**: Put the [Mao card game](<https://en.wikipedia.org/wiki/Mao_(card_game)>) on chain, with a rule like any new rule must be < 20 characters of code. This game would be perfect to demo both programmability of blockchains and provide a fun twist to one of my favorite card games. You can use ZK-SNARKed execution of commited-to code in order to prove consistent execution of your code, with something like Risc0 or a zkEVM, and use a zk verifier as a "commitment" to the code. Can also be off-chain, since is only a fun SNARK demo.
 - **Pay for L1 Txs With Any Coin**: Gas station network v2 mainnet frontend, even for simple ERC20 sends. Would allow people to send transactions to the chain without any eth in their wallet; there are no live mainnet frontends right now. This is being vaguely pushed for with account abstraction, but you can also run MEV-incentivized relayers to do this (see [stealthdrop](https://github.com/stealthdrop/stealthdrop) or [surrogeth](https://github.com/lsankar4033/surrogeth) without centralized relayers).
-- Allow circom to do higher-degree gates via automatically decomposing it (i.e. z = x _ x _ x is automatically parsed as y = x _ x and z = y _ x in the backend, where \_ can be + or \*)
-- A very simple browser extension that detects if a website that claims to be ZK is sending any information to a server, or is clientside only
+- **Higher Degree Gates in Circom**: Allow circom to do higher-degree gates via automatically decomposing it (i.e. z = x _ x _ x is automatically parsed as y = x _ x and z = y _ x in the backend, where \_ can be + or \*)
+- **Is this website actually clientside ZK?**: A very simple browser extension that detects if a website that claims to be ZK is sending any information to a server, or is clientside only. One version would spoof all outgoing requests to be from an empty server, so that you can still do things like download zkeys, but you can't send personal data.
+  - Partially DONE. First half done by Monia, not open source yet.
 - Create a GitHub org for non-censored DeFi frontends, as suggested [here](https://twitter.com/smsunarto/status/1560897907405901824). Host them under an uncensorable domain as well.
 - A stablecoin for basket-of-goods price index, which adjusts the interest rates of its vaults to create this peg i.e. (us dollar / inflation). It maintains surplus in the Treasury by issuing gas options, allowing a simple on chain derivates framework to generate actual income in other cryptocurrencies, allowing it to deviate from the dollar.
-- A developer-friendly ERC721 on testnets i.e. Goerli, that lets you send Eth to the contract and will auto-mint you back 100 dev NFTs to experiment with, so super easy to test with during hackathons
+- **Dev NFTs on Goerli**: A developer-friendly ERC721 on testnets i.e. Goerli, that lets you send Eth to the contract and will auto-mint you back 100 dev NFTs to experiment with, so super easy to test with during hackathons
 - A few fun projects related to ZK identity: if you have any experience at any level, [dm me](https://twitter.com/yush_g) for ideas catered to your level :)
 - Build a full NFT marketplace that uses optimal auction theory instead of first price auctions. You should use our [on chain blind Vickrey auction contracts](https://github.com/Philogy/create2-vickrey-contracts), which you can understand via our [blog post](https://blog.aayushg.com/posts/vickrey).
-- Safe tornado cash, where users can use it but hackers/North Korea can't. To be able to use tornado.cash, you have to wait a significant number of blocks between deposits and withdraws. You know the leaves being added to the Merkle tree, and can trace which are linked to stolen deposits. You can create a second blocklist of "banned leaves", which allows you to block withdraws of nullifier leaves, meaning hackers can deposit but not withdraw.
-  - DONE: This was [built](https://github.com/hananbeer/tornado-core-blacklist) and a bounty was awarded!
+- **Safe tornado cash**: Where users can use it, and prove non-membership in blocked lists of addresses. Such a list could be i.e. money linked to hacks/North Korea or something. Currently, to be able to use tornado.cash, you have to wait a significant number of blocks between deposits and withdraws. You know the leaves being added to the Merkle tree, and can trace which are linked to stolen deposits. You can create a second blocklist of "banned leaves", which allows you to block withdraws of nullifier leaves, meaning hackers can deposit but not withdraw.
+  - Partially DONE: This was [built](https://github.com/hananbeer/tornado-core-blacklist) and a bounty was awarded! Ameen built a similar centralized version of such a list, but permissionless list adding I think is key. Note that this bounty is **still open with the same reward** for the more general construction.
   - Note that this can be made more general. Any entity (the government, rektfinance.eth, or you) can create a curated list of "bad addresses". Any withdrawer can prove non-inclusion in any set of lists they think others would care about when they withdraw (via proof of inclusions in the complement).
-- Make a PR to [Gitcoin](https://github.com/gitcoinco) to order comment section by comments first, then all contributions. Also recalculate the matching amount shown on the frontend to be adjusted to project future donations based on the average distribution, so that the matching amount is more accurate.
+- **Better Gitcoin Comments**: Make a PR to [Gitcoin](https://github.com/gitcoinco) to order comment section by comments first, then all contributions. Also recalculate the matching amount shown on the frontend to be adjusted to project future donations based on the average distribution, so that the matching amount is more accurate.
 - Patch ethers.js to add a function that calculates the transaction hash, without having to send the transaction. keccak256 on the signed transaction doesn't work, and there is no built in function to do so even though it is possible and one can write their own helper function (see the [description here](https://github.com/Divide-By-0/ideas-for-projects-people-would-use/issues/12)).
+- **ZK Soft KYC**: A circuit on the simpler end, with a proof-of-membership to Gitcoin Alpha Passport. When you send a donation on Gitcoin, you prove you own an account (i.e. via a signature match into a merkle tree heyanon style) to prove a matching % (or soft KYC-ability), without revealing who you are. You can use an Axiom state root of the on chain Gitcoin passport to ensure up-to-dateness with the chain. Note that this trusts Gitcoin to verify your matching in a centralized manner.
+- **Witness Encypted Tinder**: Implement Protocol Labs’ [new construction](https://drive.google.com/file/d/1GEfm77BfKRz1Xzby89era8KOgalqn00L/view) or [this non-succinct one](https://eprint.iacr.org/2021/1423.pdf), and then build a proof of concept Tinder where everyone selects 5 people they want to match with, and are only matched if people select each other. First, everyone commits to, say, 5 people they are most interested in. Those 5 people should get only notified if they also commit to that person as one of their chosen 5 as well. So, after everyone commits, those commitments are used in the FC-WE scheme that everyone then runs, to publish a message only to their 5 folks only if they also had valid commitments (i.e. with them in it, while keeping it anonymous, which may not be possible with groth16). Finally, in the reveal stage, everyone attempts to read every message and can only end up reading the ones that work for them. You can do this with a pairwise Socialist Millionaire or Yao’s Garbled Circuits, but this requires more back and forth stages.
+- **On Chain Proof Aggregator**: To get L1-level censorship resistance and data availability of ZK circuits is expensive, but there is a way to make this cheaper at the cost of a delay. Imagine building a contract called DelayedBatchGroth16Verify. Let's say, for instance, that I am withdrawing from Torando Cash. Then, I have two phases. One, I send my proof + public parameters to the DelayedBatchGroth16Verify contract along with a small amount of eth (say, calldata cost of that many parameters + a tip). That contract, say ~12 hours, collects all the proofs sent to it. It then uses Snarkpack or analogous (via additivity of KZG commitments) to verify all of the proofs at once for 300K gas. Anyone can batch verify and send as soon as the size of the tips in the contract exceeds the cost of a single KZG verification. Once such a verify passes, it stores say hash(proof, public) in a "passed proofs" mapping. Thus, once someone has verified for me cheaper than a single verify, I can send a second transaction to tornado cash that just checks that the proof + public parameters have been part of a past batch verification (for instance, by hashing all of them and checking that it is a valid mapping key mapping to a 1), and then continues with the rest of the logic. While long-term we expect to not need this due to exceedingly cheapening L2 costs, it will be useful for the next 2 years while we do not have robust ZK L2-to-L2 bridges or audited ZK rollups.
 - ~~ed25519 encryption in a ZK SNARK (using circom). Metamask's [encrypt](https://github.com/MetaMask/eth-sig-util/blob/main/src/encryption.ts#L94) function on chain would be new, and save people from having to use MIMC as an encryption function.~~
   - Edit: This is [done](https://ethresear.ch/t/verify-ed25519-signatures-cheaply-on-eth-using-zk-snarks/13139).
 - ~~DNS record cert proving in SNARK. Prove the consecutive signatures for root signatures, CA signatures, etc, to be able to verify that some specific string in a name record was signed by a valid chain of authorities. Would likely use sig-verify circuits in circom.~~