● Introduction

● Background

○ Bitcoin and the Lightning Network

○ Nostr Protocol

● Anti-Spam Measures

● Defined Event Types

● Comprehensive Transaction Workflow

● Escrow Mechanism in DOMP

○ Overview

○ Detailed Process with Code Examples

● Reputation System

○ Storage and Reference

○ Reputation Calculation

● Arbitration

● Scenarios Demonstrating Potential Exchanges

○ Scenario 1: Successful Transaction

○ Scenario 2: Buyer Does Not Confirm Receipt

○ Scenario 3: Seller Fails to Ship the Item

○ Scenario 4: Arbitration for Dispute Resolution

● Potential Attack Vectors

● Conclusion

Abstract

The Decentralized Online Marketplace Protocol (DOMP) introduces a framework for secure, trustless, and transparent transactions within decentralized online marketplaces. Leveraging Bitcoin’s robustness, the Lightning Network’s efficiency, and the Nostr protocol’s flexibility, DOMP eliminates intermediaries and enhances user trust through innovative mechanisms such as a dual-collateral system, a reputation framework, and an optional arbitration process. By defining specific event types to structure interactions, DOMP ensures secure fund management and mitigates fraud risks inherent in decentralized commerce.

Unlike existing protocols, DOMP uniquely addresses challenges of trust and security without relying on third-party escrow services. It employs a combination of cryptographic proofs and mutual agreements to establish an escrow mechanism at the protocol level. Additionally, DOMP implements market-driven anti-spam measures, allowing relays to set their own policies based on network conditions, thereby enhancing resilience and adaptability.

By detailing transaction workflows, escrow mechanisms, reputation systems, and mitigation strategies against potential attack vectors, DOMP aims to provide a comprehensive solution for peer-to-peer commerce. It advances the vision of a decentralized marketplace where participants can transact with some amount of confidence and free from censorship.

Background

Bitcoin and the Lightning Network

Bitcoin, introduced in 2009, is a decentralized digital currency that enables peer-to-peer transactions without the need for a central authority or intermediary. Its blockchain technology ensures transparency, security, and immutability of transactions. However, Bitcoin’s scalability limitations and transaction fees present challenges for high-frequency or microtransaction-based applications, such as online marketplaces.

The Lightning Network (LN) addresses these challenges by introducing an off-chain payment protocol that allows for near-instantaneous and low-fee transactions. By establishing bi-directional payment channels between users, LN enables multiple transactions to occur off the main blockchain, reducing congestion and fees. This scalability solution makes LN particularly well-suited for handling the microtransactions allowing for more flexible client integrations in the future like the possibility of streaming data, CPU cycles, and more.

The Nostr Protocol

Nostr (Notes and Other Stuff Transmitted by Relays) is a decentralized, open-source protocol designed for creating and propagating events across a distributed network of relays. Unlike traditional centralized platforms, Nostr operates without central servers, relying instead on a network of relays that store and forward messages. Users publish and subscribe to events using public and private key cryptography, ensuring data integrity and user privacy.

Nostr’s resilience against censorship and its flexible, event-driven architecture make it an ideal choice for DOMP’s communication layer. By utilizing Nostr, DOMP facilitates direct interactions between marketplace participants without reliance on centralized infrastructure. As of 2024, Nostr has gained significant traction within the decentralized application community, with growing adoption due to its simplicity and effectiveness in enabling decentralized social networks and communication platforms. Its compatibility with DOMP ensures that the protocol can leverage existing Nostr infrastructure while contributing to its ecosystem.

Anti-Spam Measures

In decentralized networks, spam and malicious activities can degrade user experience and network performance. To maintain network integrity and prevent abuse, DOMP incorporates a combination of anti-spam measures. 

1. Lightning Network (LN) Payments:
   DOMP Clients (or individual Nostr Relays) may require small LN payments to incentivize relays for handling and retaining specific events. This economic disincentive increases the cost of spamming, making it financially unattractive for attackers. Users can also rate relays (see section: reputation system) based on reliability, creating a market-driven ecosystem where high-quality relays are rewarded accordingly.
2. Proof of Work (PoW) via NIP13:
   DOMP Clienst (or individual Nostr Relays) may utilize PoW as an alternative, or in addition to, to LN payments, allowing users to perform computational challenges as a resource-based proof. This method is akin to mechanisms used in systems like Hashcash to prevent spam and denial-of-service attacks. Using the Nostr NIP13 standard, DOMP ensures compatibility with existing Nostr implementations. This approach provides users without access to the Bitcoin or Lightning Networks a way to participate, enhancing inclusivity.
3. Hashing and Event Referencing:
   To prevent abuse of the reputation system, DOMP requires certain events—primarily reputation events—to include hashes of valid previous events signed by the user. This ensures that only participants involved in legitimate transactions can influence reputation scores. This method mitigates the risk of Sybil attacks, where an attacker might create multiple fake identities to manipulate the system, a common issue in decentralized protocols.
4. Relay-Determined Anti-Spam Policies:
   Instead of enforcing a one-size-fits-all solution, DOMP allows individual relays to set their own anti-spam requirements, including PoW difficulty or LN payment amounts. This market-driven approach is similar to how email servers implement their own spam filters and policies. It enables relays to adjust their policies based on network conditions, demand, and their capacity, promoting flexibility and resilience. Users can select relays that balance strictness and accessibility according to their preferences.

Comparison with Existing Protocols:

DOMP’s hybrid approach combines economic incentives and computational proofs.  DOMP’s strategy enhances security and accessibility by reducing barriers to entry while effectively discouraging spam and malicious behavior. By allowing relays to set their own policies, the protocol adapts to varying network conditions and user needs.

Defined Event Types

DOMP defines specific event types to structure interactions within the marketplace. Each event includes mandatory fields such as id, pubkey, created_at, sig, and references to previous events where applicable.

Listing and Bidding

• kind-300: Product Listing: Sellers list products for sale, including details and anti-spam proof.
• kind-301: Bid Submission: Buyers place bids referencing the kind-300 listing.
• kind-302: Counter Bid: Used by either party to propose revised terms during negotiations. This event references a previous bid or counter bid and includes LN invoice and collateral information.
• kind-303: Bid Acceptance: Indicates unconditional acceptance of the bid with the original terms.

Note on Merging kind-302 and kind-303: While combining these event types was considered, and could simplify the protocol, we’ve chosen to keep them separate to enhance clarity and user confidence. Having distinct event types allows users to immediately recognize whether terms have changed (kind-302) or if a bid is accepted as-is (kind-303), reducing the risk of misunderstandings.

Payments, Escrow, and Completion

• kind-310: Collateral Deposit: Logs when a seller deposits collateral.
• kind-311: Payment Confirmation: Buyers confirm payment, activating escrow. This event references collateral deposits from both parties for verification.
• kind-312: Escrow Dispute: Initiated by either party seeking release of funds.
• kind-313: Receipt Confirmation: Buyers confirm item receipt, releasing escrowed funds.
• kind-314: Refund Initiation: Sellers initiate a refund if required.
• kind-315: Mutual Agreement: Logs mutual consent to release funds or cancel the transaction.
• kind-316: Arbitration Offer: A third-party user offers to arbitrate the dispute.

Communication and Feedback

• kind-320: Communication Message: General communication between parties, such as messages, notifications, or updates. Requires PoW, LN payment, or cryptographic link.
• kind-321: User Reputation Feedback: Post-transaction ratings, enhancing transparency. Must reference specific prior events to validate the feedback.
• kind-322: Arbitrator Reputation Feedback: Ratings for arbitrators after dispute resolution.
• kind-323: Relay Reputation Feedback: Ratings for relays based on service quality.

Comprehensive Transaction Workflow

DOMP’s workflow is designed to streamline interactions between buyers and sellers, using well-defined steps and events. Below, we include code samples for each event kind and discuss the reasoning behind certain design choices.

Step 1: Product Listing by Seller (kind-300)

• Upload Product Details: Sellers provide descriptions and images using HTML links or IPFS Content Identifiers (CIDs).
• Relay Selection and Compensation: Sellers choose multiple Nostr relays to publish their product listings, compensating them according to each relay’s anti-spam requirements.
• Event Broadcasting: Sellers broadcast the kind-300 event containing product details and anti-spam proofs.

{

  “kind”: 300,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000000,

  “tags”: [

    [“anti_spam_proof”, “LN_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”product_name\”: \”Digital Camera\”, \”description\”: \”A high-quality DSLR camera.\”, \”price_satoshis\”: 80000000, \”storage_link\”: \”ipfs://CID\”}”,

  “id”: “event_id_300”,

  “sig”: “signature_seller_300”

}

Step 2: Seller Posts Collateral (kind-310)

• Seller Posts Collateral First: To build buyer confidence and demonstrate commitment, the seller deposits their collateral before the buyer proceeds. This reduces the risk of the seller trolling and encourages serious participation.  Since the seller can refund all funds (including their own collateral) if the buyer stops participating, this poses no additional risk to the seller.
• Sequence: This event would likely be done in conjunction with a kind-300 listing.  It is not necessarily required by the protocol, but may be required by application clients.  As a buyer it would be wise to make sure a seller has posted their collateral to before committing any funds to escrow to make sure the seller has “skin in the game” and cannot just freeze buyers’ funds in escrow as a way to troll online.
• Collateral Amounts:  We imagine seller collateral would generally be a lot less than for buyers since the seller’s collateral is primarily just a spam and trolling control mechanism.  In my thought experiments we usually considered 10% of the purchase price sufficient, although for very large sale prices less would probably suffice, and vice versa for very small sale prices.

{

  “kind”: 310,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000050,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_seller_collateral”]

  ],

  “content”: “{\”product_ref\”: \”event_id_300\”, \”collateral_amount_satoshis\”: 8000000}”,

  “id”: “event_id_310_seller”,

  “sig”: “signature_seller_310”

}

