BIP-444 should be only about placing op_return limits on a consensus level, it would be less messy and would probably get consensus. Down the road other data restrictions could be proposed more carefully.

Reply to this note

Please Login to reply.

Discussion

It doesn’t matter to me what exactly is in BIP-444. The point is to get it underway quickly so the market can start pricing the two competing chains’ coins.

There's alway the option of the bip not going forward wich is probably the best.

Bip-444 should just be ignored. If one wanted to spam the chain with csam one could do it without anyone’s permission using fake pubkeys. There is nothing that this bip does that can stop that.

You’re right that technologically, the fork has no effect. What was possible before remains possible after.

The point of the fork is sociological. Give the Knots folk their own chain with their own rules. A clean break from Core.

The underlying assumption of data contiguity being irrelevant is wrong. That's literally been the entire debate. One side thinking contiguous byte order is irrelevant and the otherside arguing MANY MANY ways that it is. But what ever, forks like this won't stop anything.

Remove OP_RETURN standardness and increase the witness weight to see real results. Then Fake pubkeys, taproot annex, fake sighash, ALL don't matter, as long as you pay.

If spam outbids financials, fair enough. Economics should be the only determinant.

This is not true in the same way as OP_RETURN and that's literally the whole point of contention. This has been stated and refuted nearly millions of times at this point.

Agree that the mechanism is different for how to insert arbitrary data with/without OP_RETURN.

The important thing is to get BIP-444 activated so that the market can price the two chains.

Nah, the fork is doomed to fail for other reasons. Libbitcoin is the only promising implementation and even it is still working on a viable branch for all of its features.