BitSync: New Decentralized Layer 2 Sidechain Design for BitVM

Hey Bitcoin fans and devs, I’m pumped to share a detailed theoretical analysis and a prototype pre-implementation of BitSync, a cool Layer 2 sidechain setup aimed at boosting Bitcoin’s features while keeping its security intact. BitSync tackles the ongoing issues of scalability and programmability in Bitcoin without messing with decentralization, requiring hard forks, or adding new trust issues. Quick Tech Breakdown: Real-Time Sync with Bitcoin: BitSync establishes a strong connection with Bitcoin using a two-way referencing system. Each BitSync block SC_j has a field H_B_i that holds the hash of the latest Bitcoin block B_i. On the flip side, Bitcoin miners add a commitment to the latest BitSync block hash H_SC_j in their coinbase transactions. This mutual commitment makes sure both chains are in sync regarding their state when a block is created, effectively blocking any manipulation from private forks. Auxiliary Proof-of-Work (AuxPOW) Integration: BitSync introduces a tweaked AuxPOW protocol that lets Bitcoin miners secure both chains at the same time. Some key elements include: a) Chain ID (c): A unique tag for BitSync, ensuring clear commitments. b) Chain Merkle Tree: This is part of Bitcoin’s coinbase transaction scriptSig and holds commitments to the auxiliary chain block hashes. c) getExpectedIndex Function: This function figures out the expected index i in the chain Merkle tree for a specific chain ID c, nonce n, and tree height h. AuxPOW Validation Process: Verify Bitcoin block header B.

Interesting. Looks a bit similar to Paul Sztorc's Drivechain and other early sidechain ideas, but using some newer technologies to make it possible. Basically it looks like an implementation of the Bridge protocol mentioned in the BitVM2 whitepaper, specifically using the AuxPOW (merged mining) method for the sidechain consensus. But I assume that due to its usage of BitVM, it would not need to introduce new opcodes (correct me if I'm wrong), e.g. for covenants (or Drivechain's OP_ACK), and instead rely on principles similar to optimistic rollups. Thus I don't understand why OP_BLOCKHASH would be needed as an additional opcode. Can't you "simulate" it via a "BitVM program"? My understanding is that you can create arbitrary programs with Bitcoin Script using BitVM2, but my understanding is not very deep. On page 20 of the BitVM2 Bridge whitepaper (the one linked above) there is a proposal how to emulate OP_BLOCKHASH. I'm not an IT expert but have analyzed some L2 designs from a semi-layman perspective here and this would definitely fit in this thread, so I may try to write a ELI5 on it. Would love to see this implemented ... PS: An older design (from March, thus probably still with BitVM1) had already a thread here: https://bitcointalk.org/index.php?topic=5489872.0