Step 3: Buyer Submits a Bid (kind-301)

• Bid Discovery: Buyers find products via subscribing to kind-300 events.  Realistically this would be done through clients who specialize in these kinds of interactions, but could theoretically be done manually by a user.
• Bid Submission: Buyers submit a kind-301 event referencing the product and including their proposed terms and collateral amount.
• Collateral Amounts:  Typically, buyer collateral will likely be higher than than that of sellers, as it is meant to incentivizethe buyer to confirm receipt of the item and release purchas funds to the seller.
• Relay Verification: Relays process the bid according to their anti-spam policies.

{

  “kind”: 301,

  “pubkey”: “buyer_pubkey”,

  “created_at”: 1620000100,

  “tags”: [

    [“anti_spam_proof”, “LN_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”product_ref\”: \”event_id_300\”, \”bid_amount_satoshis\”: 80000000, \”buyer_contact\”: \”buyer_pubkey\”, \”collateral_amount_satoshis\”: 80000000}”,

  “id”: “event_id_301”,

  “sig”: “signature_buyer_301”

}

Step 4: Seller Responds to the Bid

Option 1: Accept the Bid (kind-303)

• Bid Acceptance: The seller accepts the bid without changing any terms.
• Establishing Escrow: The LN invoice included in the kind-303 event is used by the buyer to make the payment. This payment, along with the buyer’s collateral, is held in escrow until the transaction is completed. The escrow is established through the protocol’s agreement between the buyer and seller, referencing the payment and collateral events.

{

  “kind”: 303,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000200,

  “tags”: [

    [“anti_spam_proof”, “lnbc1invoice_seller”]

  ],

  “content”: “{\”bid_ref\”: \”event_id_301\”, \”ln_invoice\”: \”lnbc1invoice_seller\”, \”seller_collateral_ref\”: \”event_id_310_seller\”}”,

  “id”: “event_id_303”,

  “sig”: “signature_seller_303”

}

Option 2: Propose a Counter Bid (kind-302)

• Counter Bid: The seller proposes new terms, possibly adjusting the price or collateral requirements.

{

  “kind”: 302,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000200,

  “tags”: [

    [“anti_spam_proof”, “lnbc1invoice_seller”]

  ],

  “content”: “{\”bid_ref\”: \”event_id_301\”, \”counter_offer_satoshis\”: 85000000, \”ln_invoice\”: \”lnbc1invoice_seller\”, \”seller_collateral_ref\”: \”event_id_310_seller\”}”,

  “id”: “event_id_302”,

  “sig”: “signature_seller_302”

}

Step 5: Buyer’s Response to Seller

Option 1: Accepting the Bid (kind-311)

• Accepting: If the seller accepted the bid (kind-303), the buyer proceeds to deposit their collateral and confirm payment with a kind-311 event.  This would include the buyers agreed upon collateral as well as the agreed upon sale price.
• Collateral Verification: Before proceeding, both parties verify that the collateral amounts match the agreed terms by referencing the kind-310 events in the kind-311 event.
• Escrow Activation: The buyer’s payment and both parties’ collateral are now held in escrow. Either a LN HTLC or on-chain 2-of-2 multi-sig transaction can be used for escrow depending on the circumstance.

Buyer’s Payment Confirmation (kind-311)

{

  “kind”: 311,

  “pubkey”: “buyer_pubkey”,

  “created_at”: 1620000300,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_buyer_payment”]

  ],

  “content”: “{\”bid_ref\”: \”event_id_303_or_302\”, \”payment_method\”: \”htlc\”, \”payment_proof\”: \”ln_payment_hash_buyer_payment\”, \”collateral_amount_satoshis\”: 80000000, \”collateral_payment_proof\”: \”ln_payment_hash_buyer_collateral\”, \”seller_collateral_ref\”: \”event_id_310_seller\”}”,

  “id”: “event_id_311”,

  “sig”: “signature_buyer_311”

}

Option 2: Responding to a Counter Bid (kind-302)

• Responding to a Counter Bid: Alternatively, the buyer can propose another counter bid (kind-302).  Repeats step 4.

Step 6: Transaction Completion and Escrow Handling

• Seller Ships the Item: The seller fulfills their obligation by shipping the item.

Seller Notifies Buyer of Shipment (kind-320)

• Communication: The seller uses a kind-320 event to inform the buyer that the item has been shipped, providing tracking information if available.

{

  “kind”: 320,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000400,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”message\”: \”Item has been shipped. Tracking number: XYZ123\”, \”ref\”: \”event_id_311\”}”,

  “id”: “event_id_320_seller”,

  “sig”: “signature_seller_320”

}

Step 7: Receipt Confirmation (kind-313)

• Buyer Confirms Receipt: Upon receiving the item, the buyer confirms receipt, triggering the release of all funds.  Collateral payments are refunded to both originators, and sale funds are released to the seller.
• Automatic Release: Upon receipt confirmation, the escrowed payment and collateral are released to the seller and buyer, respectively.
• No Third-Party Involvement: The release is managed by the protocol rules and enforced by the clients’ software.  This is because there is no reliable way to prove receipt of a physical object at the protocol level.  Any attempt to do this would inevitably lead to potential for buyers or sellers to defraud the other party.  There is the potential for disputes by third parties, but those are largely relegated to off protocol.

{

  “kind”: 313,

  “pubkey”: “buyer_pubkey”,

  “created_at”: 1620000800,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_buyer_payment”]

  ],

  “content”: “{\”payment_ref\”: \”event_id_311\”, \”status\”: \”received\”}”,

  “id”: “event_id_313”,

  “sig”: “signature_buyer_313”

}

Step 8: Reputation Feedback (kind-321)

• Feedback Submission: Both parties submit feedback, contributing to each other’s reputation scores.
• Mandatory Reference to Previous Events: To prevent abuse, the kind-321 event must reference a specific previous event, and each transaction can only be referenced once in reputation events.

Requirements for kind-321:

• Rating a Seller: The buyer must include a reference to a valid kind-313 (Receipt Confirmation), kind-314 (Refund Initiation), or kind-315 (Mutual Agreement) event to prove they were involved in the transaction.
• Rating a Buyer: The seller must include a reference to a valid kind-313 (Receipt Confirmation), kind-314 (Refund Initiation), or kind-315 (Mutual Agreement) event.
• One Feedback per Transaction: Each referenced event can only be used once for a valid kind-321 rating to prevent multiple ratings from the same transaction.

Explanation:

• user_pubkey: The public key of the user being rated.
• transaction_ref: The ID of the referenced event (e.g., kind-313).
• transaction_kind: The kind of the referenced event.
• Validation: Clients must verify that the transaction_ref corresponds to a valid event of the specified kind and that it has not been used in another kind-321 event by the same rater.

Code Sample for Rating a Seller:

{

  “kind”: 321,

  “pubkey”: “buyer_pubkey”,

  “created_at”: 1620000900,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”user_pubkey\”: \”seller_pubkey\”, \”rating\”: 5, \”comment\”: \”Excellent transaction. Highly recommended.\”, \”transaction_ref\”: \”event_id_313\”, \”transaction_kind\”: 313}”,

  “id”: “event_id_321_buyer”,

  “sig”: “signature_buyer_321”

}

Code Sample for Rating a Buyer:

{

  “kind”: 321,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000950,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”user_pubkey\”: \”buyer_pubkey\”, \”rating\”: 5, \”comment\”: \”Prompt payment and good communication.\”, \”transaction_ref\”: \”event_id_313\”, \”transaction_kind\”: 313}”,

  “id”: “event_id_321_seller”,

  “sig”: “signature_seller_321”

}

Escrow Mechanism in DOMP

Overview

The escrow mechanism in DOMP is a critical component that ensures secure and trustless transactions between buyers and sellers without requiring a third-party escrow agent or relying on built-in escrow functionality within the Lightning Network (LN). Instead, DOMP implements escrow at the protocol level using cryptographic proofs, mutual agreements, and strict adherence to protocol rules enforced by client software.

Key Characteristics of the DOMP Escrow Mechanism:

• Protocol-Level Implementation: Escrow is managed through DOMP’s defined event types and workflow.
• No Third-Party Custody: Funds are not held by a third party but are controlled by the protocol rules and cryptographic agreements between buyer and seller.
• Mutual Assurance through Collateral: Both parties post collateral, incentivizing honest behavior and commitment to the transaction.
• Event-Driven Control: Specific events trigger changes in the state of the escrow, such as releasing funds upon buyer confirmation.
• Client Enforcement: Client software enforces the protocol rules, ensuring compliance and preventing unauthorized actions.

Detailed Process with Code Examples

Below is a step-by-step explanation of how the escrow mechanism works within DOMP, including code examples to illustrate each stage.

Step 1: Seller Lists the Product (kind-300)

