Nostr Web Client

As I’ve said before…

Those that wish to block OP_RETURNs and whatever else they see as spam should deploy a UASF to render it invalid.

Those that consider this a form of (or path to) censorship and undesirable should deploy a URSF (user rejected soft fork) to counter it.

Exchanges can offer fork futures long before the actual split happens, gauging market sentiment and informing miners where to direct their hash power at fork point. (Hopefully we’ll see a winner-takes-most dynamic and minimal disruption for non-upgraded nodes, i.e. no large re-orgs.)

Reply to this note

Please Login to reply.

Discussion

Bilthon 2mo ago

I agree, this would probably be the best way to give everyone what they want. The problem is that I think the filter camp doesn't want this, they just want to complain and play the victim card.

Aaron van Wirdum 2mo ago

Right, yeah I agree many probably just want to rile against the “ivory tower elite” they perceive Bitcoin Core to be. Talk (ranting on social media) is cheap.

But I wouldn’t be surprised if some subsection would actually want to put their money where their mouth is and go ahead with a fork. (I suspect this would be a relatively small minority, but we won’t know for sure until they actually do it…)

Packlight 2mo ago

I favour conservatism and strict transaction use. I think it would serve Bitcoin better. That said, I would not bet on futures. Because I’m not putting funds on an exchange. And there is an easier option to show discomfort. Namely, choosing the more conservative node implementation/don’t upgrade for now.

Akashi Hyogo 2mo ago

Conservatism and strict transaction use are opposites in reality. That's the problem many people refuse to understand.

Legion XXI 2mo ago

So let’s explain to people instead of arbitrarily pushing and merging code despite contention.

Akashi Hyogo 2mo ago

Check out the what Bitcoin did episode with Antoine.

It is hard to explain when people like bombastic claims and memes and calling "bad actor" anyone who challenges their mental model.

Also there probably are some bad actors. Combine it with ragebating algos and you end up with shit ton of noise.

Packlight 2mo ago

How do you believe so? I assume because enforcing strict transaction use requires more and more filters in the future? In that case you might be right. But I was referring to being conservative on the use case of Bitcoin. Not necessarily the code base. Although I would also be down to discuss and look for consensus changes to Bitcoin to keep arbitrary data out. I don’t know how and I too like the advantages of P2SH. But I like to think we have decades to think about this. That’s what I mean by conservatism. Not getting frustrated when seemingly good changes to Bitcoin are not there yet after years. That’s okay.

Akashi Hyogo 2mo ago

No. Enforcing strict transaction use requires consensus change -> fork.

Decreasing the volume of spam might be achieved with filters. But does not enforce anything.

(If there is one miner with "custom" mempool filters the spam will be mined. Most of the miners are aware of config file on their node and want to get payed)

Akashi Hyogo 2mo ago

To enforce something on mem pool level means forcing every miner to use that mem pool setting.

Aaron van Wirdum 2mo ago

(If a UASF/URSF split were to happen, non-upgraded nodes would follow whichever chain is the longest.)

waxwing 2mo ago

That's a good point about futures and exchanges. We need a mechanism to bet on the fork outcome inside bitcoin transactions. I think there was some research into that years ago. Hopefully the mechanism doesn't use OP_RETURN 😁

Aaron van Wirdum 2mo ago

Lol!

(And yes that would be even better.)

SatsAndSports 2mo ago

What's a URSF?

Those that run the UASF will build a chain, from a predefined activation height, that doesn't contain any large op_returns

What exactly does the URSF do? It requires that the block at the activation height *must* have at least one large op-return?

Aaron van Wirdum 2mo ago

That’s one way to do it, but would be pretty ugly.

It would be better IMO to activate using BIP8 with LOT=true. That way miners will be required to signal readiness for soft fork activation before some deadline. Blocks that don’t signal would then start being rejected. (Assuming nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk will be involved with this UASF I assume this is what he’ll prefer as well.)

The URSF client should then use these same signals in the opposite way; it should start *rejecting* blocks that signal readiness.

This way you get a relatively clean split at a (more or less) predictable time.

jo 🇺🇸 2mo ago 💬 1

correct

Laukess 2mo ago

I can't decide if I like hard-forks more. Seem like a cleaner solution. You want a braking change, or can't get a soft-fork through, make a fork, it either gains adoption and becomes bitcoin, or it dies a shitcoin.

Aaron van Wirdum 2mo ago

