I think I agree with your worries and that you're asking the questions more of us should want answers to. Lopp's affiliation with Citrea already bugged me and I do think it's more par foe the course than is great.

By all means we should listen to those looking to build, but they shouldn't get veto power over concerns about preserving ALL of the functionality we currently have.

Risking L1 to work on L2 is the height of folly. I get that Agile is all the rage in software development, but it frankly should not shape the ethos of Bitcoin development.

Reply to this note

Please Login to reply.

Discussion

Tl;dr we're building a cathedral, not burning man, and should act like it.

I agree that we should listen to people who want to build, and even make conservative changes to accommodate them. Core could start to filter inscriptions by default and engage in the whack-a-mole task of continuing to add filters that prevent and discourage arbitrary data outside OP_RETURN, then simultaneously increase the data carrier size limit so OP_RETURN can carry a little more data - e.g. for some reason Citrea apparently needs 144 bytes, so we could set a new limit a little larger than that. I think Adam Back threw around 160 bytes as a compromise number to resolve the v30 drama. That sounds reasonable to me as long as we also stomp out data embedding everywhere else.