This inscription thing started out silly, was all fun and games.
But if it forks, wouldn't the pro-ordinal chain have higher fees, and that chain will be more secure?
I think we need a patch that allows for the pruning to save the disk space. To enable both communities to stay happy. Any other ideas?
Sigh...
Fees are incidental for many years, the subsidy secures the chain
Bitcoin is best used as a financial network
Cloud storage best at layer 2/3
Once this is consensus, there's a few mitigations. Miners could raise prices for images in the block chain, for example
reply
I just want everybody to get along. We can't squabble amongst ourselves. Divided, we're distracted and weak.
reply
Ordinals is a reasonably effective terrorist attack
reply
I think the damage done by splitting the community is worse than the damage done by adding at most 210 GB of data to the blockchain per year.
reply
Agreed. Which is why I like framing it as an attack.
reply
To enable both communities
wait... what have to do bitcoin community with monkey jpegs community (if you can call that a community)?
reply
Its curious the ordinal/nft problem emerged at the same time as adoption of nostr.
reply
Nostr isn't even closely linked to Bitcoin from a technical point. It has nothing to do with ordinals.
reply
I know they are completely separate systems. Its curious they caught on at the same time, perhaps another system can cure the underlying problem?
reply
There won't be a fork over this.
reply
No fork for you.
reply
No one is suggesting blocking ordinals in mined blocks. That would cause a fork, and a really messy one. People are just suggesting blocking ordinals in unconfirmed transactions, which achieves basically nothing as censorship is hard.
reply
I'm suggesting it. First I want to start with blocking inscriptions via mempool policy, and if the inscription people regularly route around that, I want to start blocking them altogether with a soft fork.
Bitcoin moves forward by censoring things that make bitcoin worse money. Segwit censored transactions that tried to exploit the signature malleability bug. Taproot censored transactions that try to spend from bc1p addresses without a schnorr signature. A long time ago, during the misnamed op_return wars, a mempool policy of censoring op_returns with greater than 80 bytes was successful at stopping that particular type of spam. Before that, during the Satoshi dice era, a mempool policy of censoring 1 sat outputs succeeded at stopping that spam.
Censorship is not bad if the thing you're censoring makes bitcoin a worse money. So I want to do it again. Inscriptions make bitcoin a worse money (in my opinion) by confusing it with BitTorrent (where censorship resistant file storage is already a success). So yeah, I'd like to censor inscriptions because that particular censorship will make bitcoin better money, like segwit did and like taproot did. And if the mempool policy doesn't work I'd like to try a soft fork.
reply
Well you're nuts. There's an endless variety of ways to publish data in Bitcoin, including all the ways we do soft fork upgrades. Censoring this stuff with mempool policy is already kinda silly; censoring it at the consensus layer just adds enormous complexity to it, and will get defeated over and over again.
reply
I wasn't around during the satoshi dice era, is it true that bitcoiners successfully squelched that project through a censoring mempool policy? In your opinion, are Satoshi dice outputs comparable with inscriptions? I think they are because both bloat my node's database with messages/files that would be better stored elsewhere, and both make it harder to sync a node. I think those things make bitcoin worse money. What do you think?
reply
Yes, correct. Satoshi dice was moved off chain. It was basically spam. Once removed bitcoin did very well as a financial network. The story is not over ...
reply
is it true that bitcoiners successfully squelched that project through a censoring mempool policy?
Nope. Nothing was done to discourage it.
If I'm wrong, point me to the git commit that censored it
reply
That git commit is called "Define dust transaction outputs, and make them non-standard"
Because of that code change (made in May 2013), Bitcoin Core began censoring transactions from the mempool if they contained very small outputs. The change was made with this comment:
"Dust" is defined in terms of MIN_RELAY_TX_FEE, which has units satoshis-per-kilobyte. If you'd pay more than 1/3 in fees to spend something, then we consider it dust. A typical txout is 32 bytes big, and will need a CTxIn of at least 148 bytes to spend, so dust is a txout less than 54 uBTC (5400 satoshis)
The minimum relay fee at the time was higher than it is now, later it was lowered by a factor of 10 and the dust limit went down to 540 sats.
reply
No, I'm aware of the dust limit. 5400sats wasn't much money back then, and they could just take it out of the bet up front making it revenue neutral. That's not why Satoshi Dice died.
reply
am I also wrong in saying Gregory Maxwell created a dust limit patch explicitly to avoid relaying satoshi dice transactions? That's how it looks to me from reading that old bitcoin talk thread. If that was the purpose of Greg's dust limit, and a dust limit became the default policy two months later, it seems unlikely that those two things happened independently. Am I missing something?
To provide a bit of context, in March 2013 Gregory Maxwell wrote a patch for bitcoin core that censored satoshidice transactions by refusing to relay or mine transactions with outputs less than 10k sats. https://bitcointalk.org/index.php?topic=149668.msg1598216#msg1598216
This patch was explicitly called out as censorship by people in that thread (see the post by OneMiner at the top of that thread) but within a few months bitcoin merged a code change that implemented a less severe form of the same thing, making the dust limit 5400 sats. Satoshi Dice relied on its ability to create utxos below that dust limit as a way to alert users of the service if they lost. But once that change went into place, the number of dust transactions fell drastically.
In other words, censorship works. I'd like to use it once again and "dust" off this reliable old tool from our tool belt.
reply
I'm not sure it's 100% accurate to say it blocking dust transactions directly killed SatoshiDice. SatoshiDice could have keep running, it would have just cost more (min 10k sats) for each of their "alert transactions". The BTC price going up significatly in 2013 also undermined the SatoshiDice business model.
I think a similar things will happen with inscriptions, as fees rise. Looking at mempool.space, a inscription transaction costs $75+ while a simple payment transaction costs something like $0.25. If the BTC price quadruples (or the sat/B fee rate quadruples) then inscriptions become expensive quickly, while transactions remain perfectly viable for everything more expensive than a coffee.
supertestnet has possibly been the MVP of the bitcoin eco system in the past year
not nuts at all, defo worth listening to all his ideas!
reply
Describing all past protocol improvements as a form of censorship is an odd way of thinking about protocol development.
reply
I think it is fair because all soft forks add rules that make a previously-valid way of transacting invalid moving forward. You used to be able to publish a transaction that does X but now you can't, due to the soft fork. I don't insist that we all call things the same names, but I call that censorship. To me, all soft forks are a question of whether the new rule censors something that really blocks bitcoin from becoming better money. If it does, it's probably a good soft fork, because I want bitcoin to be the best money it can be. And if treating bitcoin like a jpeg repository becomes popular I don't think that will help bitcoin become a better money.
reply
Damn, that's a very interesting way of looking at it. well said sir
reply
So. You can have a policy of being strongly resistant to storing images in the bitcoin block chain
There's a few different places they can be stopped, or made expensive
The question of identifying images in the block chain I think is actually easy. Because the specification is published
It is true that you can just spam the block chain with noise. But, it's pointless and you might run out of satoshis
reply
If idiots with more money than brains want to store JPEGs on the blockchain, so be it. Just makes my coins more valuable.
Besides, this may be the push the L2 networks need to fix scalability problems.
reply