PSBT v2

안나와 얀은 청구서 하나를 함께 결제하려고 합니다. 각자 자금 일부를 내고 자신의 기기에서 서명을 추가합니다. 서로 교환해야 할 것은 합의한 거래안이지 개인키가 아닙니다. 개인키는 지갑이 자금 지출을 승인하는 디지털 서명을 만들 때 사용하는 비밀 숫자입니다. PSBT는 거래와 참고 자료가 담긴 작업용 봉투 역할을 합니다. 입력은 지출할 기존 금액을 가리키고, 출력은 새로운 금액과 이를 나중에 지출할 조건을 정합니다. 기존 PSBT v0는 이 뼈대를 고정된 전역 미서명 거래에 보관합니다. v2에서는 해당 규칙을 지키며 입력과 출력을 순차적으로 추가할 수 있습니다. 장점은 공동 구성이지, 다른 사람이 이미 서명한 내용을 마음대로 고칠 수 있다는 것이 아닙니다. [1] [2]

안나가 모든 기술 필드를 직접 읽을 필요는 없습니다. 하지만 신뢰할 수 있는 서명 기기에서 실제 수취인, 금액, 수수료, 자신의 지갑으로 돌아오는 잔돈을 확인해야 합니다. 특히 마지막 항목은 놓치기 쉽습니다. 남의 출력을 자신의 잔돈으로 잘못 알아서는 안 됩니다. 기기는 아직 지출되지 않은 출력인 UTXO의 자료를 검증하고 그 조건이 서명 대상과 맞는지 확인해야 합니다. 키 파생 경로는 지갑이 마스터키에서 특정 키를 얻는 단계를 나타냅니다. 파일에 그 경로가 적혀 있다는 사실만으로 소유권이 입증되지는 않습니다. 서명 기기는 서명이 거래의 어느 부분을 보호하는지 정하는 SIGHASH도 올바르게 해석해야 합니다. 서명을 위해 교환하는 파일에 개인키나 지갑 백업 단어인 Seed Phrase를 추가할 필요는 없습니다. [2] [4]

기기나 앱이 PSBT를 지원한다고 해서 v2도 지원하는 것은 아닙니다. 사용하는 프로그램과 기기 사이에서 생성, 가져오기, 서명, 결과 반환까지 전체 흐름을 확인해야 합니다. PSBT v0와 v2는 그대로 서로 바꿔 쓸 수 없습니다. v0로 변환하려면 미서명 거래를 만들고 해당 버전의 규칙에 맞게 필드를 조정해야 합니다. 숫자만 바꿔서는 충분하지 않습니다. Bitcoin 출력의 지출 조건을 정하는 더 새로운 방식인 Taproot도 v2와 같은 것이 아닙니다. BIP 371은 두 PSBT 버전 모두에 사용할 관련 서명 자료를 정의합니다. 소액으로 전체 과정을 시험하면 해당 구성의 호환성을 확인할 수 있지만, 이후 모든 결제가 올바르다는 보장은 아닙니다. [1] [3]

파일 형식의 버전과 Bitcoin 거래의 버전은 의미가 다릅니다. v2에서는 PSBT_GLOBAL_VERSION에 2가 들어가야 하며, 기존 PSBT_GLOBAL_UNSIGNED_TX 필드는 없어야 합니다. 별도의 필수 필드인 PSBT_GLOBAL_TX_VERSION은 거래 자체의 버전을 정합니다. 입력 수와 출력 수도 필수입니다. 이렇게 나누면 정보가 각 항목 곁에 놓여 프로그램이 공통 거래 뼈대까지 찾아볼 필요가 없습니다. 생성자가 다른 참여자에게 이후 구성을 맡길 경우, BIP 370은 적절한 변경 플래그와 최소 2의 거래 버전을 요구합니다. 어디까지나 작업 형식이며 새로운 네트워크 합의 규칙이 아닙니다. [1]

각 입력에는 이전 거래의 식별자인 TXID와 그중 지출할 특정 출력의 인덱스가 필요합니다. 거래 하나에 출력이 여러 개일 수 있으므로 TXID만으로는 부족합니다. 새 출력에는 Bitcoin의 최소 단위인 satoshi로 표시한 금액과 지출 조건을 정하는 스크립트인 scriptPubKey가 들어갑니다. 항목을 추가하면 해당 전역 개수도 바꿔야 합니다. 선택 필드 sequence에는 또 다른 입력 제어값이 들어가며, 생략하면 0xffffffff를 사용합니다. 이 구성 자료는 거래를 조립하는 방법을 설명합니다. 그러나 서명과 수수료를 안전하게 판단하는 데 필요한 UTXO의 금액 및 지출 조건 자료를 대신하지는 않습니다. [1]

얀이 입력 하나를 더 추가해야 한다고 가정해 봅시다. 프로그램은 파일을 가지고 있다는 이유만으로 추가가 허용된다고 생각해서는 안 됩니다. PSBT_GLOBAL_TX_MODIFIABLE의 비트 0은 입력 변경 가능 여부를, 비트 1은 출력 변경 가능 여부를 나타냅니다. 비트 2는 입력을 대응하는 위치의 출력과 짝짓는 SIGHASH_SINGLE 서명이 있음을 알립니다. 다른 항목을 삽입해도 이 짝은 유지해야 합니다. 따라서 구성자는 실제 서명과 제약을 확인합니다. 플래그는 협력하는 프로그램에 정보를 전달할 뿐, 암호학적 서명을 우회하거나 유효하지 않은 변경을 유효하게 만들지 못합니다. [1]

일부 입력은 특정 블록 높이나 시간 경계 이후에만 거래를 사용할 수 있도록 요구합니다. 블록은 네트워크의 공동 기록에 추가된 거래 묶음이며, 블록 높이는 체인에서 그 블록의 순서를 나타냅니다. 공통 nLockTime 필드는 모든 입력과 양립하는 유형의 요구를 따라야 합니다. 선택한 유형에서 가장 큰 요구값을 사용하며, 두 유형 모두 가능하면 블록 높이를 우선합니다. 따라서 높이와 시간을 일반적인 두 숫자처럼 단순 비교할 수 없습니다. 어느 입력에도 요구가 없으면 전역 대체값을 사용하고, 그것도 없으면 0을 사용합니다. 양립할 수 없는 요구가 있는 입력은 추가할 수 없습니다. 이미 서명이 있다면 새 입력이 계산된 nLockTime을 바꿔서도 안 됩니다. 이 필드들만으로 모든 타임록 규칙을 충족한다고 보장할 수는 없습니다. [1]

서명이 추가될수록 이후 변경 범위가 줄어듭니다. BIP 370은 SIGHASH_ANYONECANPAY를 사용하지 않는 서명에서 입력 변경을, SIGHASH_NONE을 사용하지 않는 서명에서 출력 변경을 비활성화하도록 요구합니다. SIGHASH_SINGLE에서는 유지해야 할 짝을 기록합니다. 이 이름들은 서명이 보호하는 범위를 나타내며, 초보자가 임의로 바꿔 볼 설정이 아닙니다. 모든 입력이 준비되면 최종화 단계에서 필요한 서명 자료를 조립하고, 추출기가 필드들을 바탕으로 네트워크 형식의 거래를 만듭니다. 이를 전송해야 노드가 거래를 평가하고 채굴자가 블록에 포함할 수 있습니다. 안나와 얀은 거래안, 서명된 결과, 확인된 결제를 구분해야 합니다. PSBT를 건네는 것만으로 서명이나 확인이 이뤄지는 것은 아닙니다. [1] [2] [4]