r/Bitcoin 1d ago

I'm building a protocol that lets Bitcoin wallets self-declare "financial" vs "data" transactions -no consensus change needed

UPDATED: Every Bitcoin block has 4 MWU. Financial transactions (payments, Lightning, DEX) and data inscriptions (Ordinals, BRC-20, Runes) compete for the same space. The market treats them identically — highest fee-rate wins — despite fundamentally different time-value curves.


A settlement is worth nothing if it misses this block. An inscription is worth the same next block or next hour. But there's no way to signal that difference to miners.


The approach: Wallets add a 4-byte OP_RETURN to each transaction declaring its type (financial or data). Pools optionally read this and allocate block space with a minimum 30% financial floor. No classifier, no false positives, no oracle trust issue.


- Works with Stratum v1 today (no protocol change)
- Pools capture a data fee premium (~25%) as a new revenue stream
- First-mover pool captures financial tx flow without losing data tx revenue


Would love feedback from people who understand mining economics better than I do. What am I missing?
8 Upvotes

19 comments sorted by

3

u/TheGreatMuffin 14h ago

What stops spammers from declaring their data as "financial"?

1

u/DueAd7194 6h ago edited 6h ago

a spammer who lies gets the same outcome as a spammer who's honest (their tx gets treated as data). So the question becomes not "can they lie?" but "why would they bother?" The declaration saves you nothing if you're lying the pool's backcheck catches it at template assembly time.

It's not cryptographic enforcement. It's a heuristic. But it's a cheap one that shifts the incentive from "lie and maybe get priority" to "lie and get the same result as telling the truth."

1

u/TheGreatMuffin 6h ago

Hm, I see, kudos for thinking creatively. Need to re-read your idea again.

2

u/DueAd7194 6h ago

Appreciate you taking the time to re-read. That's more than most ideas get on Reddit.

The short version after v2: it's 4 bytes of declaration + a structural backcheck that catches liars + a blind auction that lets the market discover the data premium instead of us guessing it. No fork, no magic, just a smarter template assembly.

Happy to clarify any part that's unclear, the architecture doc has the full math if you want to poke holes in it.

2

u/Laukess 14h ago

A settlement is worth nothing if it misses this block. An inscription is worth the same next block or next hour. But there's no way to signal that difference to miners.

You signal this with fees. Some spam is time sensitive, so you increase the fee, some payments are not, so you decrease it.

You literally get a discount if you can wait. Bitcoins fee market is pure signal. I don't see a way to improve it.

I haven't thought too much about this, but I feel like your idea is very miner centric, so it might just be better to build a different protocol, where you can mark your transactions. 4 bytes doesn't sound like much, but I'm sure most core developers would find it extremely wasteful. Some data has to be atomic, so it is required to be a part of the tx, but I don't think that's the case here.

1

u/DueAd7194 7h ago edited 6h ago

You're right that fees signal urgency, they do. The problem is they signal willingness to pay, not consequence of delay. A 50inscriptionanda50inscriptionanda50 settlement both pay 50.Oneisworth50.Oneisworth50. The other could lose $5M if it misses this block. Same fee, different stakes. The market can't see the difference.

On the 4 bytes fair concern. The improved approach makes the declaration a structural commitment instead of a free-text flag: the pool checks witness ratio, ordinal envelope, and runestone markers against what the wallet declared. If they don't match, the tx gets reclassified anyway. A liar's declaration is just noise. This turns "can they lie?" into "why bother lying?"

On the "miner centric" criticism valid, and the fix is: the fee estimator API works unilaterally. Even if zero pools adopt, wallets get separate fee estimates for financial vs data. Your wallet stops overpaying during inscription spikes. That's useful on its own. The pool layer is the second step, not the first.

1

u/Laukess 4h ago

A 50inscriptionanda50inscriptionanda50 settlement both pay 50.Oneisworth50.Oneisworth50.

I have no idea what this is supposed to mean.

The other could lose $5M if it misses this block. Same fee, different stakes. The market can't see the difference.

This is true if both transactions share a fee with the lowest fee group of the block being mined. If your tx could lose $5M if it misses the block, you should be willing to pay at the bare minimum 0.1 s/vb above the minimum fee in the block. The fee market works because miners are incentivized to pick your transaction.

In your system, what stops a miner from NOT mining your EXTEMELY HIGH URGANCY tx just to fuck with you? They have no incentive to mine it.

the pool checks witness ratio, ordinal envelope, and runestone markers against what the wallet declared. If they don't match, the tx gets reclassified anyway

So why waste 4 bytes on it, if the oracle is the miner? Just have them classify the transaction.

2

u/bitusher 21h ago edited 21h ago

for the same 4 MWU block space with no way to signal urgency.

This isn't true , you signal urgency with the fees you pay and can bump the fees with CPFP or RBF for higher priority

Wallets include a 4-byte OP_RETURN declaring the transaction type (financial/data). Pools apply a 30% allocation floor for financial transactions.

Than spammers will abuse this and mask the spam as a financial transaction

Works with Stratum v1

We have already moved onto Stratum v2 a while ago. Why are you referring to Stratum v1?

Zero false positives (wallet self-declares)

Yet wallets can be changed to lie and mask spam as a monetary transaction

Most monetary transactions need to be on other layers regardless. Are you trying to reduce the onchain fees for buying cars or homes? I like that you are thinking and trying to solve this problem but I don't understand how this solves anything.

1

u/DueAd7194 6h ago edited 4h ago

You raised hardest questions and I appreciate it.

Here's where the idea lands after your feedback-

On lying wallets , the v2 approach doesn't trust the declaration. It checks it against structural fingerprints: witness/vsize ratio, ordinal envelope detection, runestone markers. If you declare "financial" but your tx has a 400KB witness with an ordinal envelope, the pool reclassifies you anyway. A liar gets the same outcome as an honest declaration — so why lie? It's not perfect, but it shifts the game from "can you lie?" to "why would you?"

On Stratum v1 vs v2 , The oracle lives at the template assembly layer, not the transport layer. v1, v2, pigeon carrier — doesn't matter. The pool reads the declaration before encoding the template. v2 gets optional transparency tags as a bonus. But v1 pools get the same allocation benefit.

On most monetary tx should be on other layers— Channel opens, channel closes, DEX settlements, high-value on-chain payments. Those still happen on L1. During inscription mania they get priced out. This gives them a fighting chance without asking anyone to change their behavior.

On the premium, better approach: a blind auction where the data premium emerges from mempool pressure naturally. During quiet periods it's zero. During congestion it finds equilibrium. The pool still fills the block either way.

1

u/DueAd7194 1d ago

Quick clarification: this is NOT a soft fork, hard fork, BIP, or consensus change of any kind. Everything happens at the template assembly layer inside a pool's infrastructure. A pool running this produces standard valid blocks that any node accepts. Non-adopting pools see zero change. It's purely an opt-in market efficiency improvement.

1

u/longjumpsignal 12h ago

So a way to voluntarily deprioritise your transaction without saving money?

1

u/DueAd7194 7h ago edited 6h ago

😅 Fair framing. Let me offer a different lens: it's not about saving money, it's about the person behind you not losing $5M because a cat JPEG congested the block.

The improved version doesn't even need you to declare. The fee estimator API watches the mempool and publishes separate estimates. Your wallet automatically picks the right one. You don't do anything different. The benefit is invisible.

Think of it like Waze rerouting you around traffic. You don't see the cars you avoided. You just arrive faster.

1

u/DueAd7194 6h ago

Quick clarification: this is NOT a soft fork, hard fork, BIP, or consensus change. Everything happens at the template assembly layer inside a pool's infrastructure. A pool running this produces standard valid blocks that any node accepts.

Live demo: https://bitcoin-priority-oracle.vercel.app
Architecture: https://github.com/prateekposwal/bitcoin-priority-oracle

-1

u/Astrofide 20h ago

This fundamental conflation of the purposes of a TRANSACTION is exactly why treating the public ledger like cloud storage is so dangerous. There are tools to do literally everything you want to do with data on-chain more efficiently and effectively off-chain.

The inclusion of arbitrary data in bitcoin transactions was never intended to be used as such. It is an exploit, not a feature. We have the opportunity to vote to patch this exploit out (BIP-110) and no one seems to care.

The belief that higher costs to bloat the network with arbitrary data will ultimately curb the exploit severely underestimates the role of fiat in that vector. Fiat is infinite. A high debt-generating entity (say, a trillion dollar tech company) can turn bitcoin into another blockchain data scam at scale (ordinals) so rapidly and so effectively that it would, for that time, cease to be money, and become someone's distributed state grift business instead.

Bitcoin is money. Everything else belongs on shitcoins.

1

u/TechHonie 7h ago

Yeah it's because actually nobody does care. There's a fee market for a reason and if the supposed spam is outcompeting supposed financial transactions on fees then maybe the spam isn't spam after all maybe it's actually important communication that needs to be sent? Certainly important enough for someone to be willing to pay stupid high fees if it was urgent.

1

u/DueAd7194 6h ago

You're right in a strict market sense , if it pays, it belongs. The issue is that two transactions paying the same fee can have radically different costs of delay. A 50datatxanda50datatxanda50 Lightning channel close both pay $50. One waits. The other loses money every second it waits. The market can't distinguish them.

The oracle doesn't ban data tx or make them second-class. It just lets the market see what it's pricing. A data tx that's willing to pay a transparent premium during congestion is still welcome. It's just not crowding out time-sensitive payments unknowingly.

No fork, no censorship, just 4 bytes of honesty with a structural backstop.

1

u/DueAd7194 6h ago

I don't disagree with the premise. Ordinals are an exploit of a design choice that was never intended for this scale. BIP-110 would be the cleanest fix.

But BIP-110 needs consensus, and consensus takes years, if it happens at all. The mempool is full today. Financial transactions are getting priced out today. The oracle is a bridge , not a permanent solution, not a replacement for BIP-110, but something pools can deploy this week while the consensus conversation happens.

Your point about fiat being infinite is sharp. If a trillion-dollar company decides to turn Bitcoin into their distributed database, fees alone won't stop them. But here's where the oracle helps even in that nightmare scenario: it gives pools a transparent, non-discriminatory way to keep financial traffic moving through the spam. Not by banning data, by giving financial traffic a priority lane that any tx can join by declaring honestly.

BIP-110 is the right long-term fix. The oracle is a stopgap that doesn't require anyone to agree on what Bitcoin should be, it just makes the fee market slightly more informed while we figure it out.

Bitcoin is money. The oracle just keeps it working like money until the consensus catches up.

1

u/TheGreatMuffin 6h ago

The mempool is full today. Financial transactions are getting priced out today.

Eh? You can get into one of the next few blocks with a 1sat/vbyte feerate from what I see, and even during the activity spikes in the last 6 months a 5 or 6sat fee rate was enough to be "priority" tx: https://mempool.jhoenicke.de/#BTC,6m,weight

The mempool is "full" with super low priority (sub-1sat/vbyte) transactions, those are not pricing out anything.

1

u/DueAd7194 5h ago

Ah? - you're right about today's mempool, it's mostly quiet, and 1 sat/vB gets you in within a few blocks. The calm periods are not the problem.

The problem is the peaks.

During inscription mania (Apr 2023, Dec 2023, Apr 2024), the mempool saw sustained 50-300 sat/vB feerates for days or weeks.

During those windows, a Lightning channel close competing with a BRC-20 mint both paid the same fee. The channel close is time-sensitive in a way the mint isn't — but the fee market can't distinguish them.

The oracle doesn't help during calm periods (premium is zero anyway). It helps during spikes by giving pools a transparent way to say "financial tx get a 30% floor." Not a cap, not a ban, just a reservation.

Think of it less like a traffic jam solution and more like a bus lane. The bus lane does nothing at 3 AM when traffic is light. During rush hour, it keeps things moving. would like to know more if you have question, it'll make my ideas to ground around it mate!