Consensus Rules vs Relay Policy

There are a lot of new people arguing on X about relay policy these days (and some old people who have suddenly returned). I see a lot of conflation and confusion between Consensus Rules and Policy. Here’s a short explainer of each 🧵 **

Consensus Rules are rules that full nodes enforce that determine which transactions are valid. Put another way, if your node receives a block containing transactions that violate consensus rules, your node will reject the block. **

Suppose your node has a blockchain of length 100. It receives a new block that builds on the 100th block. But it contains a transaction that violates some consensus rule. Your node will discard that block and keep waiting for a 101st block to arrive. **

Some examples of consensus rules:

• the block subsidy right now is 3.125 BTC. If a miner tries to print more, its invalid
• transaction can only spend unspent coins (no double spending)
• locking scripts have to be satisfied (which comes with its own rules)
• Block size limit **

Relay Policy or Mempool Policy controls what unconfirmed transactions your node will relay to other nodes. Bitcoin nodes form a peer-to-peer network with other nodes. When a node broadcasts a transaction, it is sent to all its peers, who send it to all their peers, and so on. **

Eventually the transaction reaches a node who puts the transaction in a block. Note that miners can put any transactions they want in a block, including none and including transactions that they receive through some other mechanism (see Mara Slipstream or Rebarlabs shield) **

Once a transaction is in a block, your node will store and relay it regardless of policy, but until it is confirmed, your node applies policy to decide whether or not to pass it along on the p2p network. **

Here are some policy examples:

• the longest chain of unconfirmed parent/child transactions (25)
• largest unconfirmed tx package
• transactions using OP_SUCCESS opcodes
• max op_return size/count
• max items on the witness stack
• scriptpubkey templates **

Note that policy is a SUBSET of consensus-valid transactions. This is important: There might be a transaction that your node will NOT relay on the P2P network, but once in a block your node will happily accept. This is important for softfork upgrades, censorship resistance, etc. **

Hope this helps! **

• • •

Missing some Tweet in this thread? You can try to force a refresh

** ** Keep Current with Rijndael 😸 **

Stay in touch and get notified when new unrolls are available from this author!

** ** This Thread may be Removed Anytime!**

Twitter may remove this content at anytime! Save it as PDF for later use!

More from @rot13maxi

Jul 29

Slugline: A Bitcoin Transaction Carpool, paid with Runes (or, a runes paymaster for L1 Bitcoin)

Pay your L1 transaction fees with Runes

🧵

This weekend I was at @PlebFi, an awesome Bitcoin dev conference. The theme was Metaprotocols. While I didn’t enter the hackathon (I was a judge) I decided to hack something up anyway.

My project is called slugline, and even though its pretty rough, it works and is neat :)

Here’s how it works:

Alice wants to make a Bitcoin transaction but doesnt want to pay a fee in BTC (some reasons that might be below). So she makes a tx that pays zero fee.

BUT she attaches an input that contains some runes, and makes the first output a zero-value p2a anchor

Read 11 tweets

Jul 20

This week, @PresidioBitcoin hosted the Bitcoin Quantum Summit (pbquantum.com). I was thrilled to be invited to attend, and wanted to write up a thread about what I learned this week. I’ll save my commentary for the end, and start with where we are, the challenges we (might) need to solve, and some of the solutions that have been proposed or that people are thinking about.🧵

Some quick table-setting before we get into it: Why and how would Bitcoin be affected by Quantum Computing? When you spend Bitcoin, the network requires you to prove that you are authorized to spend that coin (UTXO). Most of the time, this is done by providing a digital signature. The security of the digital signature schemes we use in Bitcoin rely on a problem called the Discrete Log Problem (DLP) being hard for computers to solve. In other words, it is computationally infeasible for a computer to take a Public Key and do the math to figure out the Private Key. That means that if you have your private key(s), you and only you can spend your Bitcoin.

There is an algorithm called Shor’s algorithm that would allow a large and powerful enough quantum computer to do this math. So if there was a capable enough Quantum Computer, it would be able to take in a Public Key and work out the Private Key. Given that Private Key, the Quantum Attacker would be able to create valid signatures, spending the Bitcoin.

Read 29 tweets

Apr 7

Taplocks: Verifiable but unspendable tapleafs

or, a hashlock over a tapleaf

🧵

If you wanted to emulate a new opcode (CAT, CTV, some PQ signing scheme, OP_WASM, whatever) today, you could do it with a policy signer or a signing oracle:

• they vend a pubkey
• you encumber your UTXO with the key
• they sign if you satisfy the script (out of band)

Is this perfect for all applications? No. but for some (especially experimental) usecases, it’s a fine trust assumption, especially if you add multiple signing servers to introduce a collusion requirement. Now a quorum of some federation has to sign.

Read 14 tweets

Sep 11, 2024

Can OP_CAT make AMMs for Runes/BRC20? Probably not. Can we make a token protocol that is AMM-friendly with OP_CAT? Yes! (with some interesting tradeoffs)

The big challenge with Runes, BRC20, and other many other colored coin protocols is that token validity is dependent on all of the prior state of the token (and in some cases like open mints, on the state of the whole chain). In an AMM, you need the `swap` script to know how much of a token is in an input/output. If you rely on the user to tell you, they can set their own price. If you’re using a token protocol that relies on an offchain indexer to determine token validity, you need to stuff all the previous transaction data for the lifetime of the data into the transaction witness and validate it in script. Yikes!

Using OP_CAT, can we design a token protocol such that the validity of the token (and the token amount) can be checked by a reasonably-sized script with a constant (or at least bounded) amount of data? Turns out we can! Here’s how.

Read 11 tweets

Feb 15, 2024

I made a vault using OP_CAT!

What is a vault? Why OP_CAT? How does it work? 🧵

A vault is a construction (using either covenants or presigned transactions) that let you add reactive security to your Bitcoin.

Imagine a special Bitcoin address that you spend coins to. When you want to spend those coins, they first go to a special “waiting room” where they sit for some period (like a week or a month). After that time expires, the coins can go on to their destination.

Read 14 tweets

Jan 13, 2024

We’ve been working super hard on @QuantumCatsXYZ. in addition to the incredible artwork by @0xfar, there’s a lot of cool tech behind these Evolving Inscriptions.

Ordinal Inscriptions are on Bitcoin. The Bitcoin Blockchain is immutable. How did we build evolving inscriptions? 👇

What’s an Evolving Inscription? Check out this tweet (and the whole thread), but what you have is a single inscription that sits in your wallet under your full control, but the way it renders changes over time on a pre-determined path.

https://x.com/QuantumCatsXYZ/status/1745824369085919570?s=20

To make this work, we lean on several different mechanisms:

• Ordinal Recursion
• Presigned Transactions
• Symmetric Cryptography
• client-side load-management

There are a lot of moving parts, but when we’re done it’s absolutely magical 🪄

Read 32 tweets