P2TR 출력은 witness v1 program에 32바이트 x-only output key Q를 둡니다. Key path 지출은 Q에 대응하는 유효한 BIP340 Schnorr signature 하나를 witness에 넣어 사용하며, script path 지출은 실행할 tapscript와 control block, 조건을 만족할 stack 데이터를 공개합니다. Control block의 internal key와 Merkle path로 script leaf가 처음 output key에 커밋됐음을 재구성하므로, 사용하지 않은 다른 script branches는 공개하지 않습니다.
P2TR 출력은 하나의 32바이트 키로 보입니다
BIP341은 internal public key P와 선택적 script tree의 Merkle root m을 TapTweak으로 결합해 Q=P+tG를 만듭니다. chain의 scriptPubKey에는 OP_1과 x(Q)만 들어가므로 observer는 UTXO 생성 시 단일 서명 지출인지 복잡한 backup 조건이 있는지 바로 알 수 없습니다.
script tree가 없어도 internal key에 빈 Merkle root 조건의 tweak을 적용합니다. 단순히 internal key를 그대로 output program에 넣는 일반 설명은 정확하지 않습니다. Wallet은 descriptor와 tweak 계산을 백업해야 하며 internal private key만 있어도 잘못된 tree 정보를 쓰면 같은 output key를 복원하지 못합니다.
Taproot는 여러 지출 조건을 output key 하나에 약속하고, 실제 사용한 경로만 지출 시점에 드러냅니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- P2TR 출력은 하나의 32바이트 키로 보입니다
BIP341은 internal public key P와 선택적 script tree의 Merkle root m을 TapTweak으로 결합해 Q=P+tG를 만듭니다.
- Key path는 output key 서명만 공개합니다
Witness에서 annex를 제외하고 항목이 하나 남으면 BIP341 검증은 key path로 처리합니다.
- Script path는 leaf 약속을 증명합니다
Witness의 마지막 두 항목은 tapscript s와 control block c입니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Key path는 output key 서명만 공개합니다
Witness에서 annex를 제외하고 항목이 하나 남으면 BIP341 검증은 key path로 처리합니다. 그 항목은 Q에 대한 Schnorr signature이며 기본 SIGHASH_DEFAULT 또는 명시적 hash type을 포함할 수 있습니다. 여러 당사자가 MuSig2로 aggregate key를 만들었다면 협력 결과도 chain에서는 단일 BIP340 서명처럼 보일 수 있습니다.
key path는 script와 Merkle proof를 싣지 않아 일반적으로 더 작고 script policy를 숨깁니다. 그러나 협력 signer가 필요한 구조에서는 한 명이 offline이면 사용할 수 없습니다. 비상 복구나 time lock 조건은 별도 script leaf로 준비해 두어야 합니다.
| 항목 | Key path | Script path |
|---|---|---|
| 핵심 witness | Schnorr signature | stack·script·control block |
| 공개 조건 | output key만 | 사용한 leaf와 Merkle path |
| 일반 크기 | 더 작음 | leaf 깊이에 따라 증가 |
| 협력 요구 | aggregate 정책에 따름 | 선택 leaf 조건에 따름 |
| 검증 대상 | Q 서명 | Q 재구성 후 tapscript |
Script path는 leaf 약속을 증명합니다
Witness의 마지막 두 항목은 tapscript s와 control block c입니다. BIP341은 c 길이가 33+32m 바이트인지 확인하고 첫 바이트에서 leaf version과 output key y parity를, 다음 32바이트에서 internal key P를 읽습니다. 나머지 32바이트 묶음은 Merkle sibling path입니다.
Node는 TapLeaf hash에서 시작해 각 sibling과 lexicographic order로 TapBranch hash를 계산해 root를 얻습니다. P와 root로 tweak Q를 재구성하고 output program과 같은지 확인한 뒤 tapscript를 실행합니다. Merkle proof만 맞아도 script 조건을 만족하지 못하면 지출은 실패합니다.
- P2TR witness program의 32바이트 Q를 확인합니다.
- annex가 있으면 규칙에 따라 분리합니다.
- witness 항목 수로 key·script path를 구분합니다.
- control block 길이와 leaf version을 확인합니다.
- Merkle root와 Q를 재구성한 뒤 script를 실행합니다.
사용하지 않은 가지는 숨지만 구조 단서는 남습니다
Script path를 사용하면 선택한 tapscript와 control block의 Merkle siblings가 공개됩니다. sibling은 다른 script 내용 자체가 아니라 hash지만 path 깊이와 사용한 조건은 보입니다. 동일한 script template, 공개키 재사용, timing이 wallet policy를 연결할 수 있어 ‘완전한 프라이버시’라고 표현하지 않습니다.
Tree를 설계할 때 자주 쓰는 leaf를 얕게 두면 witness bytes를 줄일 수 있지만 policy 확률과 정보 공개를 함께 고려해야 합니다. key path가 항상 가능하도록 만들면 협력 key 관리 실패가 script backup과 연결됩니다. descriptor와 recovery drill로 두 경로를 모두 검증합니다.
도구는 block 시점 규칙과 sighash를 보여 줘야 합니다
Tapscript는 BIP342의 opcode·signature 규칙을 사용하고 legacy Script와 한도가 다릅니다. OP_CHECKMULTISIG 대신 OP_CHECKSIGADD로 multisig policy를 표현할 수 있습니다. Schnorr signature가 64바이트면 SIGHASH_DEFAULT, 65바이트면 마지막 byte가 hash type입니다.
분석 기록에는 output key, witness stack, annex 유무, script, control block, leaf version, Merkle depth와 sighash를 남깁니다. 탐색기가 script path라고 표시하는 것만 믿지 말고 BIP341 재구성 결과를 확인하면 잘못된 decoder와 malformed witness를 구분할 수 있습니다.
자주 묻는 질문
P2TR 출력만 보고 script 조건을 알 수 있나요?
아닙니다. 생성 시점에는 output key만 보이며 script path가 실제 사용될 때 선택 leaf와 proof가 공개됩니다.
Key path는 항상 한 사람이 서명하나요?
아닙니다. MuSig2 참여자들이 협력해 chain에서는 하나의 BIP340 서명으로 보이게 할 수 있습니다.
Control block이 맞으면 script는 실행하지 않나요?
아닙니다. output key 커밋을 재구성한 뒤 선택한 tapscript도 성공해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
