multiple opportunities for developers to permanently cause the loss of user funds. For example, the creation of P2SH-P2WPKH or P2SH-P2WSH addresses requires the strict use of compressed pubkeys, otherwise funds can be irrevocably lost

It may be true in general, but this is not a good example. BIP 32 already introduced strict use of compressed pubkeys, so it’s used by all HD wallets. Dealing with both compressed and uncompressed addresses for the same private key is a major pain. So this restriction should actually prevent bugs.

it is completely reasonable for projects such as the lightning network to reject forming bidirectional payment channels (i.e. a multisignature P2SH address) using non-SW P2SH outputs due to the possibility of malleability

More than “reasonable”, it’s a requirement. Malleabitliy is a key reason why Lightning is still not being used. It’s waiting for SegWit or something similar and it will only work on top of SegWit outputs. I don’t see why this would make fungeability worse than you describe. Transactions that open a channel will be obvious regardless. Until you decide to open a channel, there’s no need to use SegWit outputs, so you can simply “hide” among the regular UTXO set until then.

The discount itself appears to have been determined arbitrarily and not for any scientific or data-backed reasoning.

This may be true for the specific discount, but having a discount by itself increases the incentive to consume, rather than create, UTXOs, which are an expensive resource.

It might be desirable to determine the specific discount using a market mechanism, just as fees are, but this would add enormous complexity. Perhaps it can be done later.

Leave a Reply

Your email address will not be published. Required fields are marked *