BIP342는 탭루트의 스크립트 경로 지출 가운데 리프 버전 0xc0인 탭스크립트의 규칙을 정합니다. 서명 opcode는 Schnorr 서명을 검증하고, OP_CHECKMULTISIG는 막히며 OP_CHECKSIGADD가 그 자리를 대신합니다. 이 글은 2026-10-27에 연 BIP342 원문(상태 Deployed)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
OP_CHECKSIGADD는 멀티시그를 어떻게 대신할까?
스택에서 공개키, 숫자 n, 서명을 꺼내 서명이 비어 있으면 n을, 유효하면 n+1을 쌓습니다. 원문의 변환 예는 CHECKMULTISIG 스크립트를 공개키 CHECKSIG 뒤에 CHECKSIGADD를 이어 붙이고 마지막에 m NUMEQUAL로 맺는 형태입니다. CHECKMULTISIG가 일괄 검증과 맞지 않아 이렇게 대체했다고 설명합니다. 스택 동작의 기초는 스크립트 스택 글에 있습니다.
| 항목 | BIP342 규칙 |
|---|---|
| 서명 검증 | OP_CHECKSIG·VERIFY는 BIP340 Schnorr |
| 비활성 opcode | OP_CHECKMULTISIG, OP_CHECKMULTISIGVERIFY(실행 시 즉시 실패) |
| 새 opcode | OP_CHECKSIGADD, 186(0xba) |
| MINIMALIF | 합의 규칙, OP_IF 인자는 빈 벡터 또는 1 |
| 크기·개수 제한 | 스크립트 10,000바이트와 비푸시 201개 제한은 적용 안 됨 |
| sigops 예산 | 50+입력 witness 직렬화 크기, 비어 있지 않은 서명마다 50 차감 |
공개키 길이에 따라 무엇이 달라질까?
공개키가 32바이트이면 BIP340 키이고 빈 서명이 아니면 검증하며, 실패하면 즉시 종료됩니다. 길이가 0이면 실패합니다. 그 밖의 길이는 알 수 없는 공개키 유형으로 보아 서명 검증을 성공으로 간주하며, 원문은 이를 나중 소프트포크로 새 서명 규칙을 넣을 여지로 설명합니다.
OP_SUCCESSx는 왜 위험하다고 적혀 있을까?
80, 98, 126~129 같은 번호의 opcode를 만나면 이후 규칙을 적용하지 않고 검증이 성공합니다. 원문은 의미가 소프트포크로 정해지기 전에 쓰면 안전하지 않고 자금 손실로 이어진다고 직접 경고합니다. 서명 대상이 리프에 묶이는 구조는 control block 글에서 이어집니다.
제한은 어떻게 바뀔까?
스크립트 크기와 비푸시 opcode 개수 제한이 없어지는 이유로, 원문은 서명 해시에 scriptCode가 직접 들어가지 않아 검사 시간이 스크립트 크기에 비례하지 않는다는 점을 듭니다. 대신 서명 검사마다 예산이 줄어듭니다. 스택 항목 520바이트와 스택 1,000개 제한은 남습니다.
자주 묻는 질문
서명 길이 64바이트와 65바이트는 어떻게 다른가요?
64바이트이면 기본 해시 유형으로, 65바이트이면 마지막 바이트를 해시 유형으로 읽습니다. 마지막 바이트가 0x00이면 실패합니다.
CHECKMULTISIG는 왜 OP_SUCCESS로 바꾸지 않았나요?
원문은 실수로 계속 쓰는 사람이 바로 문제를 알아채고 디스어셈블러가 문맥에 따라 달라지지 않게 하려는 조치라고 적습니다.
MINIMALIF가 합의 규칙이 된 이유는 무엇인가요?
스택에서 분기 정보를 받는 변조 불가 스크립트를 쓰기 훨씬 쉬워지기 때문이라고 원문이 설명합니다.
