pull down to refresh

I recently listened to Dr. Jack Kruse's talk from Prague (https://www.youtube.com/watch?v=poCzB_D3VQA) and there were some valid concerns that I thought should be talked about. Most of which I was already aware of and makes sense from first principles. But I want to ask others here about what you think.

From a first-principles Bitcoin perspectiveFrom a first-principles Bitcoin perspective

I think there are four questions worth asking:

1. What is Bitcoin's purpose?1. What is Bitcoin's purpose?

  • Digital gold?
  • Settlement network?
  • General immutable ledger?

2. Is blockspace a market or a public good?2. Is blockspace a market or a public good?

If it's a market, inscriptions are just another bidder.

If it's a public good, then protecting monetary uses may justify intervention.

3. What is the bigger centralization risk?3. What is the bigger centralization risk?

  • More chain growth?
  • More governance intervention?

Reasonable Bitcoiners disagree on this.

4. What happens after subsidies disappear?4. What happens after subsidies disappear?

This is the one most people overlook.

Bitcoin's long-term security eventually comes from fees.

Inscriptions have generated enormous fees at various times.

If you remove non-monetary demand, are you strengthening Bitcoin or weakening the future security budget?


I spoke more with GPT about this and this is some of the results that were produced


Bitcoin, Arbitrary Data, and “Ossification Risk” - where is the real concern?Bitcoin, Arbitrary Data, and “Ossification Risk” - where is the real concern?

There’s been renewed debate around Bitcoin’s long-term trajectory due to inscriptions (Ordinals), OP_RETURN usage, and other ways of embedding arbitrary data into transactions.

Some argue this is a serious issue. Others see it as normal fee-market behavior.

I’m trying to understand where the real risk actually is, so I’d like to lay out both sides and get feedback from the community.


1. The concern: blockspace is finite1. The concern: blockspace is finite

Bitcoin has a fixed blockspace limit. That means all demand competes in the same market.

Critics argue that non-monetary data (images, NFTs, etc.) creates:

  • Higher fees for basic payments
  • Faster chain growth
  • Higher node storage and bandwidth requirements
  • Potential long-term centralization pressure

From this view, Bitcoin risks drifting away from being a monetary settlement network.


2. The counterpoint: Bitcoin is a fee market2. The counterpoint: Bitcoin is a fee market

Others argue Bitcoin is intentionally neutral.

If someone pays fees, then:

  • miners include the transaction
  • the network remains economically consistent
  • no one decides what “valid use” is beyond consensus rules

Under this model, inscriptions are just another form of demand for blockspace.


3. OP_RETURN vs inscriptions3. OP_RETURN vs inscriptions

Two things often get mixed together:

  • OP_RETURN: small, structured data field (historically limited)
  • Ordinals / inscriptions: embed data in witness space (much larger payloads)

Most of the recent controversy is actually inscriptions, not OP_RETURN.


4. The deeper concern: “ossification + data load”4. The deeper concern: “ossification + data load”

Some argue a combined risk:

  • Bitcoin becomes increasingly hard to change (ossification)
  • while simultaneously absorbing more non-monetary data usage

The worry is that together this could:

  • increase long-term node costs
  • lock in scaling constraints too early
  • push Bitcoin away from its monetary focus

5. Proposed responses (e.g. BIP-style restrictions)5. Proposed responses (e.g. BIP-style restrictions)

Some proposals suggest restricting certain forms of data embedding at the consensus level.

The goal would be to:

  • reduce inscription-style usage
  • preserve blockspace for financial transactions
  • slow chain growth pressure

6. The controversy: technical fix or governance shift?6. The controversy: technical fix or governance shift?

Critics of restrictions argue:

  • users will find alternative encoding paths anyway
  • filtering transaction types introduces subjectivity
  • it sets a precedent for future “approved vs unapproved” usage

So the debate isn’t just technical — it’s about whether Bitcoin should enforce use-case boundaries at all.


7. Open question7. Open question

It feels like there are two competing models:

  1. Pure fee market: all demand is valid if it pays
  2. Monetary-first design: blockspace should be protected for payments

I’m trying to understand which risk is more real long-term:

  • data usage driving centralization pressure
  • or governance intervention creating deeper systemic risk

Curious how others here think about this.

144 sats \ 1 reply \ @Scoresby 21 Jun

As long as we have a block size limit, I don't believe that use of blockspace leads to centralizing pressure. The price of digital storage continues to decrease faster than the blockchain increases.

Combine a 10 minute average block time enforced by the difficulty adjustment and a 1MB blocksize (even 4MB, with witnesses) enforced by block validity rules and it looks like the size of the blockchain grows in a linear manner while improvements in storage remain exponential.

(recent years look different for SSD because of AI, I think, but I suspect it will revert to a downward trend soon.)

If we feel that the blocksize is still to large to make running a node accessible, we could consider lowering it, but I don't think that changes the fundamental market nature of blockspace.

What do you think about this? You ask the question, but I suspect you have an opinion and I'm curious to hear it.

reply

Thank you!
And no I don't have a solid opinion on it. Just trying to navigate this very confusing conversation and position myself so that it makes sense.

reply

The real ossification risk isn't about data storage — it's about layer separation.

Bitcoin's strength is its minimalism: a timestamped, append-only ledger with a scripting language just powerful enough for multi-sig, time locks, and hash locks. Every feature added to base layer is a trade-off against simplicity, auditability, and node operation cost.

The concern with arbitrary data (OP_RETURN, Taproot annexes, etc.) isn't that blocks will fill with cat pictures — it's that each new use case creates expectations for future protocol changes. Once major economic actors depend on a particular data encoding, changing it becomes politically difficult even if it's technically cleaner.

Taproot's MAST structures actually help here: they let you commit to complex conditions without revealing them until spend time, keeping the visible UTXO set lean. But the real solution is what's already working: enforce the block weight limit (4 Mwu) and let the market decide what's valuable enough to include. If someone wants to pay 50 sat/vB to put data in a taproot leaf, that's their choice — and economically rational.

The true ossification risk I see: if we ever can't do a soft fork because too many economic actors have built on assumptions about what the script language can't do. That's why the current conservative approach (let things bake, don't rush covenants) is actually the right one.

reply

Thank you, makes sense to me!

reply
6 sats \ 0 replies \ @UppercaseDANIEL 21 Jun -21 sats
void tearDown() {

Thread.start {
}

replace(dir:"dirName", includes:"*flea*", token:"tokenName", value:"${value}")market