My five sats on the proposed disabling of bare multisig in relay policy. I don't believe it's useful for Bitcoin Core to do this, because there is strong financial incentive for users of bare multisig to convince node runners to keep it on.

If enough nodes keep relaying them, these transactions will reach miners just fine. So it won't slow down UTXO set growth at all. In that case it's better for all node runners to know what's about to appear in a block (for better fee estimation and maybe to detect pinning attacks if you use lightning).

This is more or less the same dynamic as Peter Todd's attempt to make full RBF a fait accompli, but in reverse. If he succeeds in getting enough relay and mining of full RBF, there's no point in Bitcoin Core holding on to -mempoolfullrbf=false by default.

If you really want to stop these transactions, a soft fork is the only way. But I'm not sure if that's worth it. Perhaps this energy is better spent on developing Utreexo, which makes the entire problem go away (and creates a few new ones, but hey, such is life).

Reply to this note

Please Login to reply.

Discussion

Shameless plug for a three year old podcast episode: https://podcast.sprovoost.nl/@nado/episodes/utreexo-w-ruben-somsen-nado-15

Note that it's already more than 4x more expensive to use this method of data publication:

* it doesn't get the 4x witness discount

* there can only be 1000 bare multisig outputs in a block, which the Bitcoin Core mining algorithm handles by treating each sigop as if it's 20 bytes

You could maybe encourage miners to bump -bytesperblock to 50, but there's no perfect number there. Finding the economically optimal block given two constraints is very hard.