Step 2: Seller Posts Collateral (kind-310)

Step 3: Buyer Submits a Bid (kind-301)

Step 4: Seller Accepts the Bid (kind-303)

Step 5: Buyer Deposits Collateral and Makes Payment

Buyer’s Collateral Deposit and Payment Confirmation (kind-311)

Explanation:

• The buyer confirms that the payment has been made by providing the payment_proof (the hash of the LN payment).
• The buyer_collateral_ref and seller_collateral_ref fields reference the collateral deposits made by both parties.
• This event effectively locks the funds (payment and both collaterals) into the protocol’s escrow mechanism.

How the Escrow Is Established:

1. Mutual Agreement and Protocol Enforcement:
   • By referencing the same bid_ref and collateral events, both parties agree to the terms of the transaction.
   • The protocol rules dictate that funds are now considered in escrow and cannot be unilaterally accessed by either party.
2. Client Software Role:

1. Clients enforce the protocol by preventing users from accessing funds in escrow until the appropriate conditions are met.
2. They monitor the Nostr network for relevant events and update the transaction state accordingly.
3. Use of Cryptographic Proofs:

1. Payment proofs and digital signatures ensure the authenticity of transactions.
2. The use of event IDs and references creates an immutable chain of events that can be verified by both parties.

Step 6: Escrow Activation

• Funds Held Securely: The buyer’s payment and both parties’ collateral are now held in escrow as per the protocol rules.

Step 7: Seller Ships the Item

• The seller, assured that the funds are secured in escrow, proceeds to ship the item.

Step 8: Seller Notifies Buyer of Shipment (kind-320)

Step 9: Buyer Confirms Receipt (kind-313)

Step 10: Funds and Collateral Release

• Triggered by kind-313: The buyer’s receipt confirmation signals that the conditions for releasing funds are met.
• Client Enforcement: Clients update the transaction state, allowing the seller to access the payment and both parties to retrieve their collateral.
• No Third-Party Intervention Required: The protocol and client software handle the release based on the events recorded.

Example Code Flow for Escrow Handling

1. Escrow Initialization:

• Buyer and Seller Collateral Deposits (kind-310 and kind-311):
  • Both parties’ collaterals are associated with the transaction through their respective kind-310 (for seller) and kind-311 (for buyer) events.
  • The payment_proof in these events verifies that the collateral has been paid via LN.
• Payment Confirmation (kind-311):
  • The buyer’s payment for the item is confirmed.
  • References to both collateral events are included, linking all funds to the transaction.

2. Escrow Locking Mechanism:

• Protocol Rules:
  • Funds are considered locked once the kind-311 event is published.
  • Clients enforce that these funds cannot be accessed until a kind-313 (Receipt Confirmation), Kind-314 (Refund  Initiation), or kind-315 (Mutual Agreement) event occurs.
• Event Chain Verification:
  • Each event includes references to previous events, creating a verifiable chain.
  • This ensures that all parties have fulfilled their obligations up to this point.

3. Escrow Release Conditions:

• Receipt Confirmation (kind-313):
  • Upon the buyer’s confirmation, clients recognize that the transaction is complete.
  • Funds are released according to the protocol: the seller receives the payment, and both parties retrieve their collateral.
• Alternative Release through Mutual Agreement (kind-315):
  • If both parties agree to cancel the transaction, they can release funds back to their original owners.

4. Example Client-Side Enforcement Logic:

def handle_event(event):

    if event.kind == 311:  # Payment Confirmation

        escrow = create_escrow(event)

    elif event.kind == 313:  # Receipt Confirmation

        escrow = get_escrow(event[‘content’][‘payment_ref’])

        if escrow and escrow.is_active:

            release_funds(escrow)

    elif event.kind == 315:  # Mutual Agreement

        escrow = get_escrow(event[‘content’][‘payment_ref’])

        if escrow and escrow.is_active and mutual_agreement(event):

            refund_funds(escrow)

def create_escrow(event):

    # Verify payment and collateral proofs

    # Lock funds in escrow

    return EscrowObject(…)

def release_funds(escrow):

    # Transfer payment to seller

    # Return collaterals to both parties

    escrow.is_active = False

def refund_funds(escrow):

    # Return payment and collaterals to original parties

    escrow.is_active = False

def mutual_agreement(event):

    # Check that both parties have agreed to the terms

    return True  # Simplified for illustration

5. Security and Integrity:

• Cryptographic Verification:
  • All events are signed by the respective parties, ensuring authenticity.
  • Payment proofs and references prevent fraudulent claims.
• No Central Authority Needed:
  • The protocol and client software handle all aspects of the escrow, maintaining decentralization.

Example Playthrough Summary:

• Initiation:
  • Seller lists item and posts collateral.
  • Buyer submits bid.
• Agreement:
  • Seller accepts bid.
  • Buyer deposits collateral and confirms payment.
• Escrow Activation:
  • Funds (payment and collaterals) are locked in escrow by the protocol rules.
• Transaction Completion:
  • Seller ships item.
  • Buyer confirms receipt.
  • Funds are automatically released by client software per protocol rules.

What Happens If Disputes Arise?

• Buyer Does Not Confirm Receipt:
  • Seller can initiate a dispute (kind-312).
  • Parties can communicate via kind-320 events.
  • They may reach a mutual agreement (kind-315) or opt for arbitration (kind-316).
• Protocol Enforcement:
  • Funds remain in escrow until a resolution is achieved.
  • Collateral incentivizes both parties to resolve disputes although this can never be guaranteed in a decentralized system and some amount of trust and collaboration required between buyers and sellers will always be a limiting factor.  Buyers and sellers are allowed to establish their own risk profiles through negotiating collateral requirements within any single bid taking into account the sale item itself along with the other party’s repuation. 

Reputation System

A functioning reputation system which is very difficult to manipulate is vital to DOMP’s functioning.  It is the main way buyers and sellers can establish acceptable collateral levels for individual purchases.

Storage and Reference

• Decentralized Storage: Reputation feedback events are stored on Nostr relays.
• Reference by Identifier: Each reputation event references the entity being rated using appropriate identifiers (e.g., pubkey for users and arbitrators, URL for relays).

Event Types for Reputation Feedback

• kind-321: User Reputation Feedback
  • Used for rating buyers and sellers.
  • Must reference specific prior transaction events to validate the feedback.
• kind-322: Arbitrator Reputation Feedback
  • Used for rating arbitrators.
  • Must reference specific arbitration events (kind-316, kind-312, kind-315) to validate the feedback.
  • Only participants involved in the arbitration can rate the arbitrator.
• kind-323: Relay Reputation Feedback
  • Used for rating relays.
  • Must include proof of interaction with the relay, such as a payment proof or service usage evidence.
  • Relay is identified by its URL or domain name.

Reputation Details & Calculations

Kind 321 – User Reputation Feedback

• Client Responsibilities:
  • Fetching Events: Clients fetch kind-321 events related to a user.
  • Validating Feedback: Clients verify that each kind-321 event includes a valid reference to a prior event and that it has not been used before.
  • Calculating Scores: Clients compute reputation scores based on valid, non-duplicated feedback.
• Prevention of Abuse:
  • Event Validation: By requiring references to specific events, only users who participated in a transaction can provide feedback.
  • Single Use of References: Each transaction event can only be referenced once in reputation events to prevent multiple ratings from a single transaction.

Example User Reputation Algorithm:

def calculate_reputation(user_pubkey):

    feedback_events = get_feedback_events(user_pubkey)

    valid_feedback = []

    used_transaction_refs = set()

    for event in feedback_events:

        transaction_ref = event[‘content’][‘transaction_ref’]

        transaction_kind = event[‘content’][‘transaction_kind’]

        # Check if the transaction_ref has already been used

        if transaction_ref in used_transaction_refs:

            continue  # Skip duplicate feedback

        # Validate the referenced event

        if not validate_transaction_event(transaction_ref, transaction_kind, event[‘pubkey’], user_pubkey):

            continue  # Skip invalid references

        used_transaction_refs.add(transaction_ref)

        valid_feedback.append(event)

    # Calculate reputation score based on valid_feedback

    total_score = 0

    total_weight = 0

    for event in valid_feedback:

        rating = event[‘content’][‘rating’]

        transaction_value = get_transaction_value(event[‘content’][‘transaction_ref’])

        weight = transaction_value

        total_score += rating * weight

        total_weight += weight

    reputation_score = total_score / total_weight if total_weight > 0 else 0

    return reputation_score

def validate_transaction_event(transaction_ref, transaction_kind, rater_pubkey, rated_pubkey):

    transaction_event = get_event_by_id(transaction_ref)

    if not transaction_event:

        return False

    # Check if the transaction_kind matches the event’s kind

    if transaction_event[‘kind’] != transaction_kind:

        return False

    # Verify that the rater and rated users were involved in the transaction

    involved_pubkeys = {transaction_event[‘pubkey’], transaction_event.get(‘counterparty_pubkey’)}

    if rater_pubkey not in involved_pubkeys or rated_pubkey not in involved_pubkeys:

        return False

    return True

kind-322: Arbitrator Reputation Feedback

Requirements for kind-322:

• Rating an Arbitrator: The user must include a reference to a valid arbitration event, such as:
  • kind-316 (Arbitration Offer)
  • kind-312 (Escrow Dispute)
  • kind-315 (Mutual Agreement involving arbitration)
