📖 원문: BIP-0141
BIP: 141 레이어: 합의 (소프트포크) 제목: 분리된 증인 (합의 레이어) 작성자: 에릭 롬브로조(Eric Lombrozo, [email protected]) 존슨 라우(Johnson Lau, [email protected]) 피터 우일(Pieter Wuille, [email protected]) 의견 요약: 의견 없음 의견 주소: https://github.com/bitcoin/bips/wiki/Comments:BIP-0141 상태: 완결됨 유형: 표준 트랙 생성일: 2015년 12월 21일 라이선스: PD
이 BIP는 트랜잭션 머클 트리와는 별도로 기록되는 “증인(witness)”이라는 새로운 구조를 정의한다. 이 구조에는 트랜잭션 유효성을 확인하는 데는 필요하지만 트랜잭션 효과를 결정하는 데는 필요하지 않은 데이터가 포함되어 있다. 특히 스크립트와 서명이 이 새로운 구조로 이동된다.
증인은 코인베이스 트랜잭션을 통해 블록의 기존 머클 루트에 내장된 트리에 기록되며, 이는 BIP 소프트포크와 호환되도록 하기 위한 것이다. 향후 하드포크는 이 트리를 자체 분기에 배치할 수 있다.
트랜잭션의 전체 효과는 출력 소비(지출)와 새로운 출력 생성에 의해 결정된다. 다른 트랜잭션 데이터, 특히 서명은 블록체인 상태를 검증하는 데만 필요하며, 블록체인의 상태를 결정하는 데는 필요하지 않다.
트랜잭션 머클 트리에 기록된 트랜잭션 구조에서 이러한 데이터를 제거하면 몇 가지 문제가 해결된다.
- 의도하지 않은 위변조가 불가능해진다. 서명 데이터가 더 이상 트랜잭션 해시의 일부가 아니므로 트랜잭션 서명 방식에 대한 변경은 트랜잭션 식별과 관련이 없다. 이는 트랜잭션 가변성에 대한 해결책으로서, 표준 서명 접근 방식(BIP-62)보다 우수하다.
- 모든 입력이 서명되어 있는 한(하나 이상의 CHECKSIG 또는 CHECKMULTISIG 연산으로) 모든 유형의 스크립트에 대해 비자발적인 트랜잭션 가변성을 방지한다.
- m-of-n CHECKMULTISIG 스크립트의 경우, 트랜잭션은 m명의 개인키 보유자의 동의가 있어야만 변경이 가능하다. (BIP-62를 사용하는 개인키 보유자가 1명뿐인 것과는 대조적임)
- 알려지지 않은 ECDSA 서명 가변성으로 인한 비자발적인 거래 가변성을 방지한다.
- 라이트닝 네트워크와 같은 오프체인 프로토콜의 중요한 기능인 거래 상대방 위험(계약 의무 불이행 가능성의 위험) 없이 승인되지 않은 거래 의존성 체인을 생성할 수 있다.
- 서명 데이터 전송은 선택 사항이 된다. 피어가 트랜잭션의 존재를 확인하는 것이 아니라 트랜잭션의 유효성을 확인하려는 경우에만 필요하다. 이렇게 하면 SPV 증명의 크기가 줄어들고, 동일한 대역폭을 사용하여 더 많은 트랜잭션을 다운로드 할 수 있으므로 잠재적으로 SPV 클라이언트의 개인정보 보호가 향상될 수 있다.
- 트랜잭션 데이터의 일부를 현재 프로토콜에 알려지지 않은 구조로 이동하여 소프트포크를 통해 일부 제약을 우회할 수 있다. 예를 들면:
- 블록 크기를 계산할 때 증인의 크기는 무시/절감하여 블록 크기를 어느 정도 효과적으로 늘릴 수 있다.
- 최대 데이터 푸시 크기(520바이트) 또는 sigops 제한과 같은 하드코딩된 상수를 재평가하거나 제거할 수 있다.
- 기존 스크립트의 의미 제약 없이 새로운 스크립트 체계를 도입할 수 있다. 예를 들어, 트랜잭션 서명 검증을 위한 새로운 트랜잭션 다이제스트 알고리즘은 BIP-143에 설명되어 있다.
새로운 데이터 구조인 witness가 정의된다. 각 트랜잭션은 2개의 ID를 가진다.
txid의 정의는 변경되지 않고 기존 직렬화 형식의 이중 SHA256 값으로 유지된다.
[nVersion][txins][txouts][nLockTime]
새로운 wtxid가 정의된다: 증인 데이터를 더한 새로운 직렬화의 이중 SHA256이다.
[nVersion][marker][flag][txins][txouts][witness][nLockTime]
nVersion, txins, txouts, nLockTime의 형식은 기존 직렬화 방식과 동일하다.
marker는 반드시 1바이트 0 값인 0x00이어야 한다.
flag는 1바이트의 0이 아닌 값이어야 한다. 지금은 0x01을 사용해야 한다.
witness는 트랜잭션의 모든 증인 필드에 대한 직렬화 값이다. 각 txin은 하나의 증인 필드와 연결된다. 증인 필드는 txin의 스택 항목 수를 나타내는 var_int로 시작한다. 그 다음에는 스택 항목이 이어지며, 각 항목은 길이를 나타내는 var_int로 시작한다. 증인 데이터는 스크립트가 아니다.
증인이 없는 프로그램(이하 정의됨)의 txin은 0x00으로 표현되는 빈 증인 필드와 연결되어야 한다. 모든 txin이 증인 프로그램이 아닌 경우 트랜잭션의 wtxid는 해당 txid와 동일하다.
새로운 블록 규칙이 추가되어 wtxid에 대한 서약이 필요하다. 코인베이스 트랜잭션의 wtxid는 0x0000….0000으로 가정한다.
witness root hash는 블록 헤더의 hashMerkleRoot와 유사한 방식으로 모든 wtxid를 리프(leaf)로 사용하여 계산된다.
약정은 코인베이스 트랜잭션의 scriptPubKey에 기록된다. 이는 38바이트 이상이어야 하며, 첫 6바이트는 0x6a24aa21a9ed여야 한다.
1바이트 - OP_RETURN (0x6a)
1바이트 - 다음 36바이트 (0x24) 푸시
4바이트 - 약정 헤더 (0xaa21a9ed)
32바이트 - 약정 해시: Double-SHA256(증인 루트 해시|증인 예약값) (witness root hash|witness reserved value)
39바이트 이후: 합의 의미가 없는 선택적 데이터
그리고 코인베이스 입력의 증인은 witness reserved value에 대한 단일 32바이트 배열로 구성되어야 한다.
패턴과 일치하는 scriptPubKey가 두 개 이상 있는 경우, 출력 인덱스가 가장 높은 것이 약정으로 간주된다.
블록의 모든 트랜잭션에 증인 데이터가 없는 경우, 약정은 선택 사항이다.
1바이트 푸시(push) 연산자 코드(0-16)와 2-40바이트 사이의 데이터 푸시로 구성된 scriptPubKey(또는 BIP-16/P2SH에 정의된 redeemScript)는 새롭고 특별한 의미를 가진다. 첫 번째 푸시의 값은 “버전 바이트(version byte)”라고 한다. 다음으로 푸시된 바이트 벡터는 “증인 프로그램”이라고 한다.
다음 두 가지 경우 증인 유효성 검사 로직이 작동한다. 각 경우에 따라 증인 버전 바이트와 프로그램의 위치, 그리고 scriptSig의 형태가 결정된다.
- 정확히 버전 바이트를 푸시하고, 증인 프로그램을 푸시하는
scriptPubKey에 의해 트리거 된다. scriptSig는 확실히 비어 있어야 하며 그렇지 않으면 유효성 검사에 실패한다. (”네이티브 증인 프로그램”) scriptPubKey가 P2SH 스크립트이고,scriptSig에 푸시된 BIP-16redeemScript가 정확히 버전 바이트의 푸시와 증인 프로그램의 푸시일 때 트리거 된다.scriptSig는 정확히 BIP-16redeemScript의 푸시여야 하며 그렇지 않으면 유효성 검사에 실패한다. (”P2SH 증인 프로그램”)
버전 바이트가 0이고 증인 프로그램이 20바이트인 경우:
- P2WPKH(Pay-to-witness-public-key-hash) 프로그램으로 해석된다.
- 증인은 정확히 2개의 항목(각각 520바이트 이하)으로 구성되어야 한다. 첫 번째는 서명이고, 두 번째는 공개키이다.
- 공개키의 HASH160 값은 20바이트 증인 프로그램과 일치해야 한다.
- 일반 스크립트 평가 이후, 서명은 CHECKSIG 작업을 통해 공개키에 대해 검증된다. 검증 결과 스택에는 TRUE가 하나 있어야 한다.
버전 바이트가 0이고 증인 프로그램이 32바이트인 경우:
- P2WSH(Pay-to-witness-script-hash) 프로그램으로 해석된다.
- 증인은 스크립트에 공급할 입력 스택과 그 뒤에 직렬화된 스크립트(
witnessScript)로 구성되어야 한다. witnessScript(≤ 10,000바이트)는 초기 증인 스택에서 팝 아웃(pop off) 된다.witnessScript의 SHA256 값은 32바이트 증인 프로그램과 일치해야 한다.witnessScript는 역직렬화 되고, 나머지 증인 스택(각 스택 항목당 520바이트 이하)으로 일반 스크립트 평가 후 실행된다.- 스크립트는 실패해서는 안 되며, 스택에서 정확히 하나의 TRUE를 생성해야 한다.
버전 바이트가 0이지만 증인 프로그램이 20바이트도 아니고 32바이트도 아닌 경우, 스크립트는 실패해야 한다. [1]
버전 바이트가 1~16이면 증인 프로그램 또는 증인 스택에 대한 크기 제한이 없다. 이러한 버전은 향후 확장을 위해 예약되어 있다. [2]
블록은 현재 총 크기가 1,000,000바이트(1MB)로 제한되어 있다. 이 제한을 다음과 같이 변경한다.
블록 가중치(Block weight)는 기본 크기(base size) * 3 + 총 크기(total size)로 정의된다. (근거 [3])
기본 크기는 업그레이드 되지 않은 노드에서 볼 때 증인 관련 데이터가 없는 원래 트랜잭션 직렬화의 블록 크기(바이트)이다.
총 크기는 기본 데이터와 증인 데이터를 포함하여 BIP-144에 설명된 대로 직렬화된 트랜잭션이 포함된 바이트 단위의 블록 크기이다.
새로운 규칙은 블록 가중치 ≤ 4,000,000이다.
블록당 sigops는 현재 20,000으로 제한되어 있다. 이 제한을 다음과 같이 변경한다.
현재 공개키 스크립트, 서명 스크립트, P2WSH 확인 스크립트의 sigops는 이전 값의 4배로 계산된다. Sigop 제한도 마찬가지로 4배 증가하여 최대 80,000까지 허용한다.
각 P2WPKH 입력은 1 sigop으로 계산된다. 또한, P2WSH witnessScript 내의 연산 코드(opcode)는 P2SH redeemScript 내에서 이전과 동일하게 계산된다. 즉, CHECKSIG는 1 sigop으로만 계산된다. OP_1부터 OP_16 사이의 값이 앞에 오면 CHECKMULTISIG는 각각 1~16 sigops로 계산되며, 그게 아니라면 20 sigops로 계산된다 이 규칙은 네이티브 증인 프로그램과 P2SH 증인 프로그램 모두에 적용된다.
💡 Sigops
Sigops는 Signature Operations의 줄임말로, 트랜잭션 입력과 출력에 포함된 서명 연산 수를 계산하는데 사용되는 작업량 측정 단위이다. 비트코인 네트워크는 안정성을 위해 블록에 포함될 수 있는 sigops의 수를 제한하고 있다.
다음의 정의는 합의 제한에 사용되지는 않지만 위에서 소개한 용어와 일관된 언어를 제공하기 위해 제안되었다.
트랜잭션 가중치(Transaction weight)는 기본 트랜잭션 크기(base transaction size) * 3 + 총 트랜잭션 크기(total transaction size)로 정의된다. (즉, 기본 크기와 총 크기에서 블록 가중치를 계산하는 것과 동일한 방법)
가상 트랜잭션 크기(Virtual transaction size)는 트랜잭션 가중치 / 4 (다음 정수로 반올림)로 정의된다.
기본 트랜잭션 크기는 증인 데이터가 제거된 상태로 직렬화된 트랜잭션의 크기이다.
총 트랜잭션 크기는 기본 데이터와 증인 데이터를 포함하여 BIP-144에 설명된 대로 직렬화된 바이트 단위의 트랜잭션 크기이다.
P2WPKH 및 P2WSH의 스크립트 언어는 세그윗 이전의 스크립트와 매우 유사해 보이지만, 몇 가지 주목할 만한 차이점이 있다. 사용자는 세그윗 이전의 시스템에서 사용할 수 있는 P2WPKH 또는 P2WSH 스크립트로도 사용할 수 있을 것이라고 가정해서는 안 된다. 개발자는 프로덕션 네트워크에 대규모로 배포하기 전에 기본 릴레이 정책을 켠 상태에서 테스트넷을 통해 스크립트를 테스트 하고, 메인넷에서 BIP-141이 활성화 된 후 적은 금액으로 스크립트를 테스트 해야 한다.
합의 수준에서의 주요한 차이점은 버전 0의 증인 프로그램에서 서명 검증을 위한 새로운 트랜잭션 다이제스트 알고리즘으로써 BIP-143에 설명되어 있다.
세 가지 릴레이 및 마이닝 정책도 참조 구현 버전 0.13.1에서 세그윗의 첫 번째 릴리즈에 포함되어 있다. 이러한 정책에 기반한 소프트포크는 가까운 시일 내에 제안될 예정이다. 잠재적인 소프트포크에서 트랜잭션 승인의 무기한 지연 및 영구적인 자금 손실을 피하려면 사용자는 새로운 의미를 주의 깊게 살펴보아야 한다.
- P2WPKH와 P2WSH에서는 압축된 공개키만 허용된다. (BIP-143 참고)
- P2WSH에서 OP_IF/NOTIF 인수는 최소여야 한다. [4]
- 서명은 (세그윗 이전의 스크립트 및 P2WSH 모두에 대해) OP_CHECKSIG 또는 OP_CHECKMULTISIG가 실패한 경우 null 벡터여야 한다. (BIP-146 참고)
다음 예시는 버전 0의 P2WPKH(Pay-to-witness-public-key-hash)이다.
증인 (witness): <signature> <pubkey>
스크립트 서명 (scriptSig): (empty)
스크립트 공개키 (scriptPubKey): 0 <20-byte-key-hash>
(0x0014{20-byte-key-hash})
scriptPubKey의 ‘0’은 다음 푸시(push)가 버전 0인 증인 프로그램임을 나타낸다. 증인 프로그램의 길이는 P2WPKH 유형임을 나타내며, 증인은 정확히 2개의 항목으로 구성되어야 한다. 증인에서 공개키의 HASH160 값은 증인 프로그램과 일치해야 한다.
서명은 다음과 같이 검증된다.
<signature> <pubkey> CHECKSIG
기존 P2PKH 출력과 비교했을 때, P2WPKH에 해당하는 것은 scriptPubKey에서 3바이트를 덜 차지하며, 서명과 공개키를 scriptSig에서 증인으로 옮긴다.
다음 예시는 동일한 P2WPKH이지만 BIP-16 P2SH 출력에 내장된 형태의 예시이다.
증인 (witness): <signature> <pubkey>
스크립트 서명 (scriptSig): <0 <20-byte-key-hash>>
(0x160014{20-byte-key-hash})
스크립트 공개키 (scriptPubKey): HASH160 <20-byte-script-hash> EQUAL
(0xA914{20-byte-script-hash}87)
ScriptSig의 유일한 항목은 HASH160으로 해시되고, scriptPubKey의 20-byte-script-hash와 비교되어 다음과 같이 해석된다.
0 <20-byte-key-hash>
그런 다음 이전 예제에서 설명한 대로 공개키와 서명을 확인한다.
이전 예시와 비교하면 scriptPubKey는 1바이트 더 크고, scriptSig는 23바이트 더 크다. 내장된 형태의 증인 프로그램은 효율성이 떨어지지만 결제 주소가 완전히 투명하고, 버전 0.6.0 이후 모든 비트코인 참조 클라이언트에서 이전 버전과 호환된다.
다음 예시는 1-of-2 다중 서명 방식의 버전 0 P2WSH(pay-to-witness-script-hash)이다.
증인 (witness): 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
스크립트 서명 (scriptSig): (empty)
스크립트 공개키 (scriptPubKey): 0 <32-byte-hash>
(0x0020{32-byte-hash})
scriptPubKey의 ‘0’은 다음 푸시(push)가 버전 0인 증인 프로그램임을 나타낸다. 증인 프로그램의 길이는 P2WSH 유형임을 나타낸다. 증인의 마지막 항목(”witnessScript”)을 스택에서 제거하고 SHA256으로 해시한 다음 scriptPubKey의 32-byte-hash와 비교해서 역직렬화 한다.
1 <pubkey1> <pubkey2> 2 CHECKMULTISIG
스크립트는 증인의 나머지 데이터로 실행된다.
0 <signature1> 1 <pubkey1> <pubkey2> 2 CHECKMULTISIG
P2WSH는 520바이트 푸시 제한을 우회하므로 최대 10,000바이트의 스크립트 크기를 허용한다.
scriptPubKey는 BIP-16 P2SH의 23바이트와 달리 34바이트를 차지한다. 크기가 증가하면 280개의 작업이 더이상 불가능하지 않으므로 충돌 공격에 대한 보안이 향상된다. (2015년 말까지 비트코인 생성 이후 비트코인 채굴에서 계산된 해시는 284개이다.) 지출 스크립트는 동등한 BIP-16 P2SH 출력에 대한 스크립트와 동일하지만 증인으로 이동되었다.
다음 예시는 동일한 1-of-2 다중 서명 방식의 P2WSH 스크립트이지만 BIP-16 P2SH 출력에 내장된 형태의 예시이다.
증인 (witness): 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
스크립트 서명 (scriptSig): <0 <32-byte-hash>>
(0x220020{32-byte-hash})
스크립트 공개키 (scriptPubKey): HASH160 <20-byte-hash> EQUAL
(0xA914{20-byte-hash}87)
scriptSig의 유일한 항목은 HASH160으로 해시되고, scriptPubKey의 20-byte-hash와 비교되어 다음과 같이 해석된다.
0 <32-byte-hash>
그런 다음 예제에서 설명한 것과 같이 P2WSH witnessScript가 실행된다.
이전 예제와 비교해보면 scriptPubKey는 11바이트 더 작지만(보안이 약해짐) 증인은 동일하다. 그러나 scriptSig에는 35바이트가 필요하다.
코인베이스 트랜잭션의 새로운 약정은 witness root hash와 witness reserved value의 해시이다. witness reserved value는 현재 합의 의미가 없지만 향후 소프트포크에 대한 새로운 약정 값을 허용한다. 예를 들어, 향후 합의에 중요한 약정이 필요한 경우, 이는 코인베이스의 약정이 된다.
Double-SHA256(witness root hash|Hash(new commitment|witness reserved value))
이전 버전과의 호환성을 위해 Hash(new commitment|witness reserved value) 값은 코인베이스 증인으로 이동하고, witness reserved value는 향후 소프트포크에서 지정한 다른 위치에 기록된다. 이러한 방식으로 얼마든지 새로운 약정을 추가할 수 있다.
병합 채굴과 같이 비트코인 합의에 중요하지 않은 약정은 비트코인 합의 프로토콜의 업그레이드 기능을 보존하기 위해 witness reserved value를 사용해서는 안 된다.
또한, 약정에 따른 선택적 데이터 공간은 향후 소프트포크의 메타데이터를 위한 공간으로 두며, 다른 목적으로 사용해서는 안 된다.
세그윗은 트랜잭션 가변성 문제를 근본적으로 해결하여 신뢰가 필요 없는 방식으로 미승인 트랜잭션 의존성 체인을 구축할 수 있게 한다.
앨리스와 밥이라는 두 당사자는 2-of-2 다중서명 출력(”펀딩 트랜잭션”)에 일정량의 비트코인을 전송하는데 동의할 수 있다. 펀딩 트랜잭션에 서명하지 않고 미래에 시간 제한이 있는 다른 트랜잭션을 생성하여 2-of-2 다중 서명 결과물을 제3의 계정으로 지출할 수 있다 (이하 “지출 트랜잭션”). 앨리스와 밥은 지출 트랜잭션에 서명하고 서명을 교환한다. 서명을 검토한 후, 두 사람은 서명하고 펀딩 트랜잭션을 블록체인에 기록한다. 추가적인 조치가 없다면 잠금 시간이 지나면 지출 트랜잭션이 확정되고 원래의 계약에 따라 자금이 전달된다. 또한, 잠금 시간 전에 더 짧은 잠금 시간을 가진 다른 지출 트랜잭션으로 원래 계약을 취소할 수 있는 유연성을 유지하기는 하지만 이는 두 당사자의 상호 동의가 있는 경우에만 가능하다.
두 당사자가 먼저 펀딩 트랜잭션에 서명하지 않으면 지출 트랜잭션을 생성할 수 없으므로 가변성 수정 사항에 대한 내용을 다루는 BIP-62에서는 이러한 설정이 불가능하다. 앨리스가 밥보다 먼저 펀딩 트랜잭션 서명을 공개하면 밥은 지출 트랜잭션에 서명하지 않고도 펀딩을 무기한으로 잠글 수 있다.
미승인 트랜잭션 의존성 체인은 이중 소액 결제 채널과 라이트닝 네트워크와 같은 보다 정교한 결제 네트워크의 기본 구성 요소로서, 비트코인 시스템의 확장성과 효율성을 크게 향상 시킬 수 있는 잠재력을 가지고 있다.
현재 비트코인에는 두 가지 실제 보안 모델만 있다. 사용자는 시스템의 모든 규칙으로 모든 블록의 유효성을 검사하는 풀 노드를 실행하거나 일부 트랜잭션의 공개 증명을 통해 헤더의 유효성만 검사하는 SPV(간편 결제 검증) 클라이언트를 실행한다. 비트코인 백서에서는 SPV 노드가 유효하지 않은 블록을 감지하면 전체 노드의 경고를 수락하여 문제가 있는 블록과 트랜잭션을 다운로드하여 검증할 수 있다고 제안했다. 그러나 이러한 접근 방식은 잘못된 경고를 생성하는 데 비용이 거의 들지 않기 때문에 DoS 공격 요인이 될 수 있다. 경고에는 간결하면서도 결정적인 사기 증거 내역이 있어야 한다.
현재 비트코인 프로토콜에서는 몇 가지 규칙을 제외한 거의 모든 규칙에 대해 간결한 사기 증거 내역을 생성할 수 있다.
- 전체 블록 자체와 모든 입력 트랜잭션을 보여주지 않고는 채굴자가 코인베이스 트랜잭션 출력에 너무 많은 비트코인을 도입했음을 증명하는 것은 불가능하다.
- 전체 블록(sigop 제한의 경우 모든 입력 트랜잭션)을 보여주지 않고는 크기 및 sigop 제한과 같은 블록별 제약 조건의 위반을 증명할 수 없다.
- 제네시스 블록으로 거슬러 올라가는 블록체인의 모든 트랜잭션 ID를 보여주지 않고는 존재하지 않는 입력 지출을 증명할 수 없다.
SPV 노드가 빠르게 검증할 수 있는 짧은 블록 무효 증명을 허용하는 추가 증인 데이터를 기록할 수 있다.
- 트랜잭션 수수료에 대한 합 트리를 기록하여 채굴자가 코인베이스 트랜잭션에 과도한 수수료를 추가하지 않는다는 짧은 증명을 구성할 수 있다. 이는 블록 크기와 sigop 수 제한과 비슷하다.
- 트랜잭션의 입력에 의해 소비된 출력에 대한 백링크가 제공될 수 있다. 이러한 백링크는 블록 해시와 오프셋으로 구성되며, 씬 클라이언트(thin client)가 쉽게 쿼리하고 확인하여 출력이 존재하는 지 확인할 수 있다.
이러한 약정은 소프트포크를 통해 확장 가능한 약정 구조에 포함될 수 있으며, 새로운 규칙을 이해하지 못하는 노드에게도 투명하게 공개될 것이다.
버전 바이트가 증인 프로그램보다 먼저 푸시되고, 버전을 알 수 없는 프로그램은 항상 누구나 사용할 수 있는 스크립트로 간주되므로 소프트포크를 통해 새로운 스크립트 시스템을 도입할 수 있다. 구조로서의 증인은 기존 스크립트 의미와 제약 조건, 특히 520바이트 푸시 제한의 제약을 받지 않으므로 임의로 큰 스크립트와 서명을 허용한다.
새로운 스크립트 시스템의 예로는 다중 서명 트랜잭션의 크기를 획기적으로 줄여주는 슈노르 서명(Schnorr signature), 양자 컴퓨팅에 강한 램포트 서명(Lamport signature), 극도로 복잡한 조건부 스크립트에 대해 매우 간결한 증명을 허용하는 마스트(Merklized abstract syntax tree) 등이 있다.
💡 Merklized Abstract Syntax Tree
Merklized Abstract Syntax Tree(MAST)는 BIP-114에서 제안된 것으로, 스크립트 언어의 복잡성을 다루기 위해 만들어진 데이터 구조이다. MAST는 일반적인 머클 트리를 기반으로 하며, 데이터의 해시를 계산하고 이를 트리 형태로 구성한다. MAST에서의 각 노드는 스크립트의 조건 분기를 나타내며, 이는 트랜잭션의 출력을 스크립트 언어로 나타낸 것이다.
현재 트랜잭션에는 nLockTime 필드가 하나만 존재하며, 모든 입력은 동일한 값을 공유해야 한다. 그러나 BIP-68에서는 nSequence 필드를 사용하여 입력별 상대적 잠금 시간을 사용할 수 있지만, 잠금 시간과 정밀도가 제한되어 있다.
소프트포크를 통해 별도의 증인 구조를 도입하여 입력별 잠금 시간과 상대 잠금 시간을 허용하고, 새로운 데이터에 서명하고 조작할 수 있는 새로운 스크립트 시스템을 도입할 수 있다. (예: BIP-65 및 BIP-112)
소프트포크로서 이전 소프트웨어는 수정 없이 계속 작동한다. 그러나 업그레이드 되지 않은 노드는 증인 데이터를 보거나 검증하지 않으며, 모든 증인 프로그램을 누구나 사용할 수 있는 스크립트로 간주한다 (증인 프로그램이 0과 같아서 스크립트가 실패해야 하는 몇 가지 케이스는 제외). 지갑은 누구나 쓸 수 있는 스크립트를 항상 경계하고 의심스럽게 취급해야 한다. 업그레이드 하지 않은 노드는 새로운 기능을 활용하기 위해 업그레이드 할 것을 강력히 권장한다.
업그레이드 하지 않은 지갑이 할 수 있는 일
- 업그레이드 되지 않은 지갑과 업그레이드 된 지갑에서 비트코인 수령
- 기존 P2PKH 주소를 사용해 업그레이드 되지 않은 지갑과 업그레이드 된 지갑으로 비트코인 전송 (세그윗 혜택 없음)
- P2SH 주소를 사용하여 업그레이드 된 지갑으로 비트코인 전송
- BIP-70 결제 프로토콜을 통해 네이티브 증인 프로그램을 사용하여 업그레이드 된 지갑으로 비트코인 전송
업그레이드 하지 않은 지갑이 할 수 없는 일
- 세그윗 트랜잭션을 검증하며, 해당 트랜잭션이 항상 유효하다고 가정한다.
이 BIP는 “세그윗”이라는 이름과 비트 1을 사용하는 “버전 비트” BIP-9로 배포된다.
비트코인 메인넷의 경우, BIP-9 시작 시간은 UTC 2016년 11월 15일 자정(epoch 타임스탬프 1479168000)이며, BIP-9 타임아웃은 UTC 2017년 11월 15일 자정(epoch 타임스탬프 1510704000)이 될 것이다.
비트코인 테스트넷의 경우, BIP-9 시작 시간은 UTC 2016년 5월 1일 자정(epoch 타임스탬프 1462060800)이며, BIP-9 타임아웃은 UTC 2017년 5월 1일 자정(epoch 타임스탬프 1493596800)이 될 것이다.
이번 BIP의 많은 아이디어를 제공한 그레고리 맥스웰(Gregory Maxwell)과 이를 소프트포크로 배포하는 방법을 알아낸 Luke-Jr(루크 주니어)에게 특히 감사를 표한다.
- 예를 들어, OP_0 뒤에 40바이트의 0이 아닌 데이터 푸시가 뒤따르는 scriptPubKey는 잘못된 프로그램 크기로 인해 실패한다. 그러나 OP_0 뒤에 41바이트의 0이 아닌 데이터 푸시가 뒤따르는 scriptPubKey는 증인 프로그램으로 간주되지 않으므로 통과된다.
- 이전 버전과의 호환성을 위해 0~16까지의 모든 버전 바이트에 대해 증인 프로그램의
CastToBool값이 0이면 스크립트가 실패해야 한다. 그러나 이러한 해시값을 가지고 해시 함수에 대한 공격이 발생하더라도 위험은 무시할 만하다. - 1MB 기본 데이터와 3MB 증인 데이터와 같은 두 개의 개별 제한을 두는 대신 단일 복합 제약 조건을 사용하는 이유: 두 개의 개별적인 제한을 사용하면 채굴과 수수료 추정이 거의 불가능해진다. 채굴자는 두 가지 제약 조건이 주어졌을 때 수수료를 최대화하는 트랜잭션 집합을 찾기 위해 복잡한 비선형 최적화 문제를 풀어야 하며, 지갑은 채굴자가 트랜잭션이 포함된 블록을 생성하려고 할 때 두 조건 중 어떤 조건이 가장 큰 제약을 받는지에 따라 지불해야 할 금액을 알 수 없게 된다. 이러한 접근 방식의 또 다른 문제는 무료로 혜택을 받는 행위(freeloading)이다. 트랜잭션 셋이 기본 데이터 1MB 제약에 도달하면 최소한의 수수료만 인상하여 최대 3MB의 추가 데이터를 증인에 추가할 수 있다. 이 경우 추가 증인 공간에 대한 한계 비용은 사실상 0이 된다.
- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013014.html
- BIP16 Pay to Script Hash
- BIP143 Transaction Signature Verification for Version 0 Witness Program
- BIP144 Segregated Witness (Peer Services)
- BIP173 Base32 address format for native v0-16 witness outputs
이 문서는 공공 도메인에 공개되어 있다.