@ -26,6 +26,7 @@ Contact the author: https://lightco.in/contact
- Appendix C. Increasing throughput with offchain data availability
- Appendix D. A closer look at validity sidechains
- Appendix E. Enabling additional throughput increases with validity proofs
- Appendix F.
- References **(TODO)**
- License **(TODO)**
@ -346,9 +347,9 @@ Recursive covenants are a change to Script that has long been considered by the
Del Bonis identifies the OP_EVAL and PUSHSCRIPT opcodes as nice-to-haves that reduce the size of the rollup script in some areas, reducing the amount of blockspace used and therefore making rollups cheaper to use, all else being equal. Increasing or removing the stack element size limit are another nice-to-have that he identifies as making rollups cheaper to use, in this case by increasing the number of transactions that can fit into each rollup state update, thereby enabling the cost of the rollup update to be shared by a larger number of transactions.[89]
The Del Bonis rollup design is one way to build validity rollups on bitcoin, but not the only way. For example, it would be possible to add an extension block to bitcoin with custom logic that supports the creation of specific or arbitrary rollup designs. In his post, Del Bonis discusses several alternative ways that rollups could be built on bitcoin, either as minor tweaks to his more detailed design or using entirely different mechanisms for ensuring the security of funds held in the rollup. Rather than add direct support for the opcodes needed, support for validity rollup primitives could be implemented in Simplicity using Jets, for example.[95]
The Del Bonis rollup design is one way to build validity rollups on bitcoin, but not the only way. For example, it would be possible to add an extension block to bitcoin with custom logic that supports the creation of specific or arbitrary rollup designs. In his post, Del Bonis discusses several alternative ways that rollups could be built on bitcoin, either as minor tweaks to his more detailed design or using entirely different mechanisms for ensuring the security of funds held in the rollup. Rather than add direct support for the opcodes needed, support for validity rollup primitives could be implemented in Simplicity using Jets, for example.[95] Anthony Towns has also suggested using Chialisp as an alternative to Simplicity for similar use-cases.[96]
The Elements sidechain project (and the Liquid blockchain that is based on Elements) does not yet have support for the validity proofs needed to support a validity rollup, but it does have support for recursive covenants.[96, 97] Implementing support for validity proofs in Elements, along with some of the other changes Del Bonis identified as nice to have, could therefore be a path to testing a validity rollup protocol that is ultimately intended to be deployed to bitcoin.
The Elements sidechain project (and the Liquid blockchain that is based on Elements) does not yet have support for the validity proofs needed to support a validity rollup, but it does have support for recursive covenants.[97, 98] Implementing support for validity proofs in Elements, along with some of the other changes Del Bonis identified as nice to have, could therefore be a path to testing a validity rollup protocol that is ultimately intended to be deployed to bitcoin.
What the research so far shows is that with some changes it would be possible to build validity rollups on bitcoin. Some designs would be more technically difficult to implement than others, but even with the simpler implementations proposed, bitcoin users stand to gain significant scaling benefits and potentially more privacy and other desirable functionality as well.
@ -594,7 +595,11 @@ Zcash is the first implementation of the Zerocash protocol. The defining privacy
> Image source: [124]
While Zerocash transactions hide the most transaction information of all currently known techniques, there is still some onchain metadata leakage that could be used to de-anonymize transactions. For example, a Zerocash transaction publicly reveals the amount of inputs and outputs used in the transaction. This has been shown in practice to be enough information to de-anonymize the sender of a Zerocash transaction.[124] While this demonstration was contrived, and there is a way to mitigate this attack by merging the notes together before sending them to their final destination, and the risk of deanonymization decreases the more transactions with like-input-and-output note amounts there are to hide among, the mock attack showed how the little metadata that Zerocash does reveal can be used to deanonymize users. Countermeasures against the onchain (and offchain) metadata leaks that there are must therefore be taken by users (or the wallets of users) who need to remain unidentifiable when transacting with shielded coins.
While Zerocash transactions hide the most transaction information of all currently known techniques, there is still some onchain metadata leakage that could be used to de-anonymize transactions. For example, a Zerocash transaction publicly reveals the amount of inputs and outputs used in the transaction. This has been shown in practice to be enough information to de-anonymize the sender of a Zerocash transaction.[125] While this demonstration was contrived, and there is a way to mitigate this attack by merging the notes together before sending them to their final destination, and the risk of deanonymization decreases the more transactions with like-input-and-output note amounts there are to hide among, the mock attack showed how the little metadata that Zerocash does reveal can be used to deanonymize users. Countermeasures against the onchain (and offchain) metadata leaks that there are must therefore be taken by users (or the wallets of users) who need to remain unidentifiable when transacting with shielded coins.
### A note on "opt-out" vs "opt-in" privacy
Some people may argue that the "opt-in" nature of encrypted protocols implemented in a validity rollup makes the privacy less effective for those who use it, and that "opt-out" encrypted protocols on blockchains such as Beam or Monero will always provide superior privacy, all else being equal. This is a misunderstanding. There is actually no such thing as purely "opt-out" privacy, because _all_ protocols, private or not, are "opt-in" at first (assuming no one is coerced by some external force to use them). People "opt-in" to using Monero by choosing to download a Monero wallet and buy, receive, or mine monero, just as people would "opt-in" to using an encrypted validity rollup on bitcoin by downloading a compatible bitcoin wallet and buying or receiving encrypted bitcoin or depositing their transparent bitcoin into the encrypted validity rollup. Likewise, an encrypted bitcoin user could choose to never touch transparent bitcoin, the same way a Monero user can choose to never touch transparent bitcoin. In both cases, people first "opt-in" to the encrypted protocol, and then they can choose whether or not they ever want to "opt-out". The only meaningful difference to end users in these cases is the unit of account involved.
## Appendix C. Increasing throughput with offchain data availability
@ -729,15 +734,13 @@ One concern that is often brought up when discussing the idea of implementing cr
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.
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 bitcoin 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 bitcoin from the rollup than was originally deposited, preserving the integrity of the L1 money supply.
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.
Some people may argue that building an encrypted validity rollup on bitcoin would threaten the integrity of the money supply due to the possibility of undetectable inflation. In practice, any unexpected, undetectable inflation that occurs could be isolated to the encrypted rollup so that the fully auditable "transparent" bitcoin supply remains intact. As described above, bitcoin consensus rules can prevent more bitcoin from being withdrawn from the encrypted rollup than were deposited, ensuring that the integrity of the money supply outside of the encrypted rollup is preserved.
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.
So if you don't want to worry about being left holding worthless encrypted bitcoin because someone exploited an inflation vulnerability and withdrew the maximum available balance from the rollup, you can keep all of your bitcoin in a fully-auditable transparent bitcoin layer. If you are willing to risk keeping some spending bitcoin encrypted so you can transact with strong privacy but want to keep the rest of your bitcoin transparent so you don't put your savings at risk of undetectable inflation then you can do that too. And if you aren't worried about an inflation vulnerability at all, or find the privacy gains worth the risk, you can keep all of your bitcoins encrypted if you want to. The encrypted rollup gives you several options depending on your risk tolerance.
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]
It's important to note here that undetectable inflation in encrypted protocols is _already possible_ because there are already encrypted protocols where the supply of encrypted bitcoin-denominated assets is at risk of an inflation vulnerability. For example, L-BTC on Liquid and renBTC on Aztec could both be unexpectedly and undetectably inflated if there was an inflation vulnerability that got exploited.[136, 70] The only relevant difference between these existing encrypted 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 validity rollup on bitcoin due to concerns about undetectable inflation would not be to prevent users from putting their bitcoin at risk of an inflation vulnerability, but to prevent users from doing so _in a non-custodial way_ and instead drive bitcoins into the control of trusted custodians — the law of unintended(?) consequences in action.[137]
John Light
2 years ago
GitHub