• One Feedback per Arbitration: Each arbitration event can only be referenced once for a valid kind-322 rating.

Code Sample for Rating an Arbitrator:

{

  “kind”: 322,

  “pubkey”: “user_pubkey”,

  “created_at”: 1620001000,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”arbitrator_pubkey\”: \”arbitrator_pubkey\”, \”rating\”: 4, \”comment\”: \”Fair and timely resolution.\”, \”arbitration_ref\”: \”event_id_316\”, \”arbitration_kind\”: 316}”,

  “id”: “event_id_322_user”,

  “sig”: “signature_user_322”

}

kind-323: Relay Reputation Feedback

• Purpose: Enables users to rate relays based on their service quality.
• Validation: Requires proof of interaction with the relay.

Requirements for kind-323:

• Identification of Relay: Relays are identified by their URL or domain name (relay_url).
• Proof of Interaction: Users must provide evidence of interaction, such as:
  • Payment proof to the relay (e.g., for anti-spam measures)
  • Event IDs of events successfully propagated by the relay
• One Feedback per Interaction: Each interaction can be referenced once for feedback.

Code Sample for Rating a Relay:

{

  “kind”: 323,

  “pubkey”: “user_pubkey”,

  “created_at”: 1620001050,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”relay_url\”: \”relay1.example.com\”, \”rating\”: 5, \”comment\”: \”Reliable and fast service.\”, \”interaction_proof\”: {\”payment_proof\”: \”ln_payment_hash_relay_fee\”, \”event_id\”: \”event_id_300\”}}”,

  “id”: “event_id_323_user”,

  “sig”: “signature_user_323”

}

Example Arbitrator and Relay Reputation Algorithm:

Note For Arbitrators:

• Validation: Clients must verify that the arbitration_ref corresponds to a valid arbitration event involving both the rater and the arbitrator.
• Single Use of References: Each arbitration event can only be referenced once per rater in reputation events.

Note For Relays:

• Validation: Clients verify the interaction_proof to ensure the user interacted with the relay.
• Relay Identification: Since relays do not have pubkey, they are identified by relay_url.

def calculate_arbitrator_reputation(arbitrator_pubkey):

    feedback_events = get_arbitrator_feedback_events(arbitrator_pubkey)

    valid_feedback = []

    used_arbitration_refs = set()

    for event in feedback_events:

        arbitration_ref = event[‘content’][‘arbitration_ref’]

        arbitration_kind = event[‘content’][‘arbitration_kind’]

        if arbitration_ref in used_arbitration_refs:

            continue  # Skip duplicate feedback

        if not validate_arbitration_event(arbitration_ref, arbitration_kind, event[‘pubkey’], arbitrator_pubkey):

            continue  # Skip invalid references

        used_arbitration_refs.add(arbitration_ref)

        valid_feedback.append(event)

    # Calculate reputation score based on valid_feedback (similar to user reputation)

    # …

def calculate_relay_reputation(relay_url):

    feedback_events = get_relay_feedback_events(relay_url)

    valid_feedback = []

    used_interaction_proofs = set()

    for event in feedback_events:

        interaction_proof = event[‘content’][‘interaction_proof’]

        proof_id = hash(interaction_proof)  # Create a unique identifier for the proof

        if proof_id in used_interaction_proofs:

            continue  # Skip duplicate feedback

        if not validate_interaction_proof(interaction_proof, event[‘pubkey’], relay_url):

            continue  # Skip invalid proofs

        used_interaction_proofs.add(proof_id)

        valid_feedback.append(event)

    # Calculate reputation score based on valid_feedback (e.g., average rating)

Arbitration

Step 1: Dispute Arises

A dispute may occur due to issues such as:

• Non-receipt of Goods: The buyer claims the item was not delivered.
• Goods Not as Described: The buyer asserts that the received item differs significantly from the description.
• Payment Issues: The seller alleges that payment was not received or was incorrect.

Either party can initiate the arbitration process to seek a fair resolution.

Step 2: Initiation of Dispute (kind-312)

The party initiating the dispute publishes a kind-312 event to signal the existence of a dispute.

{

  “kind”: 312,

  “pubkey”: “buyer_pubkey”,

  “created_at”: 1620000850,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”payment_ref\”: \”event_id_311\”, \”reason\”: \”Item not received\”, \”details\”: \”Expected delivery date has passed without receipt.\”}”,

  “id”: “event_id_312”,

  “sig”: “signature_buyer_312”

}

Step 3: Selection of Arbitrator

Option 1: Arbitrator Offers Services (kind-316)

Arbitrators monitor the network for dispute events and can offer their services by publishing kind-316 events.

{

  “kind”: 316,

  “pubkey”: “arbitrator_pubkey”,

  “created_at”: 1620000900,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”dispute_ref\”: \”event_id_312\”, \”arbitrator_pubkey\”: \”arbitrator_pubkey\”, \”terms\”: \”Arbitration fee of 2% of transaction value, payable upon resolution.\”, \”fee_satoshis\”: 1600000, \”contact_info\”: \”arbitrator@example.com\”}”,

  “id”: “event_id_316”,

  “sig”: “signature_arbitrator_316”

}

• Arbitrator Fee: The arbitrator specifies their fee in satoshis or as a percentage of the transaction value.
• Terms and Conditions: The arbitrator outlines their terms, including how the fee is to be paid and any additional conditions.

Option 2: Parties Select Arbitrator Directly

Alternatively, the disputing parties may choose an arbitrator they trust, perhaps based on prior interactions or reputation scores.

Step 4: Agreement to Arbitrate and Release of Funds (kind-315)

Both parties must agree to arbitration by publishing kind-315 events. Upon mutual agreement, the protocol releases the disputed funds and both parties’ collateral to the arbitrator.

Buyer Agrees to Arbitration:

{

  “kind”: 315,

  “pubkey”: “buyer_pubkey”,

  “created_at”: 1620000950,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”payment_ref\”: \”event_id_311\”, \”agreement\”: \”Agree to arbitration by arbitrator_pubkey\”, \”arbitrator_ref\”: \”event_id_316\”, \”release_funds_to_arbitrator\”: true}”,

  “id”: “event_id_315_buyer”,

  “sig”: “signature_buyer_315”

}

Seller Agrees to Arbitration:

{

  “kind”: 315,

  “pubkey”: “seller_pubkey”,

  “created_at”: 1620000960,

  “tags”: [

    [“anti_spam_proof”, “ln_payment_hash_or_PoW_proof”]

  ],

  “content”: “{\”payment_ref\”: \”event_id_311\”, \”agreement\”: \”Agree to arbitration by arbitrator_pubkey\”, \”arbitrator_ref\”: \”event_id_316\”, \”release_funds_to_arbitrator\”: true}”,

  “id”: “event_id_315_seller”,

  “sig”: “signature_seller_315”

}

• Release of Funds: The release_funds_to_arbitrator flag indicates that both parties consent to transfer the funds to the arbitrator.

Step 5: Transfer of Funds to Arbitrator

Upon mutual agreement:

• Protocol Action: The protocol, via client software compliance, facilitates the transfer of the disputed funds and collateral to the arbitrator’s control.
• Fund Transfer Mechanism:
  • For Multisig Escrow: The arbitrator is part of a 3-of-3 multisig wallet, and with both party’s cooperation, can access the funds.
  • For Lightning Network Payments: The clients initiate a payment to the arbitrator’s LN node equivalent to the disputed amount plus any fees.

Step 6: Off-Protocol Arbitration Proceedings

The arbitrator communicates with both parties outside the protocol to:

• Gather Information: Collect evidence, statements, and any necessary documents.
• Deliberate: Analyze the information to make a fair decision.
• Confidentiality: Ensure privacy and confidentiality of sensitive data.

Step 7: Arbitrator Disburses Funds Off-Protocol

Based on the arbitration outcome:

• Fund Distribution: The arbitrator disburses the funds and collateral to the appropriate parties using off-protocol transactions.
  • Payment to Seller or Refund to Buyer: The arbitrator sends the funds directly to the entitled party’s Bitcoin or LN address.
• Deduction of Arbitration Fee: The arbitrator deducts their fee from the funds before disbursal, as per the agreed terms.

Arbitration events happen off protocol because of the inherent complexity of disputes.  It would be impractical to try to account for every possible dispute solution.

Step 8: Closing the Dispute on Protocol

While the actual fund transfer happens off-protocol, the arbitrator publishes a kind-317 event to record the resolution.

Arbitrator’s Resolution Event (kind-317):

{

  “kind”: 317,

  “content”: {

    “dispute_ref”: “event_id_312”,

    “resolution”: “Funds refunded to buyer as item was not delivered.”,

    “arbitration_fee_satoshis”: 1600000,

    “fee_deducted_from”: “seller_collateral”

  },

  “pubkey”: “arbitrator_pubkey”,

  “sig”: “signature_arbitrator_317”,

  “relays”: [“relay1.example.com”],

  “id”: “event_id_317”,

  “created_at”: 1620001100

}

• Purpose: This event provides a public record of the dispute’s resolution.

Step 9: Rating the Arbitrator (kind-322)

Both parties can provide feedback on the arbitrator’s performance.

Scenarios Demonstrating Potential Exchanges

Scenario 1: Successful Transaction

Process Summary:

