Bare Multisig Outputs
-----------------------
Blocks are getting filled with bare multisig outputs and it's an obvious troll from people that hate Bitcoin. Let me explain.
Multisig currently can be done in many ways, but before p2sh (BIP0013), the only way to do multisig was through putting the many pubkeys on-chain. As ECDSA doesn't really let you aggregate keys, outputs had to specify something like "3-of-5 of these pubkeys." The normal UTXOs have the following number of bytes:
p2pkh:25
p2sh:23
p2wpkh:22
p2wsh:34
p2tr:34
By contrast the n in the k-of-n bare multisig determines the number of bytes and it's 5 + 34 * n (my math might be off, but around there). So for 3-of-5, it's upwards of 170 bytes. But that's using compressed keys. For uncompressed keys, you it's 5 + 66 * n or 335 bytes+, and worse, you can put in illegitimate uncompressed keys (keys that are provably have no private key) to add data to the chain
Why does this matter? Because these bytes stay in the UTXO set, which is what Bitcoin software optimizes for because that's how you validate that a transaction is a not double spend and satisfies the conditions of the smart contract that locked it.
What's worse, if the pubkeys are unspendable (uncompressed keys that are not real points on the secp256k1 curve), then they'll *never* be pruned. So the UTXO set grows larger and requires more resources for your typical node runner.
Interestingly, this was how the whitepaper was embedded into the Bitcoin blockchain by putting pieces of the whitepaper pdf in 64 byte chunks through uncompressed pubkeys. Luke's Eligius pool was one of the first to ban such transactions because they were clearly bloating not just the blockchain, but the UTXO set.
That's what these trolls are doing. They're adding to the UTXO set that's not easily prunable, though now, I'm guessing some people will add pruning for UTXOs with multisig outputs that don't have any legitimate keys.
jimmysong /
npub10vl…sp42
2023-12-15 00:20:22
Author Public Key
npub10vlhsqm4qar0g42p8g3plqyktmktd8hnprew45w638xzezgja95qapsp42Published at
2023-12-15 00:20:22Event JSON
{
"id": "376c4e0c4171eed40d9e8213eeb5df6c08e324349ca71b5657c43165753c1913",
"pubkey": "7b3f7803750746f455413a221f80965eecb69ef308f2ead1da89cc2c8912e968",
"created_at": 1702596022,
"kind": 1,
"tags": [],
"content": "Bare Multisig Outputs\n-----------------------\n\nBlocks are getting filled with bare multisig outputs and it's an obvious troll from people that hate Bitcoin. Let me explain.\n\nMultisig currently can be done in many ways, but before p2sh (BIP0013), the only way to do multisig was through putting the many pubkeys on-chain. As ECDSA doesn't really let you aggregate keys, outputs had to specify something like \"3-of-5 of these pubkeys.\" The normal UTXOs have the following number of bytes:\n\np2pkh:25\np2sh:23\np2wpkh:22\np2wsh:34\np2tr:34\n\nBy contrast the n in the k-of-n bare multisig determines the number of bytes and it's 5 + 34 * n (my math might be off, but around there). So for 3-of-5, it's upwards of 170 bytes. But that's using compressed keys. For uncompressed keys, you it's 5 + 66 * n or 335 bytes+, and worse, you can put in illegitimate uncompressed keys (keys that are provably have no private key) to add data to the chain\n\nWhy does this matter? Because these bytes stay in the UTXO set, which is what Bitcoin software optimizes for because that's how you validate that a transaction is a not double spend and satisfies the conditions of the smart contract that locked it.\n\nWhat's worse, if the pubkeys are unspendable (uncompressed keys that are not real points on the secp256k1 curve), then they'll *never* be pruned. So the UTXO set grows larger and requires more resources for your typical node runner.\n\nInterestingly, this was how the whitepaper was embedded into the Bitcoin blockchain by putting pieces of the whitepaper pdf in 64 byte chunks through uncompressed pubkeys. Luke's Eligius pool was one of the first to ban such transactions because they were clearly bloating not just the blockchain, but the UTXO set.\n\nThat's what these trolls are doing. They're adding to the UTXO set that's not easily prunable, though now, I'm guessing some people will add pruning for UTXOs with multisig outputs that don't have any legitimate keys.",
"sig": "5c5d9cdd1d455d737898ae4df3678320bcab8f96033fb47e7b47d5ccba6493e53ffe1a01ae61ec5b8c60aca74390388e4f066341e8236421a1f370743d5aaeae"
}