DEV Community: k0k0ne

Understand Witness of Bitcoin -- A developer's view

k0k0ne — Mon, 18 Nov 2024 04:10:19 +0000

Understanding the witness concept is crucial for developers working with Bitcoin. However, most discussions focus on a general perspective. In this post, let's delve deeper into the details.

Witness

A witness refers to the part of a transaction that contains the unlocking scripts (also known as signatures or witness data) necessary to prove ownership of the funds being spent. This concept was introduced with the SegWit upgrade (BIP141) to help solve transaction malleability and improve scalability by segregating (separating) the signature data from the transaction data.

Key Points

A witness is a part of a tx.
Old tx HAS "witness": A witness is the object that contains unlocking scripts (signatures or witness data)

{
  "version": 1,
  "marker": 0,
  "flag": 1,
  "inputs": [
    {
      "previous_tx": "abcd1234...",
      "index": 0,
      "scriptSig": "",
      "sequence": 4294967295
    }
  ],
  "outputs": [
    {
      "value": 5000000000,
      "scriptPubKey": "76a914...88ac"
    }
  ],
  "witness": [
    "3045022100...022f01e5..."
  ],
  "locktime": 0
}

Above we have an example of transitional bitcoin tx. scriptSig contains the signature and public key needed to unlock the output being spent, alike witness, while in a narrow definition, witness is a separate component in SegWit transactions.

Here is an example:

For a Segwit Tx: Witness is saved separately.

{
  "version": 1,
  "marker": 0,
  "flag": 1,
  "inputs": [
    {
      "previous_tx": "abcd1234...",
      "index": 0,
      "scriptSig": "",
      "sequence": 4294967295
    }
  ],
  "outputs": [
    {
      "value": 5000000000,
      "scriptPubKey": "76a914...88ac"
    }
  ],
  "witness": [
    "3045022100...022f01e5..."
  ],
  "locktime": 0
}

In a SegWit transaction, the witness data is stored separately from the traditional parts of the transaction. The overall structure of a SegWit transaction includes:

Transaction Version
Marker and Flag: Indicate the presence of witness data.
Input and Output Lists: As in traditional transactions.
Witness Data: Contains the actual witness for each input.
Locktime

This separation means that the witness data does not affect the transaction's hash used for identifying the transaction, addressing the malleability issue.

How is the Witness Constructed and Used?

Construction

When creating a SegWit transaction, the witness is constructed by providing the necessary unlocking scripts for each input. Typically, this includes a signature and a public key for P2WPKH (Pay-to-Witness-Public-Key-Hash) transactions.

Usage:

Verification: Nodes and miners use the witness data to verify that the spender has the right to spend the UTXO.
Storage: Witness data is stored in the witness section of the transaction but can be pruned or segregated to save space.
Weight Units: In calculating the transaction's weight, witness data is given a lower weight, incentivizing the use of SegWit.

Viewing the Witness Data

After constructing and signing the transaction, you can inspect the witness data using a tool like Bitcoin Core's decoderawtransaction or online explorers that support SegWit.

For example:

bitcoin-cli decoderawtransaction <serialized_tx>

This command will output the transaction details, including the vout, vin, and crucially the witness field for each input, showing the signature and public key used to unlock the funds.

(1) Overall structure / RGB Protocol Source Explained

k0k0ne — Sat, 16 Nov 2024 13:17:15 +0000

Introduction

As a cryptography enthusiast, I am excited to launch a new series of articles that delve into the details of how the RGB protocol works.

In this chapter, we'll begin by outlining the overall structure of the RGB project.

Ecosystem

The RGB-WG/rgb project is structured as a comprehensive ecosystem of Rust libraries and tools, designed to support the development and operation of RGB smart contracts on the Bitcoin and Lightning networks. Here's an overview of the project structure, aimed at developers who are interested in learning about the RGB project:

Core Libraries and Tools:
- AluVM/rust-aluvm: A functional registry-based RISC virtual machine, which serves as a foundational component for executing smart contracts.
- BlockstreamResearch/secp256k1-zkp: A cryptographic library providing elliptic curve operations, essential for secure key management and transaction signing.
- BP-WG/bp-core: The core library for the Bitcoin Protocol, offering fundamental building blocks for blockchain interactions.
- BP-WG/bp-std: A standard library extending bp-core, providing additional functionality for Bitcoin protocol operations.
- BP-WG/bp-wallet: A minimalistic and standard-compliant Bitcoin wallet, integral for managing assets and transactions within the RGB ecosystem.
Smart Contract Infrastructure:
- LNP-BP/client_side_validation: A library for client-side validation of smart contracts, ensuring security and correctness in contract executions.
- RGB-WG/rgb-core: The core library for RGB smart contracts, handling the consensus layer and providing essential smart contract functionalities.
- RGB-WG/rgb-interfaces: A collection of standard RGB smart contract interfaces, facilitating the development of interoperable contracts.
- RGB-WG/rgb-schemata: Official schemata for RGB smart contracts, defining the structure and data models for contracts.
Utilities and Supporting Libraries:
- rust-amplify/rust-amplify: A library amplifying Rust's capabilities with additional generic trait implementations and type wrappers.
- strict-types/strict-encoding: A library for strict data encoding, ensuring data integrity and correctness in serialization processes.
- strict-types/strict-types: Provides strict types for confined generalized algebraic data types (GADT), enhancing type safety in Rust applications.
- UBIDECO/ascii-armor: A utility for ASCII armor encoding, useful for binary-to-text encoding of data.
- UBIDECO/rust-baid64: A library for URL-safe Base64 encoding, particularly useful for identity and data encoding in URLs.
Final Product:
- RGB-WG/rgb: The ultimate product project, integrating all the above components to provide a complete solution for developing, deploying, and managing RGB smart contracts on Bitcoin and Lightning networks.

