Beersy
BRC-57

Legitimate Uses for mAPI

A miner interface gained wide adoption and an equal amount of criticism, with some of its uses pulling against how the network is meant to work. This sets out which of those uses are legitimate and which are not.

Ty Everettchanged 17 May 20232 min read
mapi featurebroadcast to akept or reject

Summary

Why
Any effort to replace a controversial miner API risks discarding useful, legitimate features along with the problematic ones unless those features are explicitly named and preserved.
What
BRC-57 is an opinion document that identifies which behaviors of the Merchant API (mAPI) are legitimate and should be carried forward into any replacement, and which are not.
How
It argues that private fee deals between a miner and a specific customer violate the broadcast-to-all-nodes principle from the Bitcoin whitepaper, while signed transaction endorsements, notifications, and double spend notifications are legitimate features that any mAPI successor must still provide.

What this lets you do

  • Identify which mAPI features are worth preserving
  • Reject private miner-to-customer fee arrangements as non-compliant
  • Get signed miner endorsements as fast, informal payment assurance
  • Receive merkle proof notifications when a transaction is confirmed
  • Get notified if a double spend attempt is detected

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-57 accurately, including what it depends on.

The specification

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 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 b-money paper 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 transactions. This enables them to build reputation for their identity as they create and propagate honest blocks accepted by the other miners. A lightweight client which tracks 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.

Was this helpful?

Search Beersy

Search standards by number, title, author or topic