# Bitcoin zk-p2p

A bitcoin based trustless p2p onramp/offramp protocol. It uses bitvm technique to verify a groth16 proof of offchain payment (eg.Venmo) in bitcoin.

### Transaction flow

Participants:
- **Valeria** has BTC and wants to sell for Fiat USD on venmo.
- **Peter** has USD on Venmo and wants to buy some BTC.
- **Market Makers** lock funds for duration of challenge period so that Peter can get their BTC instantly.
- **Challengers** watching over transactions of market makers during the challenge period and initiate challenges if there is a cheating attempt.

1. Neither of the participants trust each other. They agree on price and fees through an offchain matching mechanism.
2. Valeria locks BTC in a utxo with output set to a groth16 proof of venmo + specifies venmo ID to send usd to.
3. Peter sends USD to the specified venmo ID, receives an email confirmation, uses zkemail to generate a groth16 proof.
4. Peter finds a market maker that is willing to guarantee his proof in case it was fraudelent. He shares the proof offchain and maker confirms it and accepts to be the guarantor for a small fee. The maker will lock funds for the durarion of the challenge period.
5. Transactions set are prepared and signed by all parties (tx details to be specified below) wich results in:
a) Peter receives his BTC
b) Valeria receives her USD on venmo
c) Maker's BTC is locked for duration of challenge period
7. In case the proof was fraudelent (i.e Peter never actually did the Venmo transaction) a challenger can utilize the challenge tx's signed by the maker to unlock the maker's funds for a reward and Valeria gets her BTC back.


### Transaction set details

Use: [adaptor signatures](https://bitcoinops.org/en/topics/adaptor-signatures/)
BTC_AMOUNT: BTC amount to be offramped

#### tx1
from: Valeria
to: Maker
Value: BTC_AMOUNT
Output paths:
1. Maker spends after challenge period

#### tx2
from: Maker
to: Peter
Value: BTC_AMOUNT - maker fees
Output paths:
1. Peter can spend instantly

#### tx3
from: maker
to: challenger + Valeria
Value: BTC_AMOUNT + CHALLENGER_REWARD
Output Paths:
1. Valeria BTC_AMOUNT
2. CHALLENGER_REWARD

### Bitvm
Bitvm is a technique of verifying any arbitrary turing-complete computations in Bitcoin. This includes zk-snark verification computation logic for example. It works like this:
- Write the desired computation in bitcoin script
- Break down the computation to steps and define each step's computation in this form f(input) = output, where each step's output is the input to the next step. Each step is a bitcoin script that represents the computation.
- Commit all the step scripts into the taproot tree leaves by having each step in a leaf.
- If the computation not done correctly, a challenger can point to a single step and force the prover to execute that leaf. If it doesnt match the commitment then they are cheating.

### Implementation

- While the proof of offchain payment could be any type of verifiable proof that can be verified tradiaionally in smart contracts, the example we are using here is a Venmo transfer confirmation email. But the logic looks the same if the proof was a deposit proof in a bridge contract on another chain.
- The venmo email can generate a groth16 proof (or even fflonk) using the zkemail library. See reference [implementation here](https://github.com/zkp2p/zk-p2p) for zk-p2p on Ethereum.
- Groth16 verification in [Bitvm](https://github.com/BitVM/BitVM/pull/71) produces 7gb of script. We can only break it down 1000 steps because each step needs to be precommitted to in one transaction that should fit the BTC block limit of 4MB. Obviously 7gb/1000 = 7MB exceeding the block limit. Robin suggested that there could be two sets of signatures for everything so we would get around 3.5MB leaves.
- How do we do the bitvm commitment? what transactions do we need?

### FAQ

- **Why we cant verify snark directly like any other smart contract platforms?**
- **Why do we need a market maker? why not do it directly?**