Skip to content

Latest commit

 

History

History
102 lines (82 loc) · 5.29 KB

README.md

File metadata and controls

102 lines (82 loc) · 5.29 KB

Introduction

A Clarity library for parsing Bitcoin transactions and verifying Merkle proofs

Based on work from Jude Nelson and from the team at Trust Maschine (in particular @FriendsFerdinand, @MarvinJanssen, @setzeus, @jo-tm).

Deployments on mainnet:

  • Version 5: Adds support for txid generation and improves security to reject left over data
  • Version 4: Adds support for segwit transactions
  • Version 3: Uses get-burn-block-info of Clarity V2 to verify txs in flash blocks
  • Version 2: Buggy - Do not use
  • Version 1: Initial version with no verification for tx in flash blocks

Branch (docs)[https://github.com/friedger/clarity-bitcoin/tree/docs] contains a gitbook: (Clarity <-> Bitcoin Library)[https://clarity-bitcoin.gitbook.io/clarity-bitcoin-library/].

Clarity Functions

The main function is about verifying that a non-segwit transaction was mined in a certain bitcoin block. The verification happens in two steps:

  1. compare the provided block header information with the actual chain
  2. compare the merkle root from the provided merkle proof with the merkle root of the provided block header

Was Tx Mined?

These are the main functions that can be used to verify that a tx was mined in a given bitcoin block.

The block header can be provided as an object with the header details or as a buffer.

  • was-tx-mined-compact (header as a buffer)
  • was-segwit-tx-mined-compact (header as buffer)

The two functions for non-segwit transaction take the following arguments in the same order:

  1. Bitcoin block height
  2. Raw tx hex
  3. Bitcoin block header either as hex or as a tuple
  4. Merkle proof

The header object has the following properties using the reverse hex of the shown values in the bitcoin explorer:

  • version: (buff 4)
  • parent: (buff 32)
  • merkle-root: (buff 32)
  • timestamp: (buff 4)
  • nbits: (buff 4)
  • nonce: (buff 4)

The function for segwit transaction takes the following arguments:

  1. Bitcoin block height
  2. Raw tx hex
  3. Bitcoin block header either as hex
  4. The index of the tx in the block
  5. The Merkle tree depth of the block
  6. The Merkle proof for witness data
  7. The Merkle root for witness data stored in the coinbase tx of the block
  8. The reserved data value used in the coinbase tx
  9. The coinbase tx in non-segwit format
  10. The Merkle proof of the coinbase tx

Verification Functions for Non-Segwit Transactions in Bitcoin Block

The verification happens in two steps:

  1. verify that the hash of the given header is equal to the header hash of the given block height.
  2. verify that the given merkle proof for the given transaction id results in the merkle root contained in the header.
  • verify-block-header
  • verify-merkle-proof

Verification Functions for Segwit Transactions in Bitcoin Block

The verification happens in two steps:

  1. verify that the coinbase tx was mined using the verification for non-segwit transactions as described above.
  2. verify that the Merkle root for witness data is contained in the coinbase tx.
  3. verify that the Merkle proof for witness data is valid for the wtxid of the transaction.
  • get-commitment-scriptPubKey

Helper Function for Tx Verification

Once the tx id was confirmed to be mined in the given block, the inputs and outputs of the tx can be used to trigger certain actions in a smart contract. To verify e.g. that an input is indeed an input of the verified tx id, the hash of a transaction buffer must match the tx id. Then the inputs and outputs of the transaction can be used either

  • by parsing the transaction buffer into an object with inputs, outputs, timelock, etc. or
  • by concatenating the transaction object to a buffer with the correct hash.

Examples

As requirements, clarinet and deno needs to be installed.

Send to First Input

This example sends an amount of STX to the sender of a bitcoin transaction using p2pkh addresses. It exists in two version, one using the header object, the other the header buffer (compact).

  1. Deploy all contracts
clarinet integrate
  1. Call deployment plan to send 0.1 BTC
clarinet deployments apply -p deployments/send-btc.devnet-plan.yaml --no-dashboard
  1. Confirm to continue
  2. Copy the tx hex from the Transaction
  3. Press N to mine the block in the clarinet dashboard
  4. Generate deployment plan for the stacks transaction by running the following command with the copied tx hex (replace 01..txhex). (The generation script takes care of reversing the properties of the block header.)
deno run --allow-net ./src/generatePlan.ts 01..txhex > deployments/send-to-first-input-plan.yaml
  1. Call deployment plan to send STX to the bitcoin sender
clarinet deployments apply -p deployments/sent-to-first-input-plan.yaml
  1. Check the stacks explorer at localhost: 8001 about the result for the transactions of the two versions