Main Dependencies

AluVM/rust-aluvm
- amplify
- ascii-armor (optional)
- baid64
- paste
- strict_encoding
- strict_types (optional)
- sha2
- blake3
- ripemd
- secp256k1 (optional)
- curve25519-dalek (optional)
- half
- serde_crate (optional)
BlockstreamResearch/secp256k1-zkp
- (ignore)
BP-WG/bp-core
- workspace.dependencies:
  - amplify
  - strict_encoding
  - strict_types
  - commit_verify
  - single_use_seals
  - bp-consensus
  - bp-dbc
  - bp-seals
  - secp256k1
  - serde_crate
- [bp-core] dependencies:
  - amplify
  - strict_encoding
  - strict_types (optional)
  - commit_verify
  - single_use_seals
  - bp-consensus
  - bp-dbc
  - bp-seals
  - serde_crate (optional)
BP-WG/bp-std
- workspace.dependencies:
  - amplify
  - bech32
  - secp256k1
  - strict_encoding
  - commit_verify
  - bp-consensus
  - bp-core
  - bp-invoice
  - bp-derive
  - descriptors
  - psbt
  - indexmap
  - serde_crate
- [bp-std] dependencies:
  - amplify
  - secp256k1
  - bp-consensus
  - bp-core (optional)
  - bp-invoice
  - bp-derive
  - descriptors
  - psbt
  - serde_crate (optional)
BP-WG/bp-wallet
- workspace.dependencies:
  - amplify
  - nonasync
  - bp-std
  - psbt
  - descriptors
  - bp-esplora
  - bp-electrum
  - serde_crate
  - serde_json
  - serde_yaml
  - toml
- [bp-wallet] dependencies:
  - amplify
  - nonasync
  - strict_encoding
  - bp-std
  - bp-esplora (optional)
  - bp-electrum (optional)
  - psbt
  - descriptors
  - sha2
  - rand (optional)
  - rpassword (optional)
  - aes-gcm (optional)
  - bip39 (optional)
  - serde_crate (optional)
  - serde_json (optional)
  - serde_yaml (optional)
  - toml (optional)
  - log
  - colored (optional)
LNP-BP/client_side_validation
- workspace.dependencies:
  - amplify
  - strict_encoding
  - strict_types
- [client_side_validation] dependencies:
  - commit_verify
  - single_use_seals
  - serde_crate (optional)
RGB-WG/rgb-core
- amplify
- baid64
- strict_encoding
- strict_types
- aluvm
- commit_verify
- single_use_seals
- bp-core
- secp256k1-zkp
- mime
- serde_crate (optional)
- chrono
RGB-WG/rgb-interfaces
- amplify
- strict_encoding
- strict_types
- aluvm
- bp-core
- rgb-std
- chrono
- serde_crate (optional)
- serde_json
RGB-WG/rgb-schemata
- amplify
- strict_encoding
- strict_types
- aluvm
- bp-core
- rgb-std
- rgb-interfaces
- chrono
- serde
- serde_json
- sha2
RGB-WG/rgb
- workspace.dependencies:
  - amplify
  - nonasync
  - baid64
  - strict_encoding
  - strict_types
  - commit_verify
  - bp-core
  - bp-std
  - bp-electrum
  - bp-esplora
  - bp-wallet
  - rgb-std
  - rgb-psbt
  - indexmap
  - chrono
  - serde_crate
  - serde_yaml
  - log
- [rgb-runtime] dependencies:
  - amplify
  - nonasync
  - baid64
  - bp-electrum (optional)
  - commit_verify
  - strict_types
  - bp-core
  - bp-std
  - bp-esplora (optional)
  - bp-wallet
  - rgb-std
  - rgb-psbt
  - indexmap
  - chrono
  - serde_crate (optional)
  - serde_yaml (optional)
  - log (optional)
rust-amplify/rust-amplify
- libc (optional)
- amplify_derive (optional)
- amplify_syn (optional)
- amplify_num
- amplify_apfloat (optional)
- ascii
- rand (optional)
- serde_crate (optional)
- stringly_conversions (optional)
strict-types/strict-encoding
- amplify
- serde_crate
strict-types/strict-types
- amplify
- ascii-armor (optional)
- baid64 (optional)
- strict_encoding
- vesper-lang
- indexmap
- sha2
- serde (optional)
- serde_json (optional)
- serde_yaml (optional)
- toml (optional)
UBIDECO/ascii-armor
- amplify
- strict_encoding (optional)
- baid64 (optional)
- base64 (optional)
- base85 (optional)
- sha2
UBIDECO/rust-baid64
- amplify
- base64
- sha2
- mnemonic

Futhermore

In the subsequent chapters, I'll select topics to explore in depth. Due to my busy schedule, the topics will be chosen randomly but will cover the material from the ground up.