Burning Take protocol

A way to vote on Bitcoin by burning sats. No token, no contract, no server, no owner. Everything below can be implemented from this page alone, and every rule is checkable against the chain.

1 · Terms

2 · Address derivation

A topic address is a pay-to-witness-script-hash (BIP 141) address of a script that can never succeed.

Why it is unspendable. Spending a P2WSH output requires executing the witness script successfully. OP_RETURN fails the script unconditionally under consensus rules, so no witness exists that can spend the output. See the verification page for how to check this on your own node.

Consequence. Because the output is never spent, the witness script, and therefore the name, is never revealed on chain. The only on-chain record of a topic's name is a registration burn on the root topic. An unregistered topic exists and can be counted by anyone who knows its name, and by nobody else.

3 · Name grammar

name     = question [ "?" answers ] [ "@" deadline ] [ "!" minimum ]
answers  = option "|" option *( "|" option )      ; two or more distinct options
         / number ".." number                       ; a numeric range, low..high
deadline = 1*DIGIT                                  ; block height
minimum  = 1*DIGIT                                  ; sats per burn
question = 1*( lowercase / DIGIT / "-" / "/" / other-unicode )   ; never ? | @ ! or whitespace

Normalisation, applied before derivation

Kinds of topic

4 · Vote transaction

A vote is any Bitcoin transaction with the following outputs. Inputs are unrestricted, the identity of the voter is whatever the inputs reveal, and nothing else about the transaction matters.

A transaction with an OP_RETURN but no output to the topic address is not a vote and is invisible to the protocol. Several burn outputs to the same topic in one transaction are summed. A transaction that pays two different topic addresses is two votes, each with its own weight and the same statement, unless the statements are batched as below.

Several burns in one transaction

One transaction can carry votes on several topics, each with its own statement. Take the OP_RETURN outputs in order, split each payload on the byte 0x1F (unit separator), and assign the pieces in order to the outputs that pay topic addresses, in output order. Extra pieces are ignored. Topic outputs without a piece, or with an empty piece, are abstains.

A builder puts the statements joined by 0x1F into one shared OP_RETURN when they fit in 80 bytes: one shared OP_RETURN relays on every node. When they do not fit, it writes one OP_RETURN per topic output, right after that output; several OP_RETURN outputs in one transaction need post-Core-30 relay policy and may not propagate everywhere. A single vote is the degenerate case: one topic output, one payload, no separator.

A batch (several burns a front end keeps aside until they are signed together) and a watchlist (topics a browser follows) are client-side conveniences: nothing about them reaches the chain, and nothing in this protocol depends on them.

Receipts

A burn is identified by the txid of its transaction, and by nothing else. There is no receipt object on chain: the transaction is the receipt, and any front end can render it from the txid alone by reading the outputs (burn value, topic address, statement) and the first input's address as the burner. A transaction that burns in several topics is one receipt with several burns, one per topic output, in output order. Anyone can verify a receipt with the recount in the verification page.

5 · Statements

Statements are matched after normalisation: trim, lowercase, collapse whitespace runs to one space, strip trailing . ! ?. The display form is the spelling of the first burn seen. There is no other syntax inside a statement. It is speech.

In a numeric topic the normalised statement is parsed as a decimal number. Suffixes k and m multiply by a thousand and a million. Anything that does not parse, or falls outside the range, is an off-list answer.

6 · Counting

Numeric topics also report the burn-weighted mean and the weighted median of counted values.

Time windows such as "this week" are 144 blocks per day, applied to the confirmation height. All-time totals need only an address summary, windowed totals need the address history.

Snapshots

A host may publish a snapshot: the finished scan of a topic as a static file (the burns with their txid, statement, value, height and burner, plus the height it was taken at), keyed by the SHA-256 of the canonical name. A snapshot is a cache the host publishes, not a source of truth: a counter that starts from one must still fetch every burn confirmed after its height, and must treat it like any explorer answer, checkable by re-scanning the address from scratch. A snapshot that disagrees with the chain is wrong, the chain is not.

7 · Registration and discovery

A topic becomes discoverable by burning to the root topic with the topic's canonical name as the statement. This is an ordinary vote in an ordinary topic, so registrations are ranked by sats like everything else and can be repeated by anyone. Since the statement is limited to 80 bytes, only names of 80 bytes or fewer can be registered.

