diff --git a/validity_rollups_on_bitcoin.md b/validity_rollups_on_bitcoin.md index c4a2ffc..ac0f2b7 100644 --- a/validity_rollups_on_bitcoin.md +++ b/validity_rollups_on_bitcoin.md @@ -107,7 +107,7 @@ This brings us to the present day. Ethereum developers have redesigned their who [↩](#toc) -A rollup is a blockchain that stores the state root and at least enough transaction data to recompute the current state from genesis inside of the block of a different "parent" blockchain, while shifting transaction execution "offchain" to a separate node network. This is in contrast to related protocols such as state channels, sidechains, and validia chains, which also execute transactions offchain but keep the vast majority (if not all) of their transaction data offchain as well. The operation of a rollup is otherwise identical to any other other blockchain: transactions are bundled into blocks, those blocks are broadcast to a network for verification, and valid blocks are added to the "tip" of the chain of previous blocks. (And as with other blockchains, if there are multiple valid blocks competing to get added to the chain tip, how to choose which block gets added to the chain tip varies depending on the rollup consensus rules.) +A rollup is a blockchain that stores the state root and at least enough transaction data to recompute the current state from genesis inside of the block of a different "parent" blockchain, while shifting transaction execution "offchain" to a separate node network. This is in contrast to related protocols such as state channels, sidechains, and validia chains, which also execute transactions offchain but keep the vast majority (if not all) of their transaction data offchain as well. The operation of a rollup is otherwise identical to any other blockchain: transactions are bundled into blocks, those blocks are broadcast to a network for verification, and valid blocks are added to the "tip" of the chain of previous blocks. (And as with other blockchains, if there are multiple valid blocks competing to get added to the chain tip, how to choose which block gets added to the chain tip varies depending on the rollup consensus rules.) Validity rollups are one of two main rollup variants that have been invented so far.[^52] Validity rollups are so-called because they use cryptographic "validity proofs" to ensure that new rollup blocks follow the rules of the rollup protocol. Every time a validity rollup block is created by a rollup block producer, the block producer submits a state update transaction to the parent chain. The rollup state update transaction contains data about each state transition in the rollup block, the new rollup state root after the state transitions in the block are applied, and a validity proof that proves data availability and that the new rollup state root is a valid update to the last valid rollup state root confirmed on the parent chain. Only state update transactions that are accompanied by a valid proof will successfully advance the rollup state when confirmed. State update transactions with an invalid proof will be confirmed but the transaction will revert and fail (or they will be completely rejected by full nodes and never be confirmed; it depends on the implementation). @@ -195,7 +195,7 @@ A more thorough look at the Lightning Network and how it compares, contrasts, an [↩](#toc) -One of the interesting qualities of validity rollups is that they can enable entirely new functionality to be added to their parent chain without the need for any additional consensus rule changes. This is made possible because rather than be aware of the specific consensus rules of the rollup and know how to execute transactions by following those rules, the parent chain full nodes only need to know how to verify the rollup validity proof. So an L2 validity rollup built on bitcoin L1, for example, could implement an execution environment that supports a more flexible smart contract languages or more advanced privacy technologies, with no other changes needed to bitcoin.[^66] +One of the interesting qualities of validity rollups is that they can enable entirely new functionality to be added to their parent chain without the need for any additional consensus rule changes. This is made possible because rather than be aware of the specific consensus rules of the rollup and know how to execute transactions by following those rules, the parent chain full nodes only need to know how to verify the rollup validity proof. So an L2 validity rollup built on bitcoin L1, for example, could implement an execution environment that supports a more flexible smart contract language or more advanced privacy technologies, with no other changes needed to bitcoin.[^66]

Section 3.1 New smart contract languages

@@ -322,7 +322,7 @@ As more transactions need to be proven valid at each rollup layer, the difficult

Section 4.4 Scaling the Lightning Network with validity rollups

-The Lightning Network is a decentralized network of bidirectional payment channels that routes payments off-chain and uses smart contracts on a base-layer blockchain for dispute resolution and final settlement.[23] Lightning enables any two users connected by a channel route with sufficient liquidity to send and receive value nearly instantly and generally at much lower cost than transacting on the settlement-layer blockchain. To onboard to Lightning in a self-custodial manner, a user must first confirm a transaction opening a channel with another Lightning user. A dual-funded channel can be used to enable bidirectional liquidity in a single transaction.[^94] Once a channel is opened, it may later need additional onchain transactions for maintenance such as channel rebalancing or channel closing for final settlement. +The Lightning Network is a decentralized network of bidirectional payment channels that routes payments off-chain and uses smart contracts on a base-layer blockchain for dispute resolution and final settlement.[^23] Lightning enables any two users connected by a channel route with sufficient liquidity to send and receive value nearly instantly and generally at much lower cost than transacting on the settlement-layer blockchain. To onboard to Lightning in a self-custodial manner, a user must first confirm a transaction opening a channel with another Lightning user. A dual-funded channel can be used to enable bidirectional liquidity in a single transaction.[^94] Once a channel is opened, it may later need additional onchain transactions for maintenance such as channel rebalancing or channel closing for final settlement. The onchain transactions needed to open and settle (and occasionally rebalance) self-custodial Lightning channels take up a measureable amount of limited bitcoin block space. This block space footprint results in a hard upper limit on the number of self-custodial users who can be onboarded to Lightning in a given period of time.[^95] The additional transaction capacity enabled by validity rollups could be used to support more Lightning transactions, increasing the potential number of users who can onboard and use Lightning in a self-custodial manner. The exact numbers depend on the type of transaction used for the Lightning channel. For 2-P2WPKH-input-1-P2WSH-output-2-P2WPKH-output dual-funded channels, rollups can create room for up to 3.8x more Lightning channel open transactions. @@ -364,7 +364,7 @@ Despite the popularity of using Turing-complete programming languages to build r Giving bitcoin full nodes the ability to verify a validity proof is an obvious change that is needed to support validity rollups, since validity proofs are an essential part of how validity rollups work. For this component, whoever writes the code to enable validity proof verification in bitcoin will need to make some decisions about the types of rollups they want to enable. Implementing the ability to verify proofs of more complex programs will enable rollups with more capabilities (e.g. more expressive smart contracts, like Rootstock or Stacks) while simpler proofs would enable rollups with fewer capabilities (e.g. simple payments and limited opcodes, like Liquid or bitcoin). -Less obvious is the need for recursive covenants, at least in the Del Bonis bitcoin rollup design. Recursive covenants are a type of smart contract that restricts the type of script that BTC can be sent to once it is spent. Del Bonis uses recursive covenenants to propagate the rollup construction forward with each state update, ensuring that BTC that is locked in a rollup script and haven't been withdrawn by their owner yet remain in the script from one rollup state update to the next. Once the owner of BTC on the rollup confirms a valid withdrawal transaction on the rollup, then they can exit the recursive covenant script with their BTC to the L1 withdrawal address they specified. +Less obvious is the need for recursive covenants, at least in the Del Bonis bitcoin rollup design. Recursive covenants are a type of smart contract that restricts the type of script that BTC can be sent to once it is spent. Del Bonis uses recursive covenants to propagate the rollup construction forward with each state update, ensuring that BTC that is locked in a rollup script and haven't been withdrawn by their owner yet remain in the script from one rollup state update to the next. Once the owner of BTC on the rollup confirms a valid withdrawal transaction on the rollup, then they can exit the recursive covenant script with their BTC to the L1 withdrawal address they specified. Recursive covenants are a change to Script that has long been considered by the bitcoin community.[^99][^100][^101] However there are currently no specific proposals that have achieved broad consensus among the bitcoin developer community to implement recursive covenants. There are proposals such as BIP-118 and BIP-119 that enable more limited covenants, but these do not have the recursion property needed to ensure that UTXOs sent to the rollup remain in the rollup until their owner is ready to withdraw them back to bitcoin L1.[^102][^103] @@ -452,7 +452,7 @@ Here we again reference the rollup designs from [Section 5](section-5-building-v Some commentators have cited the recursive restrictions enabled by recursive covenants as justification for pushing back on the implementation of covenants in bitcoin.[^131][^132] They point out that this capability could be used by totalitarian governments to force bitcoin users in their jurisdictions to lock their BTC into recursive covenants where the government has programmed in their control of the BTC in perpetuity. While that would indeed be technically possible to implement with recursive covenants, that is only one way that such controls could be implemented. -It is currently possible for governments to implement restrictions on how the BTC owned by their citizens can be transferred, and in a much more flexible way than recursive covenants allow, using a type of smart contract that has been standard in bitcoin for over a decade: multisig.[^133] The basic idea is that the government would require BTC owned by their citizens to be encumbered by a multisig script that requires a signature from both a government-controlled private keys and the actual owner's private key in order to transfer the BTC to another address. Before the government co-signs the transaction, the computer that has control of the government's private key will check to make sure that the transaction is following a transfer policy that is defined offchain in a normal text file that is stored on the government's computer. If the transaction complies with this transfer policy, then the government computer will co-sign the transaction. If the transaction does not comply with the transfer policy (for example, by trying to transfer BTC to an address that the government has not approved) then the government computer will not co-sign the transaction and the transaction will effectively be blocked. If the government ever wants to update their transfer policy to add or remove restrictions, then it's as simple as updating the offchain text file that defines the policy. +It is currently possible for governments to implement restrictions on how the BTC owned by their citizens can be transferred, and in a much more flexible way than recursive covenants allow, using a type of smart contract that has been standard in bitcoin for over a decade: multisig.[^133] The basic idea is that the government would require BTC owned by their citizens to be encumbered by a multisig script that requires a signature from both a government-controlled private key and the actual owner's private key in order to transfer the BTC to another address. Before the government co-signs the transaction, the computer that has control of the government's private key will check to make sure that the transaction is following a transfer policy that is defined offchain in a normal text file that is stored on the government's computer. If the transaction complies with this transfer policy, then the government computer will co-sign the transaction. If the transaction does not comply with the transfer policy (for example, by trying to transfer BTC to an address that the government has not approved) then the government computer will not co-sign the transaction and the transaction will effectively be blocked. If the government ever wants to update their transfer policy to add or remove restrictions, then it's as simple as updating the offchain text file that defines the policy. A working example showing how transfer restrictions can be implemented using multisig is found in Blockstream AMP, a platform developed by the company Blockstream to support the managed issuance and transfer of assets on the Liquid blockchain.[^134] Despite the Liquid blockchain already having support for recursive covenants, Blockstream still decided to implement transfer restrictions using multisig. Blockstream explains in their documentation that transfer restrictions implemented at the smart contract level are "very difficult to adapt to fast-moving regulations worldwide".[^135] In contrast, "Blockstream AMP implements transfer restrictions through a simple multisig authorizer setup, providing [the user] with flexibility to adapt to shifting regulations."[ibid] @@ -472,9 +472,9 @@ Shielded transactions would enable peer-to-peer transactions that are nearly as Governments have already begun cracking down on the usage of protocols that provide privacy protections to cryptoasset users. The governments of Japan and South Korea have effectively banned the trading of several specific cryptoassets that have implemented privacy protocols, such as DASH, XMR, and ZEC.[^137][^138] Most recently, South Korean regulators have pressured exchanges to delist LTC after the Litecoin community implemented support for an opt-in Mimblewimble extension block protocol.[^139] Curiously, although both bitcoin and Ethereum support opt-in privacy protocols with similar characteristics as DASH (in the case of bitcoin's coinjoin implementations) and ZEC (in the case of shielded protocols such as Aztec on Ethereum), both BTC and ETH remain available for trading in South Korea. Although BTC and ETH have escaped a ban in these jurisdictions despite supporting nearly identical privacy protocols as several of the banned cryptoassets, this luck may not last forever. If the bitcoin developers were to build validity rollups on bitcoin with strong privacy, for example, this may increase government scrutiny in these and other jurisdictions hostile to financial privacy. -An alternative to outright banning of the usage and trading of privacy-protecting cryptoassets is to continue to allow their usage but to apply regulatory pressure on exchanges, block producers, and other identifiably chokepoints to disallow interactions with opt-in privacy protocols. For example, when the United States Treasury Department added the Tornado Cash smart contract addresses to the Specially Designated Nationals list that identifies sanctioned individuals and organizations, it created a chilling effect prompting proactive over-compliance.[^140] The exchange FTX reportedly began blocking deposits from addresses that had previously interacted with Tornado Cash, then going beyond that to flag deposits associated with the (non-sanctioned) privacy protocol Aztec.[^141][^142] Ethereum mining pool Ethermine even began to exclude Tornado Cash transactions from its blocks.[^143] +An alternative to outright banning of the usage and trading of privacy-protecting cryptoassets is to continue to allow their usage but to apply regulatory pressure on exchanges, block producers, and other identifiable chokepoints to disallow interactions with opt-in privacy protocols. For example, when the United States Treasury Department added the Tornado Cash smart contract addresses to the Specially Designated Nationals list that identifies sanctioned individuals and organizations, it created a chilling effect prompting proactive over-compliance.[^140] The exchange FTX reportedly began blocking deposits from addresses that had previously interacted with Tornado Cash, then going beyond that to flag deposits associated with the (non-sanctioned) privacy protocol Aztec.[^141][^142] Ethereum mining pool Ethermine even began to exclude Tornado Cash transactions from its blocks.[^143] -The legal advocacy group Coin Center has published an anlysis questioning the legality of adding the Tornado Cash smart contract addresses to the SDN list.[^144] Investment group Paradigm has published a separate analysis suggesting that there is no legal basis for Ethermine and other block producers to exclude Tornado Cash transactions in their blocks despite the sanctions.[^145] Even if these analyses are correct, it would not mean other, stronger legal attacks could not be mounted against blockchain privacy protocols in the future, particularly in jurisdictions that have fewer free speech or rule of law protections than the United States. While attacks on users of privacy protocols may remain focused at the application layer, it's possible that some governments take their fight to the block producer and consensus layer. Bitcoin is designed to be resilient to these kinds of attacks, but nonetheless, Bitcoin developers and community members will have to decide if the risk of prompting such attacks is worth the advantages of adding strong, trustless privacy via validity rollups built on bitcoin. +The legal advocacy group Coin Center has published an analysis questioning the legality of adding the Tornado Cash smart contract addresses to the SDN list.[^144] Investment group Paradigm has published a separate analysis suggesting that there is no legal basis for Ethermine and other block producers to exclude Tornado Cash transactions in their blocks despite the sanctions.[^145] Even if these analyses are correct, it would not mean other, stronger legal attacks could not be mounted against blockchain privacy protocols in the future, particularly in jurisdictions that have fewer free speech or rule of law protections than the United States. While attacks on users of privacy protocols may remain focused at the application layer, it's possible that some governments take their fight to the block producer and consensus layer. Bitcoin is designed to be resilient to these kinds of attacks, but nonetheless, Bitcoin developers and community members will have to decide if the risk of prompting such attacks is worth the advantages of adding strong, trustless privacy via validity rollups built on bitcoin. #### Financing a freer future @@ -488,7 +488,7 @@ Decentralized domain name systems provide websites with censorship-resistant mem Giving people new tools to fight authoritarians is a good thing. The risk is that these powerful new tools invite more negative attention to bitcoin. Where freedom vs authoritarianism is concerned, the anti-authoritarian bitcoin community may be willing to say, "bring it on". But these powerful new tools enabled by validity rollups can be used for harmful purposes as well. Just as private payments can be used by someone to escape the prying eyes of their abusive domestic partner, private payments can also be used to facilitate untraceable ransom payments. Just as a censorship-resistant website can be used to host an uncomfortable political truth, it can also be used to host nonconsensual material that victimizes innocent people. The bitcoin community already has to deal with these kinds of concerns, but validity rollups could amplify them even further.[^146][^147] -This is another one of those issues where if validity rollups are enabled, the bitcoin community will have to make a decision about exactly _what kind_ of rollups will be enabled: does the bitcoin community invite the full contents of Pandora's box to be released on L2, or are there certain features or smart contracts that bitcoin users should never be allowed to access in a trustless manner? I phrase the question that way, with an emphasis on "trustless", because the alternative to supporting these powerful and controversial use-cases directly on bitcoin (via an L1 extension or as a new protocol on L2) is not that these use cases will never happen and all risk and harm from such use cases will be averted. The alternative is the status quo, where bitcoin users must give up control of their BTC to trusted "bridges" in exchange for IOUs on sidechains or altcoin chains where these use cases are actually supported.[70] On this question, the choice before the bitcoin community is not between _risk_ or _no risk_, it is between _risk without trusted third parties / with fewer trusted third parties_ or _risk with trusted third parties / more trusted third parties_. +This is another one of those issues where if validity rollups are enabled, the bitcoin community will have to make a decision about exactly _what kind_ of rollups will be enabled: does the bitcoin community invite the full contents of Pandora's box to be released on L2, or are there certain features or smart contracts that bitcoin users should never be allowed to access in a trustless manner? I phrase the question that way, with an emphasis on "trustless", because the alternative to supporting these powerful and controversial use-cases directly on bitcoin (via an L1 extension or as a new protocol on L2) is not that these use cases will never happen and all risk and harm from such use cases will be averted. The alternative is the status quo, where bitcoin users must give up control of their BTC to trusted "bridges" in exchange for IOUs on sidechains or altcoin chains where these use cases are actually supported.[^70] On this question, the choice before the bitcoin community is not between _risk_ or _no risk_, it is between _risk without trusted third parties / with fewer trusted third parties_ or _risk with trusted third parties / more trusted third parties_.

Section 6.7 Novel cryptography

@@ -557,7 +557,7 @@ We can see in [Table 5](#table-5-protocol-comparison-table) how validity rollups | | Zendoo [r] | Validity proof | Offchain with onchain checkpoints | No | Maybe** | No | > Table 5 notes: -> [ * ] "Parent chain miners can steal" here refers to the idea that if enough parent chain block producers aka "miners" collude then they can steal money from users of the protocol in question without either the cooperation of the user being stolen from (as would be necessary if they were censoring and extoring the user) or needing to re-org a parent chain block (as would be necessary if they were double-spend attacking the user). See also https://lightco.in/2021/06/21/miners-can-steal/ +> [ * ] "Parent chain miners can steal" here refers to the idea that if enough parent chain block producers aka "miners" collude then they can steal money from users of the protocol in question without either the cooperation of the user being stolen from (as would be necessary if they were censoring and extorting the user) or needing to re-org a parent chain block (as would be necessary if they were double-spend attacking the user). See also https://lightco.in/2021/06/21/miners-can-steal/ > > [ ** ] "Maybe" in this column refers to the fact that unilateral exit is possible only if the necessary data is available to users who need it to create their withdrawal transaction. > @@ -608,7 +608,7 @@ Due to many of bitcoin's current limitations (e.g. limited scripting capabilitie Perhaps the most important weakness of bitcoin that makes privacy difficult is also seen as one of bitcoin's biggest strengths: the transparent nature of transaction amounts i.e. bitcoin's public auditability. Because bitcoin transaction amounts are transparent and publicly visible on the blockchain, they can be used to correlate senders and recipients and distinguish recipient addresses from change addresses and self-sends.[^158][^159] Bitcoin privacy protocols try to fight these heuristics by mixing coins with one or more other users and by creating equal-amount outputs to increase the anonymity set of each transaction. But if any participant in the mix does something to de-anonymize themselves, they are removed from the anonymity set (sometimes without other mix participants even knowing). Eventually, an anonymity set can be whittled down to being no larger than a single-output transaction.[^160] This gradual degradation of mix anonymity sets makes bitcoin privacy inherently fragile, requiring constant costs (incurred as mining fees) to maintain anonymity set sizes via re-mixing or other "post-mix" privacy techniques. -The cost of maintaining anonymity set sizes, plus the requirement to wait for a sufficient number of users to mix equal-amount outputs to gain a sufficiently large anonymity set, can make bitcoin privacy techniques impractical for point of sale transactions or transactions of low value. There is justification for hoping that offchain protocols such as Lightning can offer improvemnts: because Lightning transactions are offchain, the details of transactions are only known to each node along a payment channel path, and in some cases only part of the details of the transaction are known to each node along the path. Atomic multipath routing could add even more ambiguity into Lightning payments, since routing nodes would not know whether they are routing the full payment or only part of the payment. However the privacy enabled here is probabilistic at best, and difficult to quantify for both senders and recipients: it could be the case that their counterparties along the path know either very little or everything about their payments. That's not to mention the privacy issues associated with balance probing and channel open/close transactions.[^161] In its current form, Lightning is best considered to be a fast and high-throughput payments solution, not a privacy solution. (This could change in the future!)[^76] +The cost of maintaining anonymity set sizes, plus the requirement to wait for a sufficient number of users to mix equal-amount outputs to gain a sufficiently large anonymity set, can make bitcoin privacy techniques impractical for point of sale transactions or transactions of low value. There is justification for hoping that offchain protocols such as Lightning can offer improvements: because Lightning transactions are offchain, the details of transactions are only known to each node along a payment channel path, and in some cases only part of the details of the transaction are known to each node along the path. Atomic multipath routing could add even more ambiguity into Lightning payments, since routing nodes would not know whether they are routing the full payment or only part of the payment. However the privacy enabled here is probabilistic at best, and difficult to quantify for both senders and recipients: it could be the case that their counterparties along the path know either very little or everything about their payments. That's not to mention the privacy issues associated with balance probing and channel open/close transactions.[^161] In its current form, Lightning is best considered to be a fast and high-throughput payments solution, not a privacy solution. (This could change in the future!)[^76] Researchers have studied the shortcomings of bitcoin privacy protocols and invented new protocols that they believe offer significant improvements to protect user privacy. Here we examine three of the most well-known alternative privacy protocols and compare the amount of data that each reveals about its users, thereby providing a basis for comparing their relative privacy improvements. @@ -636,7 +636,7 @@ Monero has since improved on the original CryptoNote protocol by implementing Ri Despite Monero's significant privacy improvements compared to bitcoin, the web of transactions created by RingCT and stealth addresses are not as impenetrable as the mass of metadata on the blockchain would first appear. There are attacks based on common usage patterns such as the overseer attack, the flashlight attack, and the tainted dust attack that can be used to deanonymize either the sender or recipient of a transaction.[^73] As with bitcoin-based privacy protocols, decoy-based protocols such as that implemented in Monero have been shown to be fragile in practice (though arguably more forgiving to "mistakes" than bitcoin, thanks to the multiple layers of cryptographic hiding and obfuscation). -#### Figure 11. How a Monero transaction looks in the explorermonero.com explorer +#### Figure 11. How a Monero transaction looks in the exploremonero.com explorer ![figure11_vr](https://user-images.githubusercontent.com/9424721/186961096-4d5c4718-36c6-4fc3-906c-2bc6058bfbd7.png) @@ -790,7 +790,7 @@ Another factor holding back block size limit increases is block propagation time Proofs of the validity of the blockchain solve the IBD issue for blocks of arbitrary size by removing the requirement that full nodes download and execute every transaction in every block to sync up to the chain tip. Instead, a validity proof can be produced as of a given block height `n` that can be used to convince full nodes that 1) a copy of the UTXO set is derived from the heaviest valid chain as of block `n` and 2) that newly received blocks `n+1, n+2, etc` correctly build upon the heaviest valid chain. This means that full nodes only have to download a copy of the UTXO set as of block `n`, verify the proof of `n`, and execute transactions in blocks built on top of `n` up until the next proof, rather than execute all transactions in all blocks from genesis. Proofs can continue to be generated for each block or for batches of blocks to maintain fast IBD and sync times for full nodes. -This "proof-sync" technique may solve the IBD problem of large blocks, but it does not solve the mining centralization problems. Work still needs to be done to decrease the bandwidth costs and propogation times of increased L1 transaction volume, for example by implementing or further optimizing protocols such as Compact Block Relay and Erlay that reduce bandwidth requirements even as transaction volume increases.[^182][^183] And there's no getting around the requirement for storage of blockchain data, which increases as the size of the blockchain grows. Still, having one less problem to solve (the IBD problem) is a nice improvement. The best part is that no consensus rule changes are required to implement and start using proof-sync clients. As of the time of writing, there are two projects working on building a proof-sync bitcoin client implementation written in Cairo, one is called Khepri and the other is called Zerosync.[^184][^185] +This "proof-sync" technique may solve the IBD problem of large blocks, but it does not solve the mining centralization problems. Work still needs to be done to decrease the bandwidth costs and propagation times of increased L1 transaction volume, for example by implementing or further optimizing protocols such as Compact Block Relay and Erlay that reduce bandwidth requirements even as transaction volume increases.[^182][^183] And there's no getting around the requirement for storage of blockchain data, which increases as the size of the blockchain grows. Still, having one less problem to solve (the IBD problem) is a nice improvement. The best part is that no consensus rule changes are required to implement and start using proof-sync clients. As of the time of writing, there are two projects working on building a proof-sync bitcoin client implementation written in Cairo, one is called Khepri and the other is called Zerosync.[^184][^185]

Appendix F. Mitigating harm from compromised cryptographic proof protocols and toxic waste