A two-way peg bridging BTC to other chains. It works similar to a perpetual one-way peg; however, instead of burning the BTC they are locked up until a particular time in 20 years.
Until then, the community has to figure out how to do peg-outs with, e.g., some sort of OP_ZKP_VERIFY or Simplicity.
We simply pretend that OP_NOP10 is OP_ZKP_VERIFY and let users lock BTC in the following script:
<program_hash> OP_NOP10
<year 2040> OP_CLTV OP_2DROP
We design OP_ZKP_VERIFY such that it reads from the stack the <program_hash> and the <zk_proof> provided in the unlocking script.
The more coins are locked in that script the higher the incentive to solve this problem.
- This is a bet on a fork getting activated. Though, there's no speculative upside to BTC because in case of demand people can always bridge more BTC.
- As long as there is a rational reason to believe that this engineering problem will get solved, there is a clear value backing these bridged BTC, even if it is less than 1:1
- The value of bridged BTC results from the probability of the softfork activation
- The script forces the community to come up with some consensus change before all these time locks open. Otherwise, it messes up the miners' incentives because it incentivizes them to keep overwriting the chain to take the unlocking BTC.
- The timelock could also open when the overflow bug in the timestamps happens because until then we have to do some hardfork anyways
- Additionally, the holders of bridged BTC are incentivised to enforce some user-activated softfork
- Until the timelock opens, people can simply use atomic swaps to bridge back to BTC (also over LN)
- We have to define the
OP_ZKP_VERIFYupfront, otherwise it has to be too specific to this particular use case. - This peg is coercive and controversial. People might oppose it a lot.
- Ideally,
OP_ZKP_VERIFYknows the latest bitcoin block hash. This way the proof can reason about any data contained in the bitcoin chain. In particular, users can run collectively a sidechain light client inscribed into the bitcoin chain to provably resolve the sidechain's longest chain rule and establish consensus about the sidechain's state.
Burak came up with the key idea. Super Testnet and I helped fleshing it out and writing it up.
It is similar to Jeremy Rubin's idea for betting on Taproot activation.
OP_ZKP_VERIFY may not be sufficient by itself. We may also need where the change output will go to - possibly another output locked by OP_ZKP_VERIFY or something, so the spender spends whatever they can spend, and remaining is held by the contract again, so others can spend it using the same mechanism.