LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Specification
  • Signed Transaction Endorsements
  • Merkle Proof Notifications
  • Double Spend Notifications

Was this helpful?

Edit on GitHub
Export as PDF
  1. Opinions

Legitimate Uses for mAPI

PreviousList of user experiencesNextSecurity and Scalability Benefits of UTXO-based Overlay Networks

Last updated 1 year ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

Abstract

The mAPI specifications have gained a certain level of traction in the Bitcoin SV ecosystem over the preceding years, while also attracting their fair share of controversy and criticism. Certain mAPI use-cases, such as those that facilitate one-on-one relationships between miners and individual customers, are not in keeping with Section 5 of the Bitcoin whitepaper ("transactions are broadcast to all nodes"). However, other uses of mAPI including merkle proof notification, signed transaction endorsements from miner ID public keys, and double spend notifications are legitimate and must be part of any suitable replacement.

Motivation

The industry has, in recent months, began to discuss and contemplate the deprecation of mAPI. Valid criticisms have been made, but there are also valid problems that are solved by mAPI. The goal of this BRC is to outline some of the legitimate mAPI use-cases and advocate for their inclusion into any mAPI replacement.

Specification

One of the criticisms aimed at mAPI is that it facilitates one-on-one agreements between miners and specific customers for lower fee rates on transactions. The Bitcoin whitepaper stipulates that transactions are broadcast to all nodes, and the cited stipulates that transactions must be publicly announced. Therefore, applications of mAPI that facilitate this type of one-on-one deal-making are in violation of the rules of the Bitcoin protocol.

There are still valid reasons people have chosen to use and adopt mAPI, and these features of mAPI make it valuable to this day:

Signed Transaction Endorsements

Miners, when they build blocks, can embed a miner ID public key in their coinbase transactions. This enables them to build reputation for their identity as they create and propagate honest blocks accepted by the other miners. A lightweight SPV client which tracks block headers can be easily extended to track and validate miner ID signatures that are part of coinbase transactions, creating a system in which attackers find it difficult to propagate double spends.

When transactions are submitted using mAPI, reputable miners attach signatures to the response payloads, acknowledging the validity of the transaction and their intent to include it into the next block. For micropayment transactions where the incentive for fraud is relatively low, this creates a viable system for instant payments. Therefore, any replacement for mAPI that does not address the need for immediate signed transaction endorsements would be incomplete.

Merkle Proof Notifications

The mAPI system facilitates notifications for merkle proofs. These proofs facilitate SPV by enabling users to attain confidence in the validity of transactions. Any mAPI replacement would be incomplete without a way to notify relevant parties to a transaction of the merkle proof in a standard and consistent way, whenever it becomes available or if it ever changes.

Double Spend Notifications

Finally, the mAPI system provides notifications when double spend attempts are discovered. This allows network participants to be notified if their counterparties are attempting to defraud them, and provides an additional layer of deterrent for such attacks. Any replacement for mAPI should be well-equipped with standard ways to notify relevant parties about double-spend attempts.

b-money paper