Replying to Avatar Aaron van Wirdum

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.)
Avatar
SatsAndSports 2mo ago 💬 1

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?

Reply to this note

Please Login to reply.

Discussion

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