Multisig Script: Resolving Incoherence In Legacy Policy

by Admin 56 views
Standardizing Policy Rules for Legacy Multisig Scripts: Resolving Incoherence

Hey guys! Let's dive into a critical discussion regarding the standardization of policy rules for legacy Multisig scripts in Bitcoin. Over the years, the policies governing these scripts, especially legacy ones, have evolved in a rather piecemeal fashion. Various pull requests have tweaked the legacy multisig script policy without fully considering the wider implications. This has led to some inconsistencies that need addressing to ensure a smoother, more coherent system for everyone involved in the Bitcoin ecosystem.

Current Status of Legacy Multisig Script Policy

Currently, the legacy multisig script policy has some quirks that might seem a bit odd. Let's break it down:

  • Legacy multisig outputs in transactions can be at most m-of-3. All pubkeys in such outputs must be in the form of a compressed pubkey, an uncompressed pubkey, or a hybrid pubkey.
  • Legacy multisig inputs being redeemed in transactions can be m-of-n with m and n both being 20 or less. Any public keys processed by OP_CHECKMULTISIG must be either compressed or uncompressed pubkeys. Hybrid keys or other data blobs are only allowed in the unprocessed part of the public key list.

While it's generally acceptable for legacy multisig output creation policy to be stricter than redemption policy, it's a bit puzzling to allow hybrid keys in outputs but then disallow them as inputs. It doesn't quite add up, right? This inconsistency can lead to confusion and potential issues for users. It's like saying, "Hey, you can put this type of key in, but you can't take it out!"

Moreover, the evolution of legacy multisig policy hasn't been consistent. Back when legacy multisig outputs were introduced as standard by BIP 11, "pubkeys" were allowed to be any value between 33 and 120 bytes. Some Bitcoin users took advantage of these more relaxed policies and created legacy multisig script UTXOs that were redeemable back then, but are no longer redeemable under today's policies. This means some UTXOs have become effectively soft-confiscated. To put it simply, these UTXOs were valid when created but have since become unspendable without direct miner intervention due to policy changes.

Understanding the Impact

Imagine building a house according to the building codes at the time, only to find out later that the codes have changed, and now your house is technically non-compliant. That's the situation some Bitcoin users find themselves in with these legacy multisig scripts. The UTXO 4dacd03d73cb497229dbfe2e7209adc4221540efe0e4c57f408b09b2fd36ece6:1 from 2014-01-12 is just one example of this. Analysis suggests that there are at least 147,470 such UTXOs that have effectively become stuck, requiring a miner's assistance to be spent, which isn't ideal for a decentralized system.

Tasks to Restore Coherence

Based on thorough research, there are four key tasks that need to be completed to bring legacy Multisig policy back into a state of coherence. These tasks aim to address the inconsistencies and ensure that the rules are fair and logical for everyone.

1. Ban Hybrid Keys in Legacy Outputs

First, we need to strengthen the rules surrounding the creation of legacy multisig (and legacy single sig) outputs to ban the use of hybrid keys. These keys are nearly impossible to redeem, creating unnecessary complications. However, it's crucial that we only strengthen the policy around creating new legacy script outputs and avoid further restricting the policy around redeeming existing legacy script UTXOs. We don't want to make more UTXOs unspendable!

Why ban hybrid keys? Hybrid keys are essentially a relic from the early days of Bitcoin and don't offer any significant advantages. By disallowing them in new outputs, we can simplify the ecosystem and reduce the potential for confusion and errors.

2. Align Legacy Script Redemption Policy with P2SH Redeem Script Policy

Next, we should bring legacy script redemption policy in line with P2SH (Pay-to-Script-Hash) redeem script policy. P2SH redeem script policy has also evolved over time, and the current policy allows any scripts as long as they have a limited number of CHECKSIG-related operations. There's no compelling reason why legacy scripts should be subject to significantly more stringent constraints than P2SH redeem scripts.

Why align these policies? Aligning these policies would simplify the rules and make it easier for developers and users to understand the system. It would also prevent situations where valid P2SH scripts are rejected as legacy scripts due to overly restrictive rules. Basically, let's make the rules make sense across the board!

3. Relax SCRIPT_VERIFY_STRICTENC Policy to Only Ban Hybrid Keys

The SCRIPT_VERIFY_STRICTENC policy, introduced in PR #5247, went a bit overboard in its attempt to eliminate the use of hybrid keys. It inadvertently made UTXOs that already existed at the time unspendable. PR #33755 partially reverts this change, ensuring that only hybrid keys are excluded from processing in CHECKMULTISIG. This is a crucial step in restoring spendability to those previously stuck UTXOs.

Why is this relaxation necessary? The original policy was too broad and had unintended consequences. By relaxing it to focus solely on hybrid keys, we can correct the issue without compromising the security or functionality of the network.

4. Align SCRIPT_VERIFY_WITNESS_PUBKEYTYPE Policy with BIP 143 Requirements

This task is technically separate from legacy multisig policy, as it concerns Segwit V0 multisig policy. However, the policy implemented in Bitcoin Core doesn't match the policy stated in BIP 143 (Bitcoin Improvement Proposal 143). These policies should be brought into agreement, either by implementing the policy correctly (as #33759 does) or by amending BIP 143 to accurately describe the current policy as implemented.

Why is this alignment important? Consistency is key! Having the implemented policy match the documented policy ensures that developers and users can rely on the specifications and avoid unexpected behavior.

The Importance of Completing Tasks 2 and 3

Notably, both tasks 2 and 3 need to be completed to make stuck UTXOs, like 4dacd03d73cb497229dbfe2e7209adc4221540efe0e4c57f408b09b2fd36ece6:1, spendable by policy again. These UTXOs aren't inherently problematic or abusive. They were simply caught up in the policy changes of PR #5247, which was primarily focused on banning hybrid keys.

It's important to remember that these UTXOs were valid when they were created and only became unspendable due to subsequent policy changes. Restoring their spendability is a matter of fairness and consistency.

Example UTXO

Consider the script from UTXO 4dacd03d73cb497229dbfe2e7209adc4221540efe0e4c57f408b09b2fd36ece6:1:

OP_PUSHNUM_1
OP_PUSHBYTES_33 035bceeb417f25beaa28d133ee7b28faa1e4f5c2f76b8daf12c3fab18261718790
OP_PUSHBYTES_33 1c434e545250525459000000000000000000000001000000004190ab0000000000
OP_PUSHNUM_2
OP_CHECKMULTISIG

This script doesn't contain any hybrid keys or anything that resembles them. It was simply a casualty of overly broad policy changes. By addressing the inconsistencies in the legacy multisig policy, we can ensure that UTXOs like this one become spendable once again, promoting a more robust and user-friendly Bitcoin ecosystem.

In summary, these four tasks are essential for resolving the incoherence in legacy Multisig policy. By banning hybrid keys in new outputs, aligning legacy script redemption policy with P2SH, relaxing SCRIPT_VERIFY_STRICTENC, and aligning SCRIPT_VERIFY_WITNESS_PUBKEYTYPE with BIP 143, we can create a more consistent, fair, and understandable system for everyone involved in Bitcoin.