Answer to this question from a few days ago: mempool.space helpfully shows you a decoding of the scriptSig; in this case you can see that a 2 of 3 multisig was being used. However, there are two things rather strange about this multisig redemption script.

First, the keys are using uncompressed encoding. You can see this because the pubkeys start with "04". Further, an uncompressed pubkey then displays the x and y coordinates of the point, in that order, meaning the total size of each pubkey is 65 bytes. Uncompressed pubkeys, starting with 03 or 02 instead of 04, take only 33 bytes and are therefore universally preferred (in the DER encoding used pre-taproot; taproot uses a 32 bytes serialization, instead).

These uncompressed pubkeys were relatively common in the early days of bitcoin, and famously persisted in isolated use cases e.g. the bitmex deposit account which was something like a 4 of 5 uncompressed key multisig - very space inefficient.

Anyway, that's only part of the story here: you'll notice that the 3rd of the 3 pubkeys, while being marked again as uncompressed ("04") actually only has 33 bytes, not 65. This is simply user error; this is NOT a valid pubkey encoding.

This is a corner case; it does *not* break consensus to have one of the N pubkeys in an M of N multisig be invalid, *if* the signatures provided in the scriptSig are valid for keys other than the invalid one.

It was however, not *standard*, so this transaction had to be submitted manually to a miner.

The question is not trivial of course; if pubkeys are allowed to be invalid in multisigs, does it help people use them to embed data? And, is that something anyone should care about? And, even if you restrict consensus to only allow valid pubkeys here, does that make any difference? Can people embed data anyway (hint: yes)?



nostr:nevent1qqsrged0nafpusc0lwts4dknfq9enfnsw028rl9mcglcvc6a3udc7zgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygr8twz0ua0zz64eglr58rh9r898wafhdh0stkklhf3830gp9cwh9qpsgqqqqqqs6srw67