Registration grants nothing. It does not create the topic, which exists as soon as its name does, and it does not confer ownership, moderation rights, or exclusivity. Two people can register the same name; that is one topic with two registration burns.

A front end may keep its own list of names in addition to the root topic, and may refuse to display any topic. It cannot prevent anyone else from counting it.

Sponsoring: the featured convention

Promotion works the same way as registration, one level up: burning to the open topic named featured with a topic's canonical name as the statement is a vote to sponsor that topic. It is an ordinary topic under ordinary rules: ranked by sats, open to anyone, repeatable, never exclusive. A front end that honours the convention shows the sats burned for a name in featured next to that topic, and may order its front page by them; one that ignores it loses nothing. Nothing about featured is special on chain.

8 · Reference code

Derivation in plain JavaScript, no dependencies. Bech32 per BIP 173.

const CH = "qpzry9x8gf2tvdw0s3jn54khce6mua7l";
const polymod = v => { const G=[0x3b6a57b2,0x26508e6d,0x1ea119fa,0x3d4233dd,0x2a1462b3]; let c=1;
  for (const x of v) { const b=c>>>25; c=((c&0x1ffffff)<<5)^x; for (let i=0;i<5;i++) if ((b>>>i)&1) c^=G[i]; } return c>>>0; };
const expand = h => [...h].map(c=>c.charCodeAt(0)>>5).concat(0, [...h].map(c=>c.charCodeAt(0)&31));
const words = bytes => { let acc=0,bits=0,out=[]; for (const b of bytes) { acc=((acc<<8)|b)&0xfff; bits+=8;
  while (bits>=5) { bits-=5; out.push((acc>>bits)&31); } } if (bits) out.push((acc<<(5-bits))&31); return out; };
const bech32 = (hrp, ver, prog) => { const d=[ver,...words(prog)]; const pm=polymod([...expand(hrp),...d,0,0,0,0,0,0])^1;
  const chk=[]; for (let i=0;i<6;i++) chk.push((pm>>>(5*(5-i)))&31); return hrp+"1"+[...d,...chk].map(x=>CH[x]).join(""); };

export async function topicAddress(canonicalName, hrp = "bc") {
  const n = new TextEncoder().encode(canonicalName);
  const script = new Uint8Array(n.length ? [0x6a, ...(n.length <= 75 ? [n.length] : [0x4c, n.length]), ...n] : [0x6a]);
  const hash = new Uint8Array(await crypto.subtle.digest("SHA-256", script));
  return bech32(hrp, 0, hash);
}
// await topicAddress("pizza")  → bc1qzssvapwlcv4um44xqtqay7h04hkq3latjtrxedj7st5d0kv06mhqsxxzg7
// await topicAddress("")       → bc1qrz05qq6tu7senu06nzgkdrhr4dsyn7pd8rrghec0t9h2ktsc27msqvznj2

Cross-check with Bitcoin Core: bitcoin-cli decodescript 6a0570697a7a61 returns the same address under segwit.address.

Test vectors an implementation must pass:

9 · Versioning

Old burns must parse the same way forever, so the grammar only grows. The characters ? | .. @ ! / are reserved. A name that uses a construct this version does not know must be treated literally: the whole string is the question and the topic is open. A future version may give such a construct meaning, and when it does, the address does not change, only the reading of it.

Nothing in this document is enforced by Bitcoin except unspendability. Everything else is a reading convention that front ends agree on. Two front ends that disagree will show different tallies for the same burns, and both are auditable.

10 · Security notes

• Weight is money. Sybil resistance comes from the burn, not from identity. Vote counts mean nothing on their own.
• No owner. Nobody can close, edit, or moderate a topic. Deadlines and minimums are agreed readings, not enforcement. Anyone can burn anything into any topic.
• Permanence cuts both ways. Statements are public and permanent, including illegal or hateful ones. Front ends filter, chains do not.
• Reorgs. A burn near a deadline can move across it in a reorganisation. Treat results as final only after a few confirmations past the deadline.
• Relay limits. Some nodes still relay at most 80 bytes of OP_RETURN data and one such output per transaction. Stay inside that to be sure a vote propagates.
• Explorers. A public API can be wrong or censored. The protocol is only as trustless as your data source; see how to verify with your own node.