Miniscript는 코인을 쓰는 조건을 정하는 언어인 Bitcoin Script의 일부를 구조적으로 표현합니다. 서명, 대기 시간, 특정 비밀의 공개를 소프트웨어가 분석하고 충족할 수 있는 형태로 조합합니다. 별도의 지갑도, 새로운 비트코인 규칙도 아닙니다. 코인을 실제로 보호하는 것은 최종 스크립트입니다.
안나는 평소 자신의 키로 코인을 쓰고 싶습니다. 디지털 서명은 비밀 숫자 값인 개인 키로 결제 승인을 증명하며, 키 자체는 공개하지 않습니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 안나는 동시에 특정 출력이 확인된 뒤 144블록이 지나면 피터도 자신의 키로 쓸 수 있는 경로를 마련하려 합니다. 이런 의도를 spending policy, 즉 지출 정책이라고 합니다. Miniscript는 이를 지갑이 다룰 수 있는 정확한 표현으로 바꾸도록 돕습니다. 피터에게는 여전히 키가 필요하며, 기다림이 키를 대신하지 않습니다. 이는 대체 접근 경로의 간단한 예일 뿐, 자동 송금이나 안나의 키 분실을 감지하는 장치가 아닙니다. [1] [2] [10]
말로 설명한 규칙은 아직 네트워크가 검증할 프로그램이 아닙니다. 컴파일러는 구체적인 Miniscript를 선택해 Bitcoin Script로 변환할 수 있습니다. Output Descriptor는 그 스크립트와 키, 필요한 파생 경로를 설명하며, 복사 오류를 찾는 체크섬도 포함할 수 있습니다. 지출할 때 네트워크가 확인하는 것은 실제 스크립트와 제출된 데이터이지, 처음의 문장이 아닙니다. Miniscript는 명령을 추가하거나 공동의 유효성 규칙인 합의를 바꾸지 않습니다. 모든 Bitcoin Script를 표현할 수 있는 것도 아닙니다. [1] [3] [6]
블록은 공동 기록에 추가하는 거래 묶음입니다. 피터의 예에서 144블록은 해당 출력이 확인된 시점부터 셉니다. 출력은 지출 조건이 붙은 구체적인 금액입니다. 정확히 하루라는 뜻도, 지갑을 만든 뒤 지난 시간도 아닙니다. Miniscript는 상대 대기를 older(n)으로 표현하며 CSV와 해당 출력을 쓰는 거래 입력의 nSequence 필드를 사용합니다. 경과 기간 검증에서 nSequence의 의미는 BIP 68이 정합니다. 반면 after(n)은 CLTV와 절대적인 nLockTime을 사용해 고정된 블록 높이나 시간 경계를 지정합니다. 지갑은 거래 필드를 올바르게 설정하고 다른 조건도 충족해야 합니다. 높이 기반 잠금과 시간 기반 잠금을 서로 맞지 않게 결합해서는 안 되며, 기다림만으로는 아무것도 전송되지 않습니다. [1] [7] [8] [9] [11]
규칙 설명을 보여 주는 것만으로는 부족합니다. 지갑은 허용된 경로를 충족하는 데이터를 제공해야 합니다. 예를 들어 서명이나, 요구된 해시와 일치하는 비밀인 preimage가 필요합니다. 해시는 데이터의 디지털 지문입니다. 여기서는 제출한 비밀로 요구된 지문을 만들 수 있는지 검사합니다. 이런 충족을 satisfaction이라고 하며 필요한 입력 데이터는 거래 witness의 일부를 이룹니다. 분기를 조합할 때는 다른 경로를 쓰기 위해 특정 하위 조건을 정해진 방식으로 거짓으로 만들어야 할 수도 있습니다. 이를 dissatisfaction이라고 하며, 결제 전체가 무효라는 뜻은 아닙니다. 소프트웨어는 경로를 구성할 수 있지만 없는 개인 키나 모르는 비밀을 만들어 낼 수는 없습니다. [1] [12]
PSBT는 준비한 거래와 보충 정보를 지갑과 서명 장치 사이에서 전달하는 형식입니다. PSBT 지원만으로는 충분하지 않습니다. 프로그램과 Hardware Wallet이 해당 descriptor와 조건을 이해해야 합니다. Bitcoin Core는 버전 24에서 P2WSH 내 Miniscript의 관찰 전용 기능을, 버전 25에서 서명을, 버전 26에서 Taproot descriptors에서의 사용을 추가했습니다. 코인을 관찰할 수 있다고 쓸 수 있는 것은 아닙니다. 설정할 때는 장치가 실제로 제공하는 기능에 따라 신뢰할 수 있는 화면에서 키, 필요한 서명, 대기 시간, 모든 대체 경로를 확인하세요. [3] [4] [5]
Seed Phrase는 키를 복원하지만, 복잡한 사용자 정의 조건에서 그 키가 다른 키와 스크립트에 어떻게 결합되었는지까지 알려 주지 않을 수 있습니다. 이 백업은 순서가 있는 단어들로 기록되며, 지갑은 이를 바탕으로 키를 파생할 수 있습니다. 체크섬을 포함한 정확한 descriptor, 키 대응표, 파생 경로, 수신 주소와 거스름돈 주소의 구분을 보관하세요. 네트워크, 주소 범위, 과거 기록 검색의 시작점은 별도로 기록합니다. 공개 descriptor는 개인 키가 아니지만 결제 이력을 드러낼 수 있습니다. 실제 사용 전에 Regtest 또는 Signet 테스트 환경에서 관찰 전용 지갑 복원과 예정된 모든 지출 경로를 시험하세요. [5] [6]
pk(), older(), after(), sha256()은 서명, 대기 또는 비밀 제출 요구를 나타냅니다. and_v(), or_d(), thresh()는 조건을 결합합니다. v: 같은 래퍼는 하위 표현식의 의미를 유지하면서 평가 방식을 조정합니다. B, V, K, W 타입은 구성 요소가 스택에서 데이터를 넘기는 방법을 제한합니다. 스택은 스크립트의 작업 공간이며 아무 요소나 서로 연결할 수 있는 것은 아닙니다. 타입 검사는 맞지 않는 조합을 발견할 수 있지만, 안나가 누구를 믿어야 하는지 또는 합리적인 예비 경로를 골랐는지는 판단하지 않습니다. [1] [2]
구조 덕분에 지출 전에 스크립트와 witness의 크기, 연산 수, 서명 검사 수, 스택 항목 수를 분석할 수 있습니다. 이는 경로별 비용을 예상하고 허용 한도 초과를 발견하는 데 도움이 됩니다. 다만 환경을 구분해야 합니다. P2WSH는 SegWit 안에서 조건을 다루고, Tapscript는 Taproot에서 사용되는 스크립트를 가리킵니다. 두 환경의 한도는 완전히 같지 않습니다. 합의 규칙뿐 아니라 일반적인 거래 중계 규칙도 적용됩니다. 따라서 분석 결과가 모든 지갑이 해당 절차를 수행할 수 있다는 보증은 아닙니다. [1]
공개 키는 서명을 검증하는 데 사용하며 비밀로 유지할 필요가 없습니다. malleability 분석은 외부인이 유효한 satisfaction 하나를 다른 유효한 satisfaction으로 바꿀 수 있는지 살핍니다. 보장에는 구체적인 가정이 있습니다. 공격자는 참여자의 개인 키를 갖고 있지 않고, 정직한 사용자보다 더 많은 preimages를 알지 못하며, satisfaction 하나만 본다고 가정합니다. 공개 키가 반복되지 않고 일반적인 수락 규칙을 따른다는 조건도 있습니다. 채굴자는 일반 중계 노드에 없는 선택지를 가질 수 있습니다. 따라서 모든 악의적인 참여자, 백업 분실, 잘못된 보관 설계에 대한 보호는 아닙니다. 이런 문제는 별도로 검토해야 합니다. [1]
컴파일러는 같은 규칙을 서로 다른 스크립트와 witness 크기로 표현하고 비용 모델에 따라 선택할 수 있습니다. 정책 입력 언어의 분기에 붙는 9@ 같은 표시는 상대적인 사용 확률을 알려 주는 힌트이지 서명 개수나 네트워크 권한이 아닙니다. 다른 컴파일 결과는 다른 스크립트, 나아가 다른 주소를 만들 수 있습니다. 따라서 복원할 때 규칙을 다시 말로 설명하고 컴파일하는 것만으로는 충분하지 않습니다. 정확하게 저장한 표현, 파생 주소 확인, 검증된 서명 경로가 중요합니다. [2] [5]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin Script, Output Descriptor, Multisig, Andrew Poelstra, Timelock, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Output Descriptor, Dead Man’s Switch, Andrew Poelstra, Simplicity.