Another subset of valid transactions are Denial of Service (DOS) transactions, which for one reason or another will cause a node to have a bad time. For example a DOS transasction might crash the node, or cause it to take a very long time to validate. We know about a number of DOS transactions, but presumably there are some DOS transactions which we don't yet know about. So we can add to our diagram two circles, one for all DOS transactions, and within that a smaller circle for the known DOS transactions.

Next we have standard transactions, which are the transactions permitted into the mempool of a node according to it's policy rules.

The default policy rules which come packaged with the latest bitcoin core release are generally adopted by the network within a year. Each release with new policy rules will result in different set of standard transactions, so it's a moving target, but on any given node the rules are set at any given time.

Each node can configure it's policy rules as it sees fit (in theory, more on this later) and transactions must first pass consensus rules before considering policy. This means that there is no risk that using different policy rules will break consensus. Another way to say this is that standard transactions are a subset of valid transactions.

Here is a quick introduction to what bitcoin policy rules are

We start with (consensus) valid transactions. These transactions abide by the bitcoin consensus rules which all nodes on the network enforce. For example, a non coinbase transaction can't spend more than the sum of the inputs.

The recent pull request to bitcoin core made by peter todd (pull 32359) removes the code to enforce a policy limit on the size and number of OP_RETURN outputs. Additionally, he proposes the removal of the configuration options to allow node runners to modify the maximum size of data carrying transactions.

If bitcoin core doesn’t have the functionality that you want you can build it, and share it with the world.

If other people share your views they can also run that code.

Examples of users

The High-Ticket Merchant

Sells expensive goods with incoming funds straight into cold storage. Can’t (or won’t) leave a hot key online for CPFP, and asking the customer to bump the fee is awkward. An auto-accelerator guarantees confirmation so the product can ship without delay.

The Multisig Treasury Custodian

Manages a 3-of-5 vault for a family office. Gathering three signers to recreate an RBF transaction is slow and costly; the automated bump removes that operational friction.

The Air-Gapped Solo Stacker

Signs a single-sig transaction on an offline device just before boarding a long flight or going off-grid. With no way to reconnect, the auto-accelerator acts as a safety net if the initial fee estimate was too low.

Payroll Controller

Payroll is broadcast on Friday and the finance team is away for the weekend. If the mempool spikes, the auto-accelerator silently bumps the fee so employee pay doesn’t wait until Monday.

You are making a transaction, you check mempool and set what seems like an appropriate fee, but then a new degen mint drops and your transaction gets buried. New transactions coming in push your transaction further back, and 24 hours later it's 10 blocks deep.

Fortunately you used Mempool Auto Accelerator with a 24h Time Delay trigger, and your transaction confirms in the next block.

I have 10 beta access spots, dm me.

I guess they REALLY wanted a 1.0 BTC utxo, and no change

unusual 151 sat/vB tx

https://mempool.space/tx/53a2b07caeef425198cc394df8511087b181cf0ab64ad1c42dee3231b2730804

Thanks for the mention!

Thanks to DATUM the nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze team have increased the number of entities finding blocks who constructed their own templates by 13 entities (11 if you assume Just Fo r X is one entity). You love to see it.

nostr:nevent1qvzqqqqqqypzqqke74nkll7r88l7jn06kw97hcsuuytudu2snkvj92pdg485yrdzqqsxvpt2t007thcklrw6x003a6px98srdmjcyaxcs73x5sg599y4eyqcpvm9m

If you are building something on bitcoin and use nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3 every day I want to hear from you, drop me a message.

https://zap.stream/npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx

Also excited to see

1) A renewed interest in transaction verification. Could this be the revival of the "server as a screen" concept the team presented in 2023?

> We want to give Bitkey customers easy ways to verify transaction details and other security-critical operations. First up is a software-driven feature we’ll bring to customers mid-year.

2) Hardware verification (on screen device?) and cold wallet config (FROST? orange.surf/bitkey-notes/)

> We’re also evaluating ways to provide even stronger transaction verification with hardware, and an optional cold wallet configuration for customers who don’t mind putting in a little more effort for more security.

Very interested to learn more about the Privacy improvements. "Predicate blind signing" was mentioned previously by the team in their Oct 2024 post.

https://bitkey.build/building-in-the-open/

# Signing privacy

Predicate blind signing combines blind Schnorr signatures with zero-knowledge proofs that make assertions about transaction attributes. This allows the server to enforce signing policies without learning any identifying information about the transaction itself.

# Vault privacy

For transactions involving funds stored in the vault, the server only signs for the funds outside the vault, adding an extra layer of protection. To preserve privacy while proving funds exist, we use a zero-knowledge proof system similar to the proof-of-solvency approach utilized by exchanges. This method allows the app to prove to the server that sufficient funds exist for a transaction without revealing any specific details about wallet balances or transaction history.

nostr:nevent1qvzqqqqqqypzpq35r7yzkm4te5460u00jz4djcw0qa90zku7739qn7wj4ralhe4zqqsyj978jn6dfwdpk3tstt2xzt22m8rcfrh56y9hllhc0lurhlnxg2q0hvcp7

confused about the different mining options with

@OCEAN ? I've made a table to compare STRATUM (V1) with DATUM.

Will add in STRATUM V2 & DEMAND in the future.

http://poolcompare.orange.surf

should be poolcompare.orange.surf

confused about the different mining options with

nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze ? I've made a table to compare STRATUM (V1) with DATUM.

Will add in STRATUM V2 & DEMAND in the future.

http://poolcomparison.orange.surf

"solo mining" is currently confusing as a term because it's being used to mean different things by different people (often with an agenda).

Sovereign Mining: You select the transactions

Lotto Mining: You get the full block reward

Looking forward to both

Miners use picks, not hammers

🔨 -> ⛏️

https://mempool.space/mining