OP_CHECKMULTISIG

바이트 0xae는 공동 수탁을 가능하게 한 요소입니다. 이 바이트는 키 개수, 그 개수만큼의 공개 키, 필요 서명 개수, 그 개수만큼의 서명, 그리고 마지막으로 한 항목을 더 스택에서 꺼냅니다. 합의 규칙은 한 번의 호출에서 최대 20개의 키를 허용합니다. 이 덕분에 기업은 임원 다섯 명 중 세 명의 승인을 출금에 요구하면서도 그중 누구도 단독으로 행동할 수 없게 할 수 있습니다.

작동 방식

검증은 탐색이 아니라 두 목록을 따라 내려가는 단일 통과입니다. 이 옵코드는 서명을 순서대로 훑으면서 각 서명을 연속된 공개 키에 차례로 대입하므로, 서명은 자신이 속한 키와 같은 상대 순서로 나타나야 합니다. 유효한 2-of-3을 두 서명의 순서를 바꿔 제시하면 스크립트가 실패하며, 이는 사람이 멀티시그 지출을 직접 조립할 때 흔한 혼란의 원인입니다.

스택에는 항목이 하나 모자라게 남으며, 늘 그랬습니다. 원래 구현은 쓰지도 않는 요소를 하나 더 꺼냈는데, 이는 기존의 모든 코인을 깨뜨리지 않고서는 없앨 수 없는 버그였습니다. 서명자들은 먼저 버릴 항목을 푸시하는 법을 익혔고, BIP-147은 블록 481,824부터 그 항목이 비어 있어야 한다고 요구하여 그로 인한 가변성을 막았습니다.

비용 계산에서 문제가 드러납니다. 숫자 옵코드가 바로 앞에 오지 않는 한, 단순 호출은 실제로 키가 몇 개 들어 있든 20개의 서명 연산으로 청구되며, 숫자 옵코드가 앞에 오면 그 숫자로 청구됩니다. 블록은 서명 연산 비용 80,000 단위로 제한되며, 릴레이 정책은 단일 pay-to-script-hash 입력에서 최대 15 단위를 허용합니다. 스크립트 주소가 공동 서명자 열다섯 명에서 상한에 이르는 이유는 옵코드 자체의 한도인 20이 아니라 이 정책상의 숫자입니다.

Tapscript는 이 옵코드를 완전히 폐기했습니다. BIP-342는 Taproot 리프 안에서는 이 옵코드와 그 검증 변형이 보이는 즉시 실패하게 했습니다. Schnorr 서명 묶음을 목록에 대해 한 번의 연산으로 확인하면 Schnorr를 쓸 가치를 만들어 주는 일괄 검증이 무력화되기 때문입니다.

사용되는 곳

모든 라이트닝 채널에 자금을 대는 2-of-2 출력은 OP_CHECKMULTISIG를 사용하며, 이것만으로도 이 옵코드는 네트워크 스크립트 지출의 큰 비중을 차지합니다. 기업 금고, 오래된 개인 간 거래(P2P) 장터의 에스크로 구성, Taproot 이전에 구축된 거래소 콜드 스토리지도 이를 사용하며, 보통 스크립트 해시 안의 2-of-3 형태입니다.

키가 해시 없이 출력에 직접 들어 있는 단순 호출은 키 세 개까지 릴레이 표준이지만 거의 쓰이지 않습니다. 발신자가 모든 키에 비용을 부담하고, 코인 하나가 움직이기 전에 전체 구성이 공개되기 때문입니다. 2014년에는 그 형식이 잠시 온체인에 파일을 저장하는 수단이 되었고, 데이터 저장 논쟁이 릴레이 정책을 건드릴 때마다 다시 떠오르는 이유의 일부입니다.

지금 공동 수탁을 구성한다면, 지갑은 개수 기반 대안을 쓰는 Taproot 구성이나, 수수료보다 호환성이 중요할 경우 P2WSH 스크립트를 만들 가능성이 더 큽니다.

OP_CHECKMULTISIG vs P2SH 멀티시그

OP_CHECKMULTISIG는 명령이고 P2SH 멀티시그는 그것을 포장하는 방식입니다. 옵코드는 정족수를 어떻게 확인하는지를 말하고, 포장은 정족수가 해시 뒤에 숨겨져 지출 시점에 드러난다는 것을 말합니다. 같은 명령이 키가 그대로 보이는 단순 출력에, 3으로 시작하는 주소 뒤의 리딤 스크립트에, 또는 bc1q 주소 뒤의 위트니스 스크립트에 나타날 수 있으며, 세 가지는 동일한 검증 로직을 실행하면서도 비용과 프라이버시에서 크게 다릅니다. 할 수 없는 것은 이 명령을 Taproot 리프에서 사용하는 것이며, 그래서 현대의 정족수는 전혀 다른 옵코드로 구성됩니다.