BRC-70

Paymail BEEF Transaction

The readable-name payment scheme was built before there was a good way to send verifiable transactions. This updates it to carry the newer self-verifying bundle instead of bare transaction bytes.

About BEEF, a bundle holding a transaction and everything needed to check it.

AlsoHandshakes SPV

Filed under Payments, though most standards about beef sit in Transactions.

Darren Kellenschwiler29 Aug 2023changed 20 Oct 20261 min read

Reference for an AI

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

Why: Paymail payments sent as plain raw transactions give the receiver no way to independently verify them, so the transaction data they get needs to carry its own proof.
What: BRC-70 is a paymail capability extension that replaces the raw transaction hex used in paymail payment delivery with BEEF (Background Evaluation Extended Format) transaction hex.
How: A paymail server lists a capability labeled 5c55a7fdb7bb pointing to an endpoint, and a sending client POSTs a JSON body containing the BEEF hex, sender metadata, and a payment reference, to which the server responds with the accepted transaction ID.

What this lets you do

Advertise a BEEF delivery endpoint in a paymail capabilities document
Send a full BEEF transaction to a paymail handle instead of a bare raw transaction
Include sender metadata like public key, signature, and a note with the payment
Let the receiving server validate the transaction and confirm with a txid
Give the receiving wallet the data it needs to run SPV without a separate lookup

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

The specification

Read the original

Abstract

We specify a paymail capability extension which supports the passing of [object Object] Transactions between hosts. The procedure for service discovery and requesting outputs is not detailed, rather this specification contains only a recommendation to replace BRC-12 RawTx hex data with BRC-62 BEEF hex data.

Motivation

We propose that p2p destination and receive raw transaction functionality between hosts to include the data required for the counterparty to run [object Object] on the transaction.

BRFCID

A random ID was generated in order to avoid label collisions in the capability document of a paymail server.

brfcid: 5c55a7fdb7bb
title: Background Evaluation Extended Format Transaction
author: Darren Kellenschwiler
version: 1.0.0

Specification

Status Note

BRC-70 is a Paymail capability extension and is external to the current bsv-blockchain/ts-sdk / bsv-blockchain/wallet-toolbox BRC-100 wallet implementation. It remains useful for Paymail-specific interoperability, but current SDK/toolbox payment flows should not be expected to expose this capability unless a Paymail integration is added explicitly.

We specify that an endpoint for delivery of transaction data ought to be added to the capabilities object in the .well-known response of a paymail service with the label: 5c55a7fdb7bb.

<!-- capabilities document of the host -->
{
    "capabilities": {
        "5c55a7fdb7bb": "https://paymail.domain.tld/api/v1/beef/{alias}@{domain.tld}",
        <!-- ...others -->
    }
}

Client Request

The sender must replace the {alias} and {domain.tld} placeholders in the URI template provided by capabilities.5c55a7fdb7bb with a valid Paymail handle. The client must then perform a POST HTTP request with the following body:

{
  "beef": "<beef_transaction_hex>", <!-- note the label is different >
  "metadata": {
    "sender": "<sender_paymail>",
    "pubkey": "<sender_public_key>",
    "signature": "<signature_of_txid>",
    "note": "<optional_human_readable_note>"
  },
  "reference": "<payment_reference>"
}

BEEF transaction hex is a string encoding of the binary format detailed in BRC-62.

Server Response

The server must validate the transaction and respond with the accepted transaction ID and an optional human-readable note.

{
  "txid": "<accepted_txid>",
  "note": "<optional_human_readable_note>"
}

Swimlanes

A swimlanes diagram is included here for further clarification: https://swimlanes.io/u/6J2q8QCEb

Was this helpful?