pull down to refresh
126 sats \ 18 replies \ @supertestnet_phone 9 Feb 2023 \ parent \ on: Is the Bitcoin network starting a UASF over this inscription stuff? bitcoin
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.
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
I think I found it: https://github.com/bitcoin/bitcoin/commit/8de9bb53af32f7f6b09c06f831f2c0a7b4e95303
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?
reply
What I think you're missing is that the dust limit doesn't stop a service like Satoshi Dice from existing. It just forces the service to operate in a less harmful way, by ensuring that UTXOs crated by it can be profitably spent.
The timing is just coincidental.
reply
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.
reply
SatoshiDice could have keep running, it would have just cost more (min 10k sats) for each of their "alert transactions".
Even that isn't true. It's not a real cost. Just money they have to take out of the bet that they're giving back to the user in a few seconds when the bet completes.
reply
Thanks the clarification, I'm not an expert on the specifics. But from what I remember from around that time, is that SatoshiDice was basically "priced out" of using the Bitcoin blockchain as the transaction fees rose above a fraction of a penny.
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