Bitcoin Cash Shielded Addresses & ZKP OP_Code

Technical
, , ,
#1

This topic is dedicated for tracking the discussion ideas, and progress around ZKP opcodes such as zk-STARK.

  • Discussion Points:

  1. Generic Verifier or zk-STARK Integration:

    • As Jason mentioned, privacy covenants can enable BCH and CashTokens to transact privately while maintaining total balance transparency on Layer 1. Could zk-STARK verifier opcodes enhance this approach by improving scalability and capabilities, such as supporting shielded pools or UTXO-based smart contracts?
      IMG_0490
      IMG_04901285×1783 207 KB

  2. Some Discussions revolved around the possibility of enabling shielded addresses and leveraging zk-STARKs where The goal is to hide sender and receiver addresses while maintaining transparent UTXO balances, potentially achieved by introducing advanced opcodes.

    • Shadow pointed out that BCH current opcode capabilities make implementation feasible.

    • bch_autist & JF suggests ZKP verification can be achieved on BCH wthout dedicated opcode.

    • btc_canary was proposing to explore forking a STARK verifier opcode.

  3. Reference of Practical Implementation:

    • Weikeng Chen showed that Bitcoin can support ZKP verification using OP_CAT and zkWASM.

    IMG_0492
    IMG_04921321×1746 161 KB

———————————————————————————

  • Jason: Bitcoin Script: multi byte opcodes (ZKP OP_Code)

    “In the case of zero knowledge proofs (ZKPs) specifically, those will almost certainly not be a set of new opcodes – for ZKPs to be integrated that way, all other operations would also need to be compatible with the ZKP paradigm, including e.g. flow control + OP_DEPTH. That may be possible with a lot of big breakthroughs + complex hacks, but it’s far more likely that a smaller, more well-proven ZKP system will be integrated in a self-contained way (where existing opcodes don’t complicate or break otherwise well-proven security properties).

    So in practice, this will likely look more like a single OP_CHECKZKP or a small set of setup/check operations. Like a new sort of OP_CHECKDATASIG rather than a new grab-bag of small OP_ZKPADD , OP_ZKPSUB , etc. operations.

    When thinking about new crypto algorithms, it’s probably most useful to think of the VM as exposing them over a VM-friendly API. Contracts don’t manually use large integer math operations to implement signature checking, they use OP_CHECKSIG . Again, it’s possible that future crypto systems will require different, more complex API interfaces, but I’ve tried to account for that by estimating high – 4 per 10 years. (And remember, in the past 10 years, we added ~2: OP_CHECKDATASIG and `aWSFX03Os0q3RLcMlr7bQsvRM8V.jpeg)

————————————————————————————-

2 Likes
#2

Glad to see these conversations about privacy starting up, if BCH wants to be adopted as money then top tier privacy is a must.

1 Like