2024.6.10 - 2024.6.16

2024.6.10

The first developer meeting (Dev Call) of the BitVM project, during which the design of the BitVM2 bridge was updated.

Key Points:

1. Robin's next focus is on developing zkCoins rather than other sidechains. zkCoins will use client-side validation and ZK proof.

2. The original Kickoff transaction inhttps://bitvm.org/bitvm2has been split into two transactions: Kickoff1 and Kickoff2. The purposes are:

2.1 Kickoff1 is mainly for challengers to initiate a challenge, requiring the challenger to pay 1 BTC to the challenged Operator. If there is a challenge within 2 weeks + 3 days, the connector A output will be spent, invalidating the reimbursement path on the Take1 happy path. The challenger must see the Kickoff2 transaction before deciding whether to challenge.

2.2 The Operator must initiate the Kickoff2 transaction within 2 weeks of publishing the Kickoff1 transaction, otherwise, anyone can initiate a Kickoff Timeout transaction to penalize the Operator after 2 weeks + 1 day.

2.3 Kickoff2 commits to the "consensus state SB" on the L2 chain. Robin's focus is on communication between two PoW chains. He mentioned in the official Telegram group that this will be based on the 2017 paper "Non-Interactive Proofs of Proof-of-Work (NIPoPoW)" and that a new related paper will be released. The hash value of the "consensus state SB" will be used as the y value in the Assert transaction.

2.3.1 Within 3 days, if anyone disputes the "consensus state" in the [start_time, start_time + 2 weeks] period (indicating suspicion of the Operator cheating by using a forked chain) and can provide a new consensus state SB' with a higher weight, they can initiate a Disprove Chain transaction to penalize the Operator. In this case, the connector B output will be spent, invalidating the reimbursement path on the Take1 happy path.

2.3.2 If a challenge is initiated within 2 weeks + 3 days after Kickoff1, it means the connector A output is spent, invalidating the reimbursement path on the Take1 happy path.

• If the Operator does not initiate the Assert transaction, it means they give up the right to reimbursement using Take2. The Operator will lose 2 - 1 = 1 BTC. [The 2 BTC expenditure method on connector B output includes Take1, Assert, and Disprove Chain].

• If the Operator initiates the Assert transaction, it means they want to exercise the right to reimbursement using Take2:

• - If anyone finds inconsistencies in the Assert, they can initiate a Disprove transaction to penalize the Operator. In this case, the connector C output will be spent, invalidating the reimbursement path on the Take2 unhappy path.

• - If no one successfully initiates a Disprove transaction after 2 weeks, the Operator can initiate the Take2 transaction and get reimbursed successfully.

2.4 Compared to the BitVM2 version, a challenge phase for the "L2 consensus state SB" has been added — the Disprove Chain transaction. However, the incentive problem for challengers has not been solved. Challengers pay 1 BTC, and if successful, the profit still goes to miners, not the challenger themselves.

2.5 The Kickoff1 transaction uses an OP_CLTV absolute time lock. The reason is still uncertain; it may be because NIPoPoW requires an absolute block range for proof of work and comparison? However, this design may still have issues because Kickoff1 is pre-signed, and the actual time for future reimbursement is uncertain.