1. Seller Lists Product (kind-300).
2. Seller Deposits Collateral (kind-310).
3. Buyer Submits Bid (kind-301).
4. Seller Accepts Bid (kind-303).
5. Buyer Deposits Collateral & Confirms Payment (kind-311).
6. Escrow Activated.
7. Seller Ships Item and Notifies Buyer (kind-320).
8. Buyer Confirms Receipt (kind-313).
9. Funds and Collateral Released.
10. Feedback Submitted (kind-321).

Scenario 2: Buyer Does Not Confirm Receipt

1. Seller Lists Product (kind-300).
2. Seller Deposits Collateral (kind-310).
3. Buyer Submits Bid (kind-301).
4. Seller Accepts Bid (kind-303).
5. Buyer Deposits Collateral & Confirms Payment (kind-311).
6. Escrow Activated.
7. Seller Ships Item and Notifies Buyer (kind-320).
8. Buyer Fails to Confirm Receipt.  All funds including the buyers collateral remain locked in escrow.
9. Seller messages the buyer requesting confirmation of receipt (kind-320)
   1. Buyer confirms receipt to recover their collateral (kind-313)
   2. Buyer disputes the receipt of item
      • Seller or buyer Initiates a Dispute (kind-312)
        • Arbitration is offered (kind-316)
          • Mutual Agreement is made (kind 315) by both parties to have 3rd party resolve the issue off protocol
          • Mutual Agreement fails and all parties’ fund remain locked

Scenario 3: Seller Fails to Ship the Item

Additional Steps:

• Buyer Initiates Communication (kind-320).
• Mutual Agreement to Cancel (kind-315).
• Funds and Collateral Returned.

Potential Attack Vectors and Mitigation Strategies

1. Client Software Manipulation

Threat: Users may modify client software to bypass protocol rules, potentially releasing escrowed funds without proper authorization.

Mitigation Strategies:

• Cryptographic Enforcement:
  • All events must be signed using the user’s private key.
  • Events include references to previous events, creating an immutable chain.
  • Clients and relays verify signatures and event integrity before processing.
• Protocol Compliance Checks:
  • Clients enforce protocol rules by validating event structures and sequences.
  • Non-compliant events are rejected, preventing unauthorized actions.
• Community Standards:
  • Promote the use of open-source, audited client software.
  • Encourage users to verify the authenticity of their client software.

2. Sybil Attacks

Threat: An attacker creates multiple fake identities to manipulate reputation scores or flood the network with spam.

Mitigation Strategies:

• Require Proof of Work (PoW) or small LN payments for certain actions, increasing the cost of creating unlimited events to manipulate the system.
• Relays set their own anti-spam policies, filtering out spam.
• Possibility to assign more weight to feedback from users with established reputations.
• Limiting ratings to actual sale events

3. Denial of Service (DoS) Attacks

Threat: Attackers flood relays with bogus events, causing service degradation.

Mitigation Strategies:

• Relays or clients may implement rate limits to control the flow of events.
• Relays or clients may Increase PoW difficulty during high traffic periods.
• Clients and users can switch to alternative relays if one becomes unresponsive.

4. Man-in-the-Middle (MitM) Attacks

Threat: Attackers intercept and alter communication between parties.

Mitigation Strategies:

• End-to-End Encryption:
  • Sensitive messages can be encrypted using the recipient’s public key.
  • Only the intended recipient can decrypt and read the message.
• Digital Signatures:
  • All events are digitally signed by the sender.
  • Recipients verify signatures to ensure authenticity and integrity.
• Secure Communication Channels:
  • Use secure transport protocols (e.g., TLS) where applicable.

5. Replay Attacks

Threat: Attackers resend valid events to manipulate the protocol’s state.

Mitigation Strategies:

• Event Identifiers and Timestamps:
  • Each event includes a unique ID and timestamp.
  • Clients track processed events to prevent duplicate processing.
• Nonces and Sequence Numbers:
  • Incorporate nonces or sequence numbers in events.
  • Events with unexpected sequence numbers are rejected.

6. Collusion Between Parties

Threat: Parties collude to defraud others, such as a buyer and arbitrator working together against a seller.

Mitigation Strategies:

• Negative feedback from affected parties impacts the reputation of colluding users.
• Future participants can avoid interacting with low-reputation users.
• All events, including arbitration agreements and outcomes, are publicly recorded.
• Suspicious patterns can be detected by the community.
• Funds cannot be released without mutual agreement, reducing the impact of collusion.
• Make it so arbitrators can be chosen at random based on reputation scores.

7. Privacy Attacks

Threat: Observers analyze public events to link transactions and identify users.

Mitigation Strategies:

• Encrypt messages containing sensitive information.
• Avoid including personal data in public event fields.
• Only essential information is included in events.
• Sensitive details can be shared off-protocol or within encrypted messages.

Conclusion

DOMP’s decentralized approach addresses key challenges in security, fraud prevention, and trust-building within online marketplaces. By fostering collaboration among developers and users, DOMP has the potential to contribute significantly to the future of peer-to-peer commerce.

• Enhanced Buyer Confidence: Requiring the seller to post collateral first reduces the risk of trolling and demonstrates commitment.
• Explicit Escrow Establishment: The escrow mechanism is clearly defined, using LN invoices and protocol agreements without requiring third-party escrow agents.
• Combined Payment and Collateral Confirmation: By integrating the buyer’s collateral deposit and payment confirmation into a single event (kind-311), the protocol ensures that buyers cannot bypass collateral requirements, enhancing security.
• Effective Communication: Incorporating kind-320 events allows for seamless communication between parties, such as shipping notifications.
• Robust Reputation System with Abuse Prevention: Requiring kind-321 events to reference specific previous events ensures that only parties involved in a transaction can rate each other, preventing abuse of the rating system.
• Exclusive Buyer Control Over Funds Release: Buyers alone can release funds from escrow unless mutual agreement or arbitration is initiated.
• No Unilateral Seller Access to Escrowed Funds: Sellers must fulfill their obligations to access payments.
• Optional Arbitration and Third Parties: The protocol allows for third-party involvement only when both parties agree.
• Market-Driven Anti-Spam Measures: Relays set their own anti-spam policies, promoting a dynamic and adaptable network.
• Event Integrity and Security: Strict event structures and cryptographic references ensure transaction integrity without centralized oversight.

Trade-offs and Reasonings:

• Combined Payment and Collateral Confirmation: Enhances security by ensuring that the buyer cannot confirm payment without simultaneously depositing their collateral.
• Mandatory Event References in Reputation Feedback: Prevents abuse by ensuring that only participants in a transaction can submit feedback, and each transaction can only be rated once.
• Separate Event Types for Bid Acceptance and Counter Bids: Enhances clarity and reduces the risk of misunderstandings.
• Seller Posts Collateral First: Increases buyer confidence without adding risk to the seller, as they can refund funds if the buyer disengages.
• Optional Third-Party Involvement: Maintains decentralization and user autonomy, allowing flexibility when disputes arise.
• Reputation System Universality: By storing reputation events on Nostr relays, reputation scores are universally accessible and consistent across clients, while calculations are performed by clients following standardized methods.

Realizing the vision of DOMP’s decentralized approach requires collaborative efforts from the community. Interested parties are encouraged to contribute to the development and implementation of this protocol. If you are interested in being involved contact me on nostr @Fromperdomp

npub19n4ecg8l4l3fxe0muam78zth0hudt3l64fgezz20hyahcwq42sss587dtv

But in the era of blockchain analysis, when most on-ramps and off-ramps are subjected to KYC/AML procedures, breaking the deniability is easier than ever. And privacy, while it appears to be decent at the moment when the transaction occurs, can only degrade over time as the sender and the receiver may accidentally or willingly divulge more information later on. Satoshi himself wrote this in the whitepaper: ”some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking would reveal other transactions that belonged to the same owner” [1].

While some self-described ”toxic maximalists” will argue that Bitcoin is inherently fungible at the protocol level and discrimination is only an issue at the social layer, it’s nearly impossible to not distinguish between monetary units while the origins are clear. In June 2024, PayPal co-founder Peter Thiel has made one of the most candid observations on the topic: ”when people in the FBI tell me that they’d much rather have criminals use Bitcoin than $100 bills, it suggests that maybe it’s not quite working the way it was supposed to” [2].

Regardless of this depressing status-quo, there are three types of arguments to be made in favor of Bitcoin’s aspirations to become a private digital currency: the first one concerns the history and origins of the project, the second one is about sound money and the requirement to obtain fungibility, and the third is about some efforts that developers have made over the years.   

1. Bitcoin’s History and Cypherpunk Origins

In an e-mail that he sent to b-money inventor Wei Dai in August 2008, Satoshi Nakamoto attached a document called ”ecash.pdf” [3] — an early draft of the Bitcoin whitepaper whose working title implies the creation of a decentralized approach to David Chaum’s privacy-friendly electronic cash system. At chapter 10, just like in the final draft of the Bitcoin whitepaper which was revealed to the world on October 31st, readers can find a rather naive but useful description of how bitcoiners can transact with a degree of privacy: every time a user receives bitcoins, he should generate a new ”public key” whose purpose and identity are known only by the sender.