Also fine (arguably better even, indeed), but no real upside from the filterers’ perspective, so unlikely they’ll go that route imho.

Laukess 2mo ago

True. Maybe it was because I had only been in bitcoin about a year at the time, but when the big blockers broke off from bitcoin, the signal-to-noise ratio went up a lot. But your right, probably not what you want if you want to hard-fork and you know you are the minority.

I wonder if we'll see more hard-forks in the future. It seems like we already have a hard time agreeing to activate soft-forks that are a lot less controversial. Doubt it'll be any easier in the future.

ede3d957... 2mo ago

May I introduce:

The BlackRock fork

nostr:nevent1qqsx88jnn5mu864c8sjtvl50ttacxu7wwl2d895l2zkxf4558ukqvecpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzp6xk03p45jjexp8pg9pgp62jalshhep9fl9z0ytt7cle7ul9f2ayqvzqqqqqqyar8qzq

Luke Dashjr 2mo ago

Policy is the right way to implement spam filters.

Aaron van Wirdum 2mo ago

Does that mean you won't support a soft fork like this?

Luke Dashjr 2mo ago

To address spam, no.

To address Core 30 malware, maybe.

Aaron van Wirdum 2mo ago

How would one address “Core 30 malware” with a soft fork?

Luke Dashjr 2mo ago

https://gnusha.org/pi/bitcoindev/CALeFGL0PDjtRt2rfbY4gTkoc+5oNQ0mn_obraE7PrtHuNYFpQw@mail.gmail.com/T/#mb71350c5dfb119efeb92c5ee738b6c8225bf15b6

Akashi Hyogo 2mo ago

This spam solution I can respect (not that it matters lol).

Auto expiration - great idea.

Going after actual problem.

Increasing cost after limit - great idea.

Aaron van Wirdum 2mo ago

If Bitcoin Core 30 did not exist, would you call what you’re proposing to render invalid here “spam”?

Pepe López 2mo ago

but against corrupt devs, what?

David Cavan Fraser 2mo ago

Disagree

BTC-Satan 2mo ago

Kayne 2mo ago

A hard fork is inevitable once enough people update to core 30. The blockchain without childporn will retain the title of Bitcoin.

This entire scenario has already played out before.

Nobody wants to run a node full of spam, it costs more money to run.

And when that spam includes child abuse material obviously no one wants to go to prison for hosting that.

Core 30 will destroy themselves.

You don't even have to run knots, just refuse to update if you're running core already

Aaron van Wirdum 2mo ago 💬 1

That’s been in there for years.

https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content

Note Appreciator 2mo ago

But that report linked in the article is referring to the arbitrary data being disguised as standard transactions.

“Beyond intended recording of financial transactions, Bitcoin’s blockchain also

allows for injection of non-financial data, either short messages via special trans-

action types or even complete files by encoding arbitrary data as standard trans-

actions.”

If it were written today they could just say: Bitcoin allows users to inject complete files.

There is a difference between allowing file uploads and a user misusing a form to encode arbitrary data.

Aaron van Wirdum 2mo ago 💬 1

No there isn’t.

Note Appreciator 2mo ago

If you run a music sharing website and allow uploads and downloads of audio files and someone tricks your application into accepting images by making them appear as if they were audio files—that seems very different to me from say a site that just allows any file under a certain limit to be uploaded and stored.

In both cases the images are received by the server and stored in the database (so you’re correct to say there is no difference in that sense) but the principle is very different. In the former case it is clear that the user is violating the website’s terms of service and engaging in deception to accomplish the goal with zero support from the webserver. In the latter case the website is signaling that this uploading images is an acceptable use.

Aaron van Wirdum 2mo ago

Bitcoin has no terms of service.

Kayne 2mo ago

One single .jpg spread between multiple blocks and links to websites that for the most part have been shut down already.

Is not the same as.

Being able to upload images and short videos directly.

According to your article Interpol identified this as a potential threat back in 2015.

The blockchain has already been forked over this before.

It's inevitable that once enough people update to core 30 that the blockchain will be forked again.

Even if you removed the threat of illegal material and malware it comes down to cost.

Cost to build and run a node, higher fees to spend sats.

Aaron van Wirdum 2mo ago

> The blockchain has already been forked over this before.

No it hasn’t. (What are you referring to?)

Kayne 2mo ago

Another fork is on its way.

History repeats.

Bitcoin is money, the blockchain without the spam will remain Bitcoin.