@ -440,7 +440,7 @@ Decentralized domain name systems provide websites with censorship-resistant mem
**To be (a powerful and private smart contract platform) or not to be...**
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.[115, 116]
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 Layer 2, 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 a Layer 1 extension or as a new protocol on Layer 2) 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 satoshis to trusted "bridges" in exchange for IOUs on sidechains or altcoin chains where these use cases are actually supported.[64] On this question, the choice before the bitcoin community isn't between _risk_ or _no risk_, it's 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 satoshis to trusted "bridges" in exchange for IOUs on sidechains or altcoin chains where these use cases are actually supported.[64] 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_.
### 6.6 Novel cryptography
@ -454,15 +454,17 @@ The novelty or "Lindy" factor of the cryptography used in validity proofs depend
Another consideration is the age of implementation and "battle hardening" that a given validity proof implementation has gone through. With the oldest production implementations now several years old (about as old as the Schnorr algorithm implementation that was integrated into Bitcoin Core) there are several validity proof systems that could be used or at least looked at for inspiration.[114] That said, there have been vulnerabilities found in some production implementations of cryptographic proof protocols.[115, 116] Each time such a vulnerability is discovered in a given cryptographic proof implementation, that implementation's "Lindy clock" is reset back to zero.
While the implementations of the oldest validity proof and Schnorr protocols used by cryptocurrencies in production are now around the same age, the _protocol designs_ that the validity proof implementations are based on are relatively new compared to the Schnorr signature algorithm. This means that the validity proof designs have had less time for review. We can gemerally expect that if there is a vulnerability in a protocol design, then as time goes and the number of reviews the protocol receives increases, the likelihood that the vulnerability will be discovered also increases. For example, during a review of the details of Zcash's "Sprout" cryptographic proof protocol ahead of giving a technical presentation about the protocol in 2018, Ariel Gabizon discovered a critical design flaw that would have enabled an attacker to undetectably counterfeit shielded coins.[117]
While the implementations of the oldest validity proof and Schnorr protocols used by cryptocurrencies in production are now around the same age, the _protocol designs_ that the validity proof implementations are based on are relatively new compared to the Schnorr signature algorithm. This means that the validity proof designs have had less time for review. We can generally expect that if there is a vulnerability in a protocol design, then as time goes and the number of reviews the protocol receives increases, the likelihood that the vulnerability will be discovered also increases. For example, during a review of the details of Zcash's "Sprout" cryptographic proof protocol ahead of giving a technical presentation about the protocol in 2018, Ariel Gabizon discovered a critical design flaw that would have enabled an attacker to undetectably counterfeit shielded coins.[117]
The discovery of vulnerabilities in the design and implementation of production cryptographic proof systems shows that additional caution, time, review, and testing is warranted when deploying such a system into a blockchain such as bitcoin where it may not be possible to fix a vulnerability without a consensus-level software update.
The discovery of vulnerabilities in the design and implementation of production cryptographic proof systems shows that additional caution, time, review, and testing is warranted when deploying such a system into a blockchain such as bitcoin where it may not be possible to fix a vulnerability without a consensus-level software update. Vulnerabilities in a cryptographic proof protocol would put the coins secured by the protocol at risk either by causing the validity proofs to fail verification when they should succeed (effectively freezing the assets secured by the proof protocol) or by causing the validity proofs to successfully verify when they should fail (enabling an attacker to counterfeit and/or steal assets secured by the proof protocol).
### 6.7 Compromised "toxic waste"
Some cryptographic proof protocols rely on a "parameter generation ceremony" (also known as a "trusted setup") to instantiate the protocol.[118] The purpose of this ceremony is to generate "public parameters" that can be used to verify the validity proofs produced by users of the protocol. In order to generate the public parameters, random numbers have to be used as inputs. If a user knows all of the random numbers used to generate the public parameters, they will be able to produce counterfeit proofs that appear valid even though the transaction the proof is validating violates the basic expectations of the protocol e.g. a user with all of the random numbers could mint coins "out of thin air" rather than minting them via the mining protocol. Because these random numbers are both critical to the integrity of the protocol and necessary byproducts of the protocol setup that must be carefully kept separate from each other at all time, they are often referred to as "toxic waste".
STARK-based proof protocols, being "transparent" in nature, inherently do not require a parameter generation ceremony.[119] Most SNARK-based proof protocols, however, including all of the proof protocols used by SNARK-based validity rollups in production today, do require a parameter generation ceremony. However in 2019 Sean Bowe discovered how to do zero-knowledge proof constructions on ordinary elliptic curves, with the exciting outcome that zk-SNARKs could be produced without the need for a parameter generation ceremony.[120] Later that year, Bowe published a paper with co-authors Daira Hopwood and Jack Grigg describing the new protocol, which they named "Halo", in detail.[83] The invention of the Halo protocol opens the possbility of SNARK-based validity rollups that do not require a parameter generation ceremony, thereby eliminating the toxic waste vulnerability.
STARK-based proof protocols, being "transparent" in nature, inherently do not require a parameter generation ceremony and therefore do not generate toxic waste.[119] In contrast, most SNARK-based proof protocols, including all of the proof protocols used by SNARK-based validity rollups in production today, do require a parameter generation ceremony. However in 2019 Sean Bowe discovered how to do zero-knowledge proof constructions on ordinary elliptic curves, with the exciting outcome that zk-SNARKs could be produced without the need for a parameter generation ceremony.[120] Later that year, Bowe published a paper with co-authors Daira Hopwood and Jack Grigg describing the new protocol, which they named "Halo".[83] The invention of the Halo protocol opens the possbility of SNARK-based validity rollups that do not require a parameter generation ceremony, thereby eliminating the toxic waste vulnerability.
See Appendix F for a look at how the risk of compromised cryptographic proofs and toxic waste could be mitigated to prevent harm to L1 bitcoin users.
---
@ -721,6 +723,22 @@ Proofs of the validity of the blockchain solve the IBD issue for blocks of arbit
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 Layer 1 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.[132, 133] 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, Lukas George and Robin Linus have begun work on a proof-sync bitcoin client implementation written in Cairo called "Zerosync".[134]
## Appendix F. Mitigating harm from compromised cryptographic proof protocols and toxic waste
One concern that is often brought up when discussing the idea of implementing cryptographic proofs for privacy on bitcoin is the possibility of unexpected inflation. If someone discovers this kind of vulnerability in the cryptography used for the privacy protocol, they can exploit the vulnerability to mint an arbitrary amount of BTC. Furthermore, because transactions using the privacy protocol are encrypted in some way, the inflation will be undetectable for some period of time. This concern stems from a fundamental tradeoff in the design of cryptocurrency privacy protocols based on cryptographic proofs: a cryptographic proof can be perfectly hiding, or perfectly binding, but not both.[135] This tradeoff means that the protocol designer must either allow the money supply to be inflated via counterfeit but preserve privacy if the cryptography is broken (perfectly hiding), or they preserve the money supply integrity but allow privacy to be broken (perfectly binding). Production implementations of encrypted transactions, including those covered in Appendix B, are typically designed to be perfectly hiding.
The same risk exists when using computational proofs for transaction verification as opposed to transaction privacy, for example to verify unencrypted rollup transactions. If the cryptographic proof is broken, then anyone who exploits the vulnerability will be able to forge proofs withdraw assets from the rollup even if they do not have the private keys to the addresses that control those assets according to the rollup ledger. In this case, the forgery can be detected immediately, but there is still the potential for disastrous harm if L1 full nodes and miners do not react to prevent the forged proofs from being confirmed on L1.
In the context of validity rollups on bitcoin, the primary factor mitigating harm from these kinds of cryptographic vulnerabilities is the fact that validity rollups are opt-in. As such, only users who have satoshis stored in the validity rollup will be affected at a technical level by the exploitation of a cryptographic proof vulnerability. The consensus rules of bitcoin L1 can prevent the attacker(s) from withdrawing more satoshis from the rollup than were originally deposited, preserving the integrity of the L1 money supply.
Some people may argue that the opt-in nature of privacy protocols implemented in a validity rollup makes the privacy less effective for those who use it, and that "always-on" private protocols on blockchains such as Beam or Monero will always provide superior privacy. This is a misunderstanding: yes, the more people there are who use a bitcoin privacy protocol, the bigger the anonymity set and the better the privacy is for everyone. However there is no such thing as "always-on" privacy, because people _always_ have the ability to transact in a non-private way.
Even if the entire bitcoin blockchain were made to be encrypted, someone could publicly publish "view keys" that make their transactions public as bitcoin transactions are today, or they could trade their satoshis for assets on another blockchain that is not encrypted. This is functionally the same as a world where 100% of bitcoin users move their activity into an encrypted rollup, but have the option to withdraw their coins back to the transparent L1. In both cases, users have a choice between transacting privately or not. What really matters here are the defaults established outside of the blockchain: whether wallets default to showing users an encrypted address or transparent address, whether users choose to trade their fiat for encrypted satoshis or transparent satoshis, whether merchants default to accepting encrypted satoshis or transparent satoshis, etc. Replace "encrypted address" and "encrypted satoshis" in the previous sentence with the privacy coin _du jour_ to see that it's functionally the same choice that users have today. The only difference is the unit of account involved.
Other people may argue that adding an encrypted transaction layer to bitcoin threatens the integrity of the monetary supply due to the possibility of undetectable inflation. This is true, but only for people who hold satoshis in the encrypted transaction layer. As already established above, bitcoin consensus rules can prevent more satoshis from being withdrawn from the encrypted layer than were deposited, ensuring that in the transparent layer, the integrity of the money supply is preserved. If you don't want to worry about being left holding worthless encrypted satoshis because someone exploited a cryptographic vulnerability and withdrew all available transparent satoshis from the encrypted layer, you can keep all of your assets in the encrypted layer. If you are willing to risk keeping some spending money encrypted but the rest of your savings transparent so you don't put your savings at risk you can do that too.
The bad news for people concerned about undetectable inflation in encrypted protocols is that there are already encrypted protocols where the supply of encrypted bitcoin is at risk of an inflation vulnerability. For example, L-BTC on Liquid and renBTC on Aztec could both be arbitrarily inflated if there was an inflation vulnerability that got exploited.[136, 70] The only relevant difference between these existing protocols and validity rollups for the purpose of this discussion is that with L-BTC and renBTC bitcoin users have to trust third parties with the custody of their satoshis while validity rollups are non-custodial by design. The outcome that would be achieved by someone who opposes the implementation of an encrypted transaction layer on bitcoin due to concerns about undetectable inflation would not be to prevent users from putting their satoshis at risk of an inflation vulnerability, but to prevent users from doing so in a non-custodial way and instead drive satoshis into the control of trusted custodians — the law of unintended(?) consequences in action.[137]
John Light
2 years ago
GitHub