Is the Bitcoin network starting a UASF over this inscription stuff? \ stacker news ~bitcoin

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...

view all related items

239 sats \ 4 replies \ @melvincarvalho 9 Feb 2023

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

191 sats \ 3 replies \ @jeff OP 9 Feb 2023

I just want everybody to get along. We can't squabble amongst ourselves. Divided, we're distracted and weak.

0 sats \ 2 replies \ @shyfire 9 Feb 2023

Ordinals is a reasonably effective terrorist attack

0 sats \ 1 reply \ @DemandUtopia 10 Feb 2023

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.

0 sats \ 0 replies \ @shyfire 10 Feb 2023

Agreed. Which is why I like framing it as an attack.

55 sats \ 0 replies \ @DarthCoin 9 Feb 2023

To enable both communities

wait... what have to do bitcoin community with monkey jpegs community (if you can call that a community)?

10 sats \ 2 replies \ @Brunswick 9 Feb 2023

Its curious the ordinal/nft problem emerged at the same time as adoption of nostr.

2 sats \ 1 reply \ @petertodd 9 Feb 2023

Nostr isn't even closely linked to Bitcoin from a technical point. It has nothing to do with ordinals.

0 sats \ 0 replies \ @Brunswick 9 Feb 2023

I know they are completely separate systems. Its curious they caught on at the same time, perhaps another system can cure the underlying problem?

30 sats \ 1 reply \ @ursuscamp 9 Feb 2023

There won't be a fork over this.

3 sats \ 0 replies \ @sime 9 Feb 2023

No fork for you.

30 sats \ 19 replies \ @petertodd 9 Feb 2023

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.

126 sats \ 18 replies \ @supertestnet_phone 9 Feb 2023

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.

82 sats \ 13 replies \ @petertodd 9 Feb 2023

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.

86 sats \ 11 replies \ @supertestnet_phone 9 Feb 2023

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?

60 sats \ 0 replies \ @melvincarvalho 9 Feb 2023

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 ...

2 sats \ 9 replies \ @petertodd 9 Feb 2023

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

50 sats \ 8 replies \ @supertestnet_phone 10 Feb 2023

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.

22 sats \ 2 replies \ @petertodd 10 Feb 2023

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.

60 sats \ 1 reply \ @super_testnet 10 Feb 2023

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?

view replies

10 sats \ 4 replies \ @supertestnet_phone 10 Feb 2023

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.

222 sats \ 3 replies \ @DemandUtopia 10 Feb 2023

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.

view replies

70 sats \ 0 replies \ @melvincarvalho 9 Feb 2023

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!

40 sats \ 2 replies \ @Murch 9 Feb 2023

Describing all past protocol improvements as a form of censorship is an odd way of thinking about protocol development.

50 sats \ 1 reply \ @super_testnet 9 Feb 2023

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.

10 sats \ 0 replies \ @gandlaf21 10 Feb 2023

Damn, that's a very interesting way of looking at it. well said sir

0 sats \ 0 replies \ @melvincarvalho 9 Feb 2023

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

20 sats \ 0 replies \ @RdioActiv 10 Feb 2023

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.