Quote from: takuma sato on May 01, 2025, 03:30:54 PM

Looks like Bitcoin Knots may be a good way to protest against this. It has Bitcoin Core functionalities and you are actively voting against this PR by running a node.

Yeah, it's best option if you don't want to rely ordinals and similar stuff. Although some people may feel hesitant to use it since AFAIK it only maintained by few people.

Quote from: d5000 on May 01, 2025, 04:21:08 PM

Quote from: takuma sato on May 01, 2025, 03:30:54 PM

It's clear to me now that the whole argument for this PR is, "the blocks are empty so we must come up with ideas to fill the blocks".

No. In reality it's the opposite. As far as I interpret the idea, the purpose is "if you want to fill the blocks with data, then please don't clutter our UTXO set and don't misuse Taproot for that purpose".

The PR probably tries to make OP_RETURN the most attractive way to store data on the chain. From the point of view of full nodes OP_RETURN is the cheapest way, i.e. the one with lowest resource consumption, because everything behind an OP_RETURN opcode can be pruned and is ignored.

If it's goal of that PR, then it failed miserably. IIRC arbitrary data on Taproot witness data only have 1/4 weight size compared with arbitrary data on OP_RETURN. It have implication spammer could pay lower fees by misusing Taproot and store bigger arbitrary data in a TX.

Quote from: d5000 on May 01, 2025, 04:21:08 PM

The problems are mechanisms which use fake public keys to store data. You can't prevent these methods without drastically changing the Bitcoin transaction format. These transactions look the same as any regular transaction, but they can contain dozens of fake public keys, i.e. hundreds of bytes of JPEGs and other shit. These methods are highly undesirable in various ways.

And looking at Ordinals hype, paying additional 564 satoshi for each fake public key/address isn't problem for spammer.

Quote from: d5000 on May 01, 2025, 04:21:08 PM

However, as I already wrote, the removal of -datacarriersize is imo too invasive and thus I'm still NACK. I would probably support it if only the default standardness setting was removed.

I get your point, although i expect most people who run node never change value of -datacarriersize.