This method was also demonstrated by Satoshi Nakamoto while he mined blocks: currently, the ”1 million BTC” theory is a mere assumption that Sergio Demian Lerner has made during his Patoshi research in 2013 [4]. We cannot know for certain which blocks were discovered by Satoshi, as every coinbase reward of 50 BTC was sent to a different address.

According to professional software engineers who analyzed version 0.1 of the Bitcoin software, Satoshi Nakamoto was not a seasoned C++ developer. He created a system that was pieced together from open source libraries, included a broken game of poker and a peer to peer marketplace, and made it available only on Windows. It took the efforts of other developers such as Hal Finney, Gavin Andresen, Jeff Garzik, Mike Hearn, Wladimir van Der Laan, Gregory Maxwell, and Laszlo Hanyecz to refine the code, break it down into manageable chunks, and port it to Linux, MacOS, and mobile platforms. Satoshi Nakamoto’s amateurish and “hacky” coding style was attested by early contributor Jeff Garzik [5] and Libbitcoin maintainer Eric Voskuil [6]. 

Based on these observations, as well as some e-mail exchanges in which Satoshi appeared to be insecure about his project and seemed to look up to Hal Finney, we know that the Bitcoin creator wasn’t some time-traveling alien AI who invented digital alchemy (as Saylorists seem to believe) and he wasn’t a CIA/NSA professional either. Satoshi didn’t invent or write from scratch the building blocks of Bitcoin: elliptic curve digital signatures, Merkle trees, SHA256, Proof of Work, public key cryptography, peer to peer networks, electronic cash and blockchains were all available as separate iterations that served distinct purposes. But he did want Bitcoin to be a decentralized version of Chaumian ecash — a true holy grail among the cypherpunk community.

The above paragraph, though it may seem unnecessary in the context of a discussion on privacy, is useful in providing context for what kind of software developer Satoshi was and what his intentions were. We do know that he wanted his system to have privacy, but at the same time he wasn’t the best coder or cryptographer around. He merely used the open source libraries that were available to him at the time. And most of the privacy technology that emerged later (ring signatures, zero knowledge proofs, MimbleWimble, confidential transactions, ZK rollups) marks an attempt to improve on a rough software stack and bring it closer to fulfilling its mission.

We know with certainty that Satoshi Nakamoto cared about improving Bitcoin’s privacy because, during his short tenure as lead developer and educator in chief he provided feedback to some early improvement proposals. This intellectual contribution is frequently pointed out by Monero fans, who claim that their network of choice closely follows the writings of Satoshi. 

On August 11th 2010, as part of Bitcoin Talk’s 770th thread (titled ”Not a suggestion”), Satoshi Nakamoto replied to users Red and Insti who proposed using Zero Knowledge Proofs to minimize the amount of transaction data being stored by full nodes. Initially, the Bitcoin creator made a pretty interesting suggestion: ”if a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.” [7]

Two days later, under the same forum topic, Satoshi described three elements that lay at the foundation of today’s Monero and ZCash:  

”Can public nodes see the values of transactions?” — a condition which later inspired the creation of Confidential Transactions.

”When paying to a bitcoin address, you would generate a new blinded key for each use” — a vague description of stealth/shielded addresses and Silent Payments, as well as one-time public keys.

”I think that’s where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it.” — a description of what would later become ring signatures in Monero and mixing pools in ZCash (as well as CoinJoins in Bitcoin).

Satoshi Nakamoto didn’t only answer to the comments posted by the users, he also proved that he’s been researching the topics and presented the limitations of his discovery: ”Crypto may offer a way to do ‘key binding’. I did some research and it was obscure, but there may be something there. ‘Group signatures’ may be related.”

As always, the Bitcoin creator presented a practical example to spark the imagination of the contributors: “say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn’t know who did it.”

Satoshi also encouraged others to find a solution to a problem he couldn’t solve during his short tenure as lead developer: “The challenge is, how do you prove that no other spends exist?  It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can’t check the signatures to see if an outpoint has been spent before.  Do you have any ideas on this?”

Hal Finney, legendary PGP coder and the first notable cypherpunk to give Bitcoin a chance, is responsible for putting out the famous “Running bitcoin” tweet — published on January 11th 2009. But only 10 days later, he wrote about a lesser known but equally significant effort: “Looking at ways to add more anonymity to bitcoin” [8]

This post was sent out to the world two years before Silk Road was launched, and it would take five years for the intelligence company Chainalysis to get founded. Without fueling any “Hal Finney was Satoshi” theories, it’s worth noting that his early concerns were valid and haven’t been dismissed yet. Bitcoin never received more anonymity — just a little bit more deniability via transaction obfuscation. 

2. Sound Money Requires Fungibility

Now let’s talk about the properties of sound money — a status which Bitcoin unquestionably aspires to attain. Even in the event that it scales down its purpose to remain a store of value, a certain degree of fungibility is still required. Currently, discrimination of transactions is possible at the validator and block producer level: nodes can choose to filter out transactions of arbitrary types or coming from a certain source, while miners can ignore transactions that they don’t like (most famously, Ocean Pool filters ordinal inscriptions and MARA Pool rejects addresses on the OFAC list).

The reason why Bitcoin still works as designed is the incentive system: it’s relatively easy for the sender to spin up a node which saves his transaction in the mempool and keeps on broadcasting it — any contemporary computer can run Bitcoin Core or Libbitcoin. Likewise, for every censorship-friendly mining cartel, there can always be another independent block producer who will not mind collecting the transaction fee.

However, in a world in which KYC/AML practices become prevalent and blockchain analysis is an industry standard, there is a lot more information about Bitcoin users, addresses, and miners. So resourceful governments can pressure participants into following a strict blacklisting procedure, with very draconian punishments for miners who break the rule. Naturally, geopolitical game theory fixes part of the problem because we live in a multi-polar world with a plurality of superpowers that don’t always collaborate.

But a project like Bitcoin should not rely on goodwill or flaws in the structure of human politics — instead, it should become censorship resistant by design. The only way to achieve this feat is to make it impossible for miners to act in ways which differ from the system’s incentives: therefore, collect the highest fees to confirm transactions without caring about the origins. If Bitcoin adds a degree of confidentiality, which enables senders to remain private and also hide the amounts that they’re sending, then the system would finally support sound money.

As any monetary theorist will tell you, fungibility is a very important quality for good money. An ounce of gold is equal in value with another one of the same purity, regardless of its origins. A $100 bill will buy you the same amount of goods and services, even if it was previously held by Brad Pitt, the President of the USA, a construction worker, a convicted criminal, or all of them at different times.

In the case of Bitcoin, you still encounter “freshly mined coins”, “Silk Road coins”, “dark market coins”, “Mt. Gox coins”, “Coinbase coins”, “Kraken coins”, “CoinJoined coins”, “ordinals”, and all sorts of ways to differentiate according to origin. On the free market, freshly mined coins are usually deemed more valuable — for the simple reason that they have no past.

Interestingly, Bitcoin does have a built-in fungibility mechanism: once a transaction fee gets paid, the corresponding coins get mined again as part of the block reward. So even the most “tainted” coins can become squeaky clean once a miner collects them as fees and reissues them. However, this is not enough: and to expect all “tainted” bitcoins to get sent as transaction fees is extremely unrealistic. What Bitcoin needs is a system that makes it impossible to discriminate according to previous ownership — and if users (and outside observers) cannot know, then they will have no means to censor.

3. The Proposals to Make Bitcoin Private

Almost sixteen years into Bitcoin’s existence, we have a remarkable series of discoveries and inventions that can improve its privacy. Some of them are already part of the Core software stack (such as BIP32, whose hierarchical deterministic wallets help create more deniability) or exist as additional features in various wallets (such as CoinJoin in Wasabi, JoinMarket & Samourai, or Silent Payments in Cake Wallet). But these solutions alone aren’t good enough. They generate a degree of deniability, but can’t hide the amounts being transacted and are generally worse for the sender.

This is why we must look into the plethora of more or less experimental proposals which offer privacy with various tradeoffs. Most commonly, there are three types of criticism regarding anything which concerns Bitcoin privacy:

1. That the extra obfuscation occupies more blockchain space and therefore won’t scale, as is the case of Confidential Transactions and Ring Signatures (both available on Monero);
2. That hiding transaction amounts may lead to unwanted monetary inflation in the event of bug exploits, as the money supply is no longer easy to audit;
3. That privacy of any kind might get Bitcoin delisted from exchanges, banned from certain jurisdictions, or even scare away institutional investors who put billions of dollars into building their BTC portfolios while assuming that the software is complete, stagnant, and easy to audit by regulators;

The first two issues can be avoided via elegant cryptography, cautious development, and rigorous testing. Privacy enthusiasts can launch the new features on other networks, incentivize scrutiny and adversarial interactions, and then propose their refined discoveries to the Bitcoin community. However, even the ideal solution becomes useless if there is no social support for its implementation in particular or for anything that aims to fix Bitcoin privacy in general. If the culture gets eroded by complacency and “number go up” hopium, then the desire for fiat money gains will stall any cypherpunk aspiration — it won’t be until fungibility really becomes an issue which blatantly erodes the financial well-being of a majority of users that the conversation about adding privacy becomes serious.

Politics aside, it’s useful to pay attention to breakthroughs in the world of privacy, understand how they work, and think of ways to apply similar protocols or principles to Bitcoin (preferably, without requiring major changes to the consensus code). It’s how ideas get refined and distilled into their most efficient form. It’s also how clever workarounds get discovered, as means to circumvent the conservative nature of the Bitcoin protocol.

The 4 types of Bitcoin Privacy

Before proceeding with the analysis, it’s important to distinguish between the four types of Bitcoin privacy: sender, receiver, amounts, and network-level. For a more thorough breakdown on the topic, I recommend you to listen to Paul Puey on S15 E48 of the Bitcoin Takeover podcast [7].

When used as Satoshi suggested in the whitepaper (new address for every incoming transaction), Bitcoin protects the identity of the receivers — that is, until further multi-input transactions are made to break the deniability. If the user makes use of the Tor network or a powerful mixnet such as Nym, then other peers cannot figure out where the node or light wallet is located based on IP address. So Bitcoin can also have pretty good network-level privacy.

However, there is little to no privacy for the sender: as the receiver can see the amount being sent and how much change was returned after the transaction. And speaking of amounts, there is no way to have any confidentiality for the number of coins being transferred — at least not on the base layer.

A good way to get deniability when sending Bitcoin is to transfer the entire amount from the UTXO to avoid change. This can be interpreted as a self-transfer to a new wallet, but can also be a payment. Nobody really knows initially, unless the veil gets lifted later when a KYC/AML off-ramp gets involved or someone makes a mistake.

There are several significant proposals to address these shortcomings, and they will be presented according to the issue they address. 

Dandelion++ for Network-Level privacy

For example, Dandelion was created to significantly boost network-level privacy by inserting a random delay that breaks the link between IP addresses and individual transactions. It was proposed for Bitcoin in 2017, received a significant improvement (Dandelion++) the next year, but it never made into the Bitcoin project.

Though there was some interest from developers, the users never really pushed for the adoption of this particular privacy enhancement — and if you ask the average bitcoiner today, they won’t know what Dandelion is and probably assume you’re speaking about a “shitcoin”. The protocol was however added to Monero, Firo, and a bunch of other privacy projects. It would have been great to have it in Bitcoin, since it doesn’t require any kind of fork or consensus and none of the concerns listed above would apply.

MWEB for Sender Privacy & Hiding Amounts

The MimbleWimble Extension Block protocol was also proposed for Bitcoin, but ended up getting developed for Litecoin. Back in 2016, Blockstream head of research Andrew Poelstra presented the idea to put MimbleWimble (a novel and groundbreaking privacy and scalability protocol) on an extension block [8]. This integration would require a soft fork and enables bitcoiners to peg their coins into a larger anonymization pool where the amounts being sent are hidden and you can’t lurk into someone else’s address. 

All you can observe in MWEB is how many coins join the pool, where the peg-ins come from, and where the peg-outs go. Though the latter two points might sound like an issue, they can be mitigated with CoinJoins to create enough deniability to make analysis difficult. 

MimbleWimble comes packaged with confidential transactions — a technology that was built for Bitcoin, was picked up by Monero, but scales much better in the updated design of Tom Elvis Jedusor. It has been available on Litecoin since May 2022 and still works flawlessly, with mobile integrations and light wallets being developed in recent months to increase portability. 

Historically, Litecoin is the network that tests upgrades which are considered to be too risky or avant-garde for Bitcoin — it happened in the case of SegWit, then it continued with main net Lightning Network experiments that were later moved to BTC. However, this time around there seems to be no interest in adding MWEB: there is no BIP to promote it, there are almost no debates about it, and critics usually point out to MimbleWimble and say it’s not ”good enough” for privacy (as if other proposals are seriously being considered or else there is something that Bitcoin already has). 

Can MWEB scale? Absolutely! Thanks to the embedded data compression, it prunes older transactions and remains compact in size. Block size increases can be applied to it without really requiring more storage from nodes.

It’s also designed in a way which makes the supply easier to audit — anyone can see how much liquidity exists in the anonymity pool, and then nodes can reject amounts that exceed the peg-ins. But will it lead to exchange delistings?

As Litecoin demonstrated, not really. Only a couple of Korean exchanges did that due to regulatory uncertainty. The big players never dropped support. MWEB is an opt-in layer for transactions — and businesses can still operate on the main chain if they want to have full transparency. 

It’s definitely a useful and interesting proposal which does contribute towards fixing Bitcoin’s privacy and scalability issues. However, as revealed in S15 E17 of the Bitcoin Takeover podcast, not even Andrew Poelstra (the man who first thought of putting MimbleWimble on a Bitcoin Extension Block) is passionate about the idea anymore… not even after it’s been implemented on a Bitcoin-compatible network [9]. But if you want to hear a technical and somewhat optimistic discussion on the topic of MWEB, listen to S15 E59 with David Burkett — the man who made it all happen [10]. 

Statechains, CoinJoins & PayJoins for Pragmatic Sender Privacy

Statechains, CoinJoins, and PayJoins (payments coming directly from CoinJoins) at scale can also mitigate some of Bitcoin’s privacy issues. The sender’s privacy definitely gets a boost, but amounts being moved on the main chain remain visible. With Statechains, currently developed by CommerceBlock for the MercuryLayer, users can seamlessly swap UTXOs of equal sizes without leaving any permanent record on the base layer. It’s a pretty cool concept, as the transfer of ownership happens without the blockchain. To learn more about it, listen to my interview with developers Nicholas Gregory and Tom Trevethan [10]. 

However, the incentive to perform this swap only exists when you don’t want your further transactions to carry your identity. And if UTXO swapping is exclusive to those who need it, then the coins being exchanged aren’t necessarily ”the cleanest” that everyone wants. This is why CoinJoins should be used in conjunction with Statechain CoinSwaps — so that all the bitcoins involved are equally clean and equally dirty at the same time. Paying out of CoinJoins is also necessary in order to preserve the privacy benefits.

However, the user experience for following this process is still cumbersome and the cost might be a little too high for most people (especially in a high fee environment, which Bitcoin expects to have). But even if Bitcoin does scale and the interfaces do get optimized to serve non-technical users, there still needs to be enough demand for this type of privacy. The reason why privacy is still niche is that very few bitcoiners actually use it.

Drivechains for Pretty Much Everything 

One of the most interesting, yet controversial proposals to improve Bitcoin is Drivechains: Layer Two Labs CEO Paul Sztorc has come up with the idea of miner-enforced sidechains that copy the features of every altcoin. This way, the scaling solution also acquires the benefits of  adding functionality and utility. Basically, Drivechains fulfill the dream of Bitcoin maximalism — that of having every use case and every transaction on Bitcoin, within the economy provided by the 21 million supply cap. The concept is explained by BIP 300 and BIP301.

In terms of privacy, Drivechains come packaged with a Zcash sidechain that provides the most advanced privacy that’s available today (as it’s a direct fork of the latest version of Zcash). It’s called Zside and can be downloaded from the LayerTwo Labs website for testing purposes on the Bitcoin signet.

To use it, bitcoiners must transfer their coins into the sidechain and lock them for approximately 13000 blocks (the time frame between the deposit and the withdrawal was architected like this to ensure system stability). On the base layer, the coins get frozen in a time lock contract. On the Zside chain, the same amount of BTC gets minted and becomes usable for as long as the user keeps the funds pegged.

This means that the supply is always clear, the amount of coins locked in the Zcash sidechain can be verified, so there is no risk of hidden inflation. By virtue of being a sidechain that can choose to prune transaction history after a certain point, it’s also very scalable. And in terms of regulators banning it or exchanges delisting BTC, they’d have to enable support for this particular layer first. Bitcoin remains unaffected.

Of course, some Bitcoin Core developers such as Matt Corallo and Peter Todd have expressed concerns about mining centralization and MEV (Maximal Extracted Value) [11]. But Paul Sztorc is currently working on the CUSF (Core Untouched Soft Fork) activation method, which involves bypassing the opinions of Bitcoin Core by directly dealing with the miners [12]. Since the block reward is diminishing and the amount of transaction fees collected by the miners is disappointingly low, there’s an incentive for block producers to enable merged mining. Drivechains also come bundled with blind merged mining, which is really useful in this multi-chain context.

If implemented, Drivechains open up the technical possibility for Bitcoin to onboard the entire planet and provide all the smart contracts or privacy features that one might desire. But at this point in time, it seems like the community would rather discuss covenant soft forks and OP code restoration than think bigger in terms of what the Bitcoin network can be. It seems unlikely that Core developers will agree on activating BIP 300, but the miners might just coordinate to maximize their revenue — because to them, the next few years are going to be all about the fees.

Covenants for ZK Rollups & Trust Minimized Sidechains

While they don’t provide any privacy benefits by themselves, covenant soft forks such as OP_CTV, OP_CAT, and OP_ANYPREVOUT are tools which allow developers to build trust-minimized sidechains and ZK rollups. With covenants, layers such as Liquid and Rootstock (which today rely on trusted setups or federations) can significantly improve their decentralization. 

Also, as suggested by Bitcoin developer Super Testnet, Drivechains could get built using OP_CAT and BitVM — but there are some tradeoffs in terms of user benefits and protections that make the Drivechains soft fork activation preferable. 

ZK rollups are also an interesting import from Ethereum, which allows users to transact with pretty good privacy on scalable layer twos. Projects like Citrea and Alpen Labs already exist and work towards building proper rollups for Bitcoin, but their ability is still limited by the lack of specific features unlocked by covenant soft forks.

Covenants can also support the creation of CoinJoin implementations that don’t have a coordinator in the middle. Something like Wasabi Wallet can get built in an automated manner, without central servers. The research of 1440000000 bytes (also known as ”Floppy”) is definitely interesting and can lead to a future in which CoinJoins are uncensorable and much easier to use.

It’s also worth noting that StarkWare, a protocol which brings Zcash-level privacy using Zero Knowledge STARKs (Scalable Transparent Arguments of Knowledge), can come to Bitcoin. Eli Ben-Sasson, the mastermind behind the system, has previously worked with ZK SNARKs (used in Zcash) and has been speaking about bringing privacy and instant blockchain synchronization to Bitcoin since at least 2014. He also co-authored the Zerocash research paper and has been on a journey to refine Zero Knowledge proofs for BTC for almost a decade.

ZK STARKs are already available on Ethereum. But if Bitcoin activates OP_CAT (or else the StarkWare researchers figure out how to build it without the extended function), then we can see this avantgarde cryptographic magic coming via ZK rollups. Not quite the ideal way, which would involve making standard base layer transactions private, but in tune with the philosophy to scale in layers with various benefits and tradeoffs.

The future is promising for these concepts, though some community members express concerns about the ability to build anything using concatenations (OP_CAT). Regardless, the privacy provided does not directly impact normal 1 input-2 outputs transactions on the base layer and it’s not as good as adding opt-in Zcash transactions. But this appears to be the path that gets most ”consensus” among bitcoiners, as many of them seem to agree that a covenant soft fork is useful.

It’s also worth noting the existence of projects such as Bitcoin OS which claim they can emulate the features of a covenant without any soft fork, and therefore allow Bitcoin to ossify and become ”permaware”. It’s an interesting approach, but it comes with limitations and tradeoffs that get fixed by an actual network upgrade. In 2024, I’ve recorded interviews with pretty much all the big players in the covenant and ZK rollups space — from Robin Linus and Orkun Kilic to Liam Eagen, Alexei Zamyatin, Eden Yago and Super Testnet. You’ll find many of these conversations if you scroll through season 15 of the show!

Privacy Hard Forks

Now we’re stepping into the field of high fantasy, as the goal is to dream about Monero or Zcash-like features on Bitcoin. However, a more radical change to the protocol, which implies a hard fork, does not necessarily lead towards better privacy. In the end, privacy is achieved when there are lots of participants who use the same protocol for the purpose of becoming indistinguishable from each other.

So it doesn’t make much sense to fantasize about Confidential Transactions (available today on Liquid) or Ring Signatures. Also, Zcash’s ZK SNARKs or Halo2 cryptography probably won’t come to Bitcoin any time soon. The reasons don’t only concern political/regulatory concerns, but also the scalability argument — anything that generates larger transaction sizes within the small block framework is less desirable.

But we can also look at projects like Decred, which managed to make every on-chain transaction a Wabisabi-like CoinJoin (CoinShuffle++, in which the amounts are visible, but there’s a lot of deniability for the sender) and also make the Lightning network more stable. I’ve interviewed Decred’s Jake Yokom-Piatt and Phoenix Green in S15 E55 of the Bitcoin Takeover Podcast and I think it’s a really interesting conversation from which we can learn [14].

Ultimately, I believe that Bitcoin will integrate a more mature version of Zcash’s protocol. It will come in a time of crisis, when institutional adoption proves to be a fad and the users find themselves desiring for ways to hide from oppressive governments. Since day one, the Zcash protocol has been thought as a way to improve Bitcoin — and Zcash’s similarities in design (21 million coins, initial Proof of Work mining) are no coincidence.

Hard forking to add privacy is the final boss — a moment that culminates a long series of social-political experiences and technical experiments. Bitcoin will undoubtedly choose to become sound money by employing the most mature, well-tested, and efficient protocol available. This is why the users, instead of being complacent, should be engaged in testing features on altcoins in order to identify the implementations that show potential and get ready for the moment when Bitcoin must get something similar. 

As mentioned in the first part of this article, it’s important to demolish any suspicion of hidden inflation. It’s also important for the privacy protocol to be scalable to the point that private transactions don’t come in larger data sizes (which is why it appears that ZK proofs might take us there). 

Last but not least, privacy should be the default and universal setting — users must never have to deal with a perishing fungibility that gets ruined by one bad actor who holds the coins, and they shouldn’t know a world where privacy is stigmatized either. Nobody questions you today when you hand a dollar bill to somebody else in a public place. Nobody will question you in the future for sending a peer to peer digital money transaction to a stranger, using a public, inclusive, and socially-mundane payments network. It’s just how evolution works.

Bitcoin will one day be 100% fungible — and we need to prepare for that day, both technologically and socially.

Bitcoin Is Still a Panopticon

Given the volume of information presented, we can safely affirm that allowing Bitcoin to have very poor privacy today was a choice. It might be the result of negligence or cowardice on behalf of the users and developers. It may be a consequence of the ”number go up no matter the cost” mentality, combined with the fear of getting delisted from exchanges.

It’s possible that the efforts to please regulators, portray Bitcoin as the nice chain that criminals avoid, and eventually embed in into the traditional financial system via ETFs might have be part of the reason. But regardless of the cause, the situation is not great: not for the users, not for the network, and definitely not for the fungibility of the currency.

Sure, CoinJoins are fine — but they still reveal the amounts being transacted and some of the participants might later KYC to diminish the others’ deniability. CoinSwaps via Statechains (as designed by Mercury Wallet) are also useful, but you never know when you get a much more ”tainted” UTXO than the one you sent out. The CoinJoin outputs may be considered ”tainted” and therefore unacceptable by some economic actors. Until the moment Bitcoin gets privacy for the amounts being sent, these issues will continue to affect users.

Since Hal Finney’s ”Looking for ways to add more anonymity to bitcoin”, which he published 18 days after the Bitcoin network launched, internet money nerds have aspired to reach this goal without any technical roadblocks or social/political issues. Almost 16 years later, we have much better research and development in the field of privacy. A decade from now, we will have perfected these tools. What matters the most is to not capitulate to dinosaur institutions offering us Sim City cheat code money, and also to try to not feel jaded about the apparent lack of progress. Technology will get us there — but are we ready for it?

Sources:

1. The Bitcoin Whitepaper, Satoshi Nakamoto, 2008, Available at: https://bitcoin.org/bitcoin.pdf 
2. Peter Thiel on Aspen Ideas Festival 2024, Available at: https://youtu.be/B3ZXrTzskw0
3. Nakamoto Studies Institute, Electronic Cash Without A Trusted Third Party, Available at: https://www.nakamotostudies.org/literature/ecash.html 
4. Sergio Demian Lerner, ”The Well-Deserved Fortune of Satoshi Nakamoto, Bitcoin Creator, Visionary and Genius”, April 2013, Available at: https://bitslog.com/2020/06/22/a-new-mystery-in-patoshi-timestamps/ 
5. Jeff Garzik, ”Hemi Presents Satoshi Stories — The Secret Behind Satoshi’s Real Identity”, Available at: https://youtu.be/Zi92Y0WpEg4?si=yYwU5TiQKZfmVwal
6. Erik Voskuil on the Bitcoin Takeover Podcast, S5 E8, Around 00:20:51, May 2020, Available at: https://bitcoin-takeover.com/audio/index.php?name=2020-05-13_s5_e8_eric_voskuil_on_misean_economics__cryptoeconomics.mp3
7. Satoshi Nakamoto on the Bitcoin Talk Forum, Replying to Topic #770, In response to Red, August 11th 2010, Available at: https://bitcointalk.org/index.php?topic=770.msg8637#msg8637 
8. Andrew Poelstra at SF Bitcoin Developers, November 21st 2016, Available at: youtube.com/watch?v=aHTRlbCaUyM 
9. Andrew Poelstra on the Bitcoin Takeover Podcast, S15 E17, February 8th 2024, Available at: https://bitcoin-takeover.com/andrew-poelstra-bitcoin-covenants-op_cat-vs-op_ctv/ 
10. David Burkett on the Bitcoin Takeover Podcast, S15 E59, October 14th 2024, Available at: https://bitcoin-takeover.com/audio/index.php?name=2024-10-14_s15_e59__david_burkett_on_mweb_privacy.mp3 
11. Nicholas Gregory and Tom Trevethan on the Bitcoin Takeover Podcast, S15 E25, March 24h 2024, Available at: https://bitcoin-takeover.com/audio/?name=2024-03-24_nicholas_gregory_tom_trevethan_on_mercury_layer.mp3
12. Peter Todd, ”Drivechains: A Detailed Analysis”, October 13th 2023, Available at: https://petertodd.org/2023/drivechains 
13. Paul Sztorc, ”CUSF — Core Untouched Soft Fork”, v0.4.1 published on June 23rd 2024, Available at: https://bip300cusf.com/cusf.pdf 
14. Jake Yokom-Piatt and Phoenix Green on the Bitcoin Takeover Podcast, S15 E55, September 21st 2024, Available at: https://bitcoin-takeover.com/audio/index.php?name=2024-09-21_s15_e55_jake_yocom-piatt_phoenix_green_on_bitcoin_decred_privacy.mp3
15. Hal Finney, Personal Twitter Profile, Available at: https://x.com/halfin/status/1136749815