Nostr Web Client

Well written and this is fun btw. Strong arguments to be sure. You’re right that Bitcoin encodes moral principles. The supply cap, signature verification, and PoW all instantiate “thou shalt not steal.”

But here’s the distinction: those principles define what Bitcoin is, not what Bitcoin allows. They’re constitutional, not regulatory.

The 21M cap and signature requirements are about Bitcoin’s nature as sound money. They don’t require ongoing interpretation. But filtering transactions by content means case by case moral judgments about what’s immoral, and that necessarily varies.

Bitcoin’s moral architecture is complete in its monetary properties. Adding content morality moves from “this is what money should be” to “this is what money should allow.” That’s a different category.

Your node, your conscience. But I see those as fundamentally different types of moral statements.

Dikaios1517 3mo ago 💬 1

100% this is fun!

I would argue that a large part of the definition of what Bitcoin IS directly flows from what it allows and what it rejects regarding transaction construction. Transactions must be denominated in Bitcoin's base monetary units, not in USD, or ETH, or anything else. Yes, that is definitional of what Bitcoin is and is not, but it is also regulatory of what Bitcoin allows to be stored in a block. Likewise, the block-size limit is a regulation on what Bitcoin allows, but one that serves to protect what Bitcoin is: a decentralized, sound, digital money.

Even the early datacarrier limits that have been adjusted over time were regulatory in order to preserve Bitcoin's purpose of being money, rather than a decentralized file-storage database.

And to be clear, we are not talking about filtering transactions by what sorts of things you are spending your money on. A payment to a hooker and a payment to a church are indistinguishable, so it isn't possible to filter one or the other out on the basis of moral qualms about prostitution or supporting a particular church. Nor should it be, since money should be fungible in order to function properly as money. But I think we should be able to acknowledge there is a massive difference between using Bitcoin for its intended purpose as money to BUY an NFT, even if you or I think NFTs are stupid, vs using Bitcoin for an unintended purpose to STORE an NFT.

Reply to this note

Please Login to reply.

Discussion

Contra 3mo ago 💬 1

You’re right that the line between what Bitcoin is and what it allows isn’t as clean as I made it sound. Block size limits and early datacarrier limits do regulate to preserve monetary purpose.

But here’s my counter. Taproot and SegWit fundamentally changed what Bitcoin allows. Whether intended or not, the community achieved consensus on upgrades that enabled this. That makes inscription capability part of what Bitcoin is now, post-2021.

Retroactively restricting it isn’t preserving Bitcoin’s original nature - it’s unwinding a consensus change that already happened. The time to prevent this was before Taproot activation, not after.

And on the interpretation question: who decides when metadata becomes storage? When a payment becomes a file? Block size is objective. ‘This data is monetary, that isn’t’ requires human judgment on every edge case. That’s the regulatory layer I’m uncomfortable with.

You’ve made a strong case. But I think the consensus ship already sailed, and trying to filter it now is changing Bitcoin, not preserving it.

Dikaios1517 3mo ago 💬 1

I think you are right about consensus ship having sailed, but when it comes to mempool filters, that's not consensus breaking and I don't think anyone is suggesting anything that would be. If they are, I wouldn't support that.

If I understand correctly, the current debate isn't about inscriptions, which primarily use the witness data section of the transaction, making them difficult to differentiate from standard transactions. That is what Taproot enabled and it's debatable what can be done about it now.

As an aside, though, I don't think it is valid to say "Well the consensus was that we wanted Taproot, and the time to stop it was before activation." For consensus to be a valid argument for not doing anything at this point requires that those who supported Taproot activation all were aware that it would enable inscriptions. Otherwise, there definitely was consensus about enabling Taproot, as far as people understood what it would give them, but there definitely was NOT consensus about enabling inscriptions. That can accurately be classified as an unintended use-case of Taproot's features by using an exploit to disguise arbitrary data as part of the transaction's witness section, which no one realized would be the case at the time of activation. That would make it a valid endeavor to patch, if consensus supports activating a proposed patch, in my opinion.

Regarding the datacarrier limit for OP_RETURN, though, that has nothing to do with Taproot. That limit has been in place for years and years. Knots is not the implementation making "a retroactive restriction" on that particular front. Rather, it is Core that is now REMOVING the long-standing datacarrier limit, which was also previously configurable by node runners, but they are removing the option for node runners to set it according to their preferences. That makes the OP_RETURN limit much more akin to the block-size limit, though the change isn't consensus breaking.

Contra 3mo ago 💬 1

Very good arguments. Hopefully this gets itself figured out. What other problems can we solve in the world.

Dikaios1517 2mo ago 💬 1

Mining template decentralization?

Contra 2mo ago

Good one