위키원
"BIP16"의 두 판 사이의 차이
hangyuwon95 (토론 | 기여) (→이론적 해석) |
잔글 |
||
| (사용자 2명의 중간 판 11개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | + | '''BIP16'''<!--BIP 16-->은 [[비트코인]] 스크립팅 시스템의 새로운 표준 트랜잭션 유형을 설명하고 새 트랜잭션에만 적용되는 추가 유효성 검사 규칙을 정의한다. | |
| + | |||
==개요== | ==개요== | ||
스크립트 대금 지불 해시의 목적은 거래를 상환하기위한 조건을 공급하는 책임을 자금을 보낸 사람으로부터 상환 자로 옮기는 것이다. | 스크립트 대금 지불 해시의 목적은 거래를 상환하기위한 조건을 공급하는 책임을 자금을 보낸 사람으로부터 상환 자로 옮기는 것이다. | ||
| − | 이점은 발신자가 QR 코드에서 스캔하거나 쉽게 복사하여 붙여 넣을 수있는 고정 길이 20 바이트 해시를 사용하여 아무리 복잡하더라도 임의의 트랜잭션에 자금을 조달 할 수 있다 | + | 이점은 발신자가 QR 코드에서 스캔하거나 쉽게 복사하여 붙여 넣을 수있는 고정 길이 20 바이트 해시를 사용하여 아무리 복잡하더라도 임의의 트랜잭션에 자금을 조달 할 수 있다. |
| + | |||
==사양== | ==사양== | ||
| − | + | [[릴레이]]되고 [[마이닝]]된 블록에 포함된 새로운 표준 트랜잭션 유형이 정의된다. | |
OP_HASH160 [20 바이트 해시 값] OP_EQUAL | OP_HASH160 [20 바이트 해시 값] OP_EQUAL | ||
| 11번째 줄: | 13번째 줄: | ||
이 새로운 거래 유형은 표준 scriptSig로 사용된다 : | 이 새로운 거래 유형은 표준 scriptSig로 사용된다 : | ||
| − | ... 서명 ... { | + | ... 서명 ... {직렬화된 스크립트} |
| − | |||
| − | 스크립트로 지불 | + | 스크립트로 지불 시점을 상환하는 거래는 직렬화된 스크립트('상환 스크립트'라고도 함) 자체가 다른 표준 거래 유형 중 하나 인 경우에만 표준으로 간주된다. |
트랜잭션을 중계하거나 새 블록에 포함시킬 때 이러한 아웃 포인트를 검증하는 규칙은 다음과 같다. | 트랜잭션을 중계하거나 새 블록에 포함시킬 때 이러한 아웃 포인트를 검증하는 규칙은 다음과 같다. | ||
scriptSig에 "푸시 데이터"조작 이외의 조작이 있으면 유효성 검증에 실패한다. | scriptSig에 "푸시 데이터"조작 이외의 조작이 있으면 유효성 검증에 실패한다. | ||
일반 유효성 검사가 수행된다. 서명 및 {직렬화 된 스크립트}에서 초기 스택이 생성되고 스크립트의 해시가 계산되고 아웃 포인트의 해시와 일치하지 않으면 즉시 유효성 검사가 실패한다. | 일반 유효성 검사가 수행된다. 서명 및 {직렬화 된 스크립트}에서 초기 스택이 생성되고 스크립트의 해시가 계산되고 아웃 포인트의 해시와 일치하지 않으면 즉시 유효성 검사가 실패한다. | ||
| − | {serialized script}가 초기 스택에서 튀어 나와서 팝 스택과 deserialized 스크립트를 scriptPubKey로 사용하여 트랜잭션의 유효성이 다시 확인됩니다.이 새로운 규칙은 타임 스탬프가> = 1333238400 (2012 년 4 월 1 일) 인 블록에서 트랜잭션을 확인할 때만 적용해야 한다 . | + | {serialized script}가 초기 스택에서 튀어 나와서 팝 스택과 deserialized 스크립트를 scriptPubKey로 사용하여 트랜잭션의 유효성이 다시 확인됩니다.이 새로운 규칙은 타임 스탬프가> = 1333238400 (2012 년 4 월 1 일) 인 블록에서 트랜잭션을 확인할 때만 적용해야 한다 . 블록체인에는 이러한 새로운 유효성 검사 규칙에 실패하는 1333238400 이전의 트랜잭션이 있다 이전 거래는 이전 규칙에 따라 검증해야한다. |
예를 들어, 한 서명이 필요한 트랜잭션에 대한 scriptPubKey 및 해당 scriptSig는 다음과 같다. | 예를 들어, 한 서명이 필요한 트랜잭션에 대한 scriptPubKey 및 해당 scriptSig는 다음과 같다. | ||
scriptSig : [서명] {[pubkey] OP_CHECKSIG} | scriptSig : [서명] {[pubkey] OP_CHECKSIG} | ||
| 35번째 줄: | 36번째 줄: | ||
==이론적 해석== | ==이론적 해석== | ||
이 BIP는이 BIP 등의 모든 것을 달성하기 위해 새로운 스크립트 opcode ( "OP_EVAL")를 제안한 BIP 12를 대체한다. | 이 BIP는이 BIP 등의 모든 것을 달성하기 위해 새로운 스크립트 opcode ( "OP_EVAL")를 제안한 BIP 12를 대체한다. | ||
| − | 이 BIP (및 스크립트 대 해시 주소 유형 BIP 13)의 동기는 다소 논란의 여지가 있다. 몇몇 사람들은 이것이 불필요하다고 생각하며, 발신자에게 완전한 {직렬화 된 스크립트}를 제공함으로써 복잡한 / 다중 서명 트랜잭션 유형을 지원해야한다. 저자는이 BIP가 자금을 base58로 인코딩 된 20 바이트 | + | 이 BIP (및 스크립트 대 해시 주소 유형 BIP 13)의 동기는 다소 논란의 여지가 있다. 몇몇 사람들은 이것이 불필요하다고 생각하며, 발신자에게 완전한 {직렬화 된 스크립트}를 제공함으로써 복잡한 / 다중 서명 트랜잭션 유형을 지원해야한다. 저자는이 BIP가 자금을 base58로 인코딩 된 20 바이트 비트코인 주소로 송금하기 위해 이미 생성 된 모든 지원 인프라에 필요한 변경을 최소화하여 판매자와 교환 및 기타 소프트웨어가보다 빨리 다중 서명 트랜잭션을 지원할 수 있다고 생각한다 . |
하나의 '특별한'형식의 scriptPubKey를 인식하고 감지 될 때 추가 유효성 검사를 수행하는 것은 추악하다. 그러나, 대안은 더 나쁘고, 구현하기가 더 복잡하고, 및 / 또는 표현 언어의 힘을 위험한 방식으로 확장한다는 데 공감대가 있다. | 하나의 '특별한'형식의 scriptPubKey를 인식하고 감지 될 때 추가 유효성 검사를 수행하는 것은 추악하다. 그러나, 대안은 더 나쁘고, 구현하기가 더 복잡하고, 및 / 또는 표현 언어의 힘을 위험한 방식으로 확장한다는 데 공감대가 있다. | ||
| − | 서명 연산 계산 규칙은 {직렬화 된 스크립트}를 정적으로 스캔하여 쉽고 빠르게 구현할 수 있도록 | + | 서명 연산 계산 규칙은 {직렬화 된 스크립트}를 정적으로 스캔하여 쉽고 빠르게 구현할 수 있도록 고안되었다. 비트코인은 채굴자에 대한 서비스 거부 공격을 방지하기 위해 블록 당 최대 수의 서명 작업을 시행한다. 제한이 없다면, 불량 광부는 검증을 위해 수십만 개의 ECDSA 서명 작업이 필요한 블록을 브로드 캐스트 할 수 있으며 나머지 네트워크가 현재의 유효성을 검증하는 동안 다음 블록을 계산할 수 있다. 하나. |
기존 구현에 대해 1 번의 확인 공격이 있지만 실제로는 비용이 많이 들고 어렵다. 공격은 다음과같다. | 기존 구현에 대해 1 번의 확인 공격이 있지만 실제로는 비용이 많이 들고 어렵다. 공격은 다음과같다. | ||
공격자는 기존 소프트웨어에서 볼 수 있지만 새 구현에는 유효하지 않은 스크립트에 지불하는 트랜잭션을 생성하고이를 사용하여 동전을 보낸다. | 공격자는 기존 소프트웨어에서 볼 수 있지만 새 구현에는 유효하지 않은 스크립트에 지불하는 트랜잭션을 생성하고이를 사용하여 동전을 보낸다. | ||
| 46번째 줄: | 47번째 줄: | ||
==이전 버전과의 호환성== | ==이전 버전과의 호환성== | ||
| − | 이러한 트랜잭션은 표준 구현에서 비 구현 구현으로, 일반적으로 트랜잭션을 릴레이하거나 블록에 포함하지 | + | 이러한 트랜잭션은 표준 구현에서 비 구현 구현으로, 일반적으로 트랜잭션을 릴레이하거나 블록에 포함하지 않는다. |
| − | + | 이전 구현에서는이 BIP를 완전히 지원하는 소프트웨어로 작성된 블록을 유효성 검증 할 때 {serialize script}의 해시 값이 일치하는지 검증하지만 다른 유효성 검증은 수행하지 않는다. | |
| − | 이전 구현에서는이 BIP를 완전히 지원하는 소프트웨어로 작성된 블록을 유효성 검증 할 때 {serialize script}의 해시 값이 일치하는지 검증하지만 다른 유효성 검증은 수행하지 | + | 악의적인 P2P 트랜잭션으로 인한 블록체인 분할을 피하려면 한 가지 경우를 신중하게 처리해야 한다. |
| + | 새 클라이언트 / 광부에는 유효하지 않지만 이전 클라이언트 / 광부에는 유효하다. | ||
| + | 오래 지속되는 블록체인 분할이 정상적으로 업그레이드되고 보장되지 않도록하려면 채굴 자 중 50 % 이상이 새로운 트랜잭션 유형의 전체 유효성 검사를 지원해야하며 동시에 이전 유효성 검사 규칙에서 새 규칙으로 전환해야 한다. | ||
| + | 해시 파워의 50 % 이상이이 BIP를 지원하는지 여부를 판단하기 위해 채굴 자들은 소프트웨어를 업그레이드하고 코인베이스 트랜잭션 입력에 "/ P2SH /"문자열을 넣어 블록을 생성해야한다. | ||
| + | 2012년 2월 1일에 블록체인을 검사하여 이전 7일 동안의 스크립트 대 해시를 지원하는 블록 수를 결정한다. 550개 이상의 [[코인베이스]]에 "/ P2SH /"가 포함된 경우, 2012년 2월 15일 00:00:00 GMT 이후 타임 스탬프가 있는 모든 블록은 스크립트 대 해시 트랜잭션이 완전히 검증된다. 일주일에 약 1,000 개의 블록이 생성된다. 따라서 550은 새 기능을 지원하는 네트워크의 약 55%여야 한다. 대부분의 해시 성능이 새로운 유효성 검사 규칙을 지원하지 않으면 롤아웃이 연기된다.<ref>dergigi, 〈[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP : 16 ]〉, 《깃허브》</ref> | ||
| − | + | ==직렬화된 스크립트 크기에 대한 520바이트 제한== | |
| + | 이전 버전과의 호환성 요구 사항의 결과로 직렬화된 스크립트 자체는 520 바이트보다 큰 데이터를 스택에 푸시할 수 없다는 규칙을 포함하여 다른 PUSHDATA 작업과 동일한 규칙을 따릅니다. 따라서 참조하는 구속 스크립트 길이가> 520 바이트 인 경우 P2SH 출력을 사용할 수 없습니다. 예를 들어 OP_CHECKMULTISIG opcode 자체는 최대 20 개의 pubkey를 수용 할 수 있지만 33 바이트 압축 pubkey는 최대 15개의 pubkey를 요구하는 [[P2SH]] 출력을 사용하는 것이 가능하다 : 3 바이트 + 15 개의 pubkeys * 34byte / pubkey = 513 바이트. | ||
| − | + | {{각주}} | |
| − | |||
| − | |||
| − | + | ==참고자료== | |
| + | * 받을만한, 〈[https://bitcointalk.org/index.php?topic=46538 OP_EVAL 제안]〉, 《비트코인토크》, 2011-10-02 | ||
| + | * danra, 〈[https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki BIP : 13]〉, 《깃허브》, 2017-10-23 | ||
| + | * Varunram, 〈[https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki bip-0011]〉, 《깃허브》, 2018-07-06 | ||
| + | * kaidiren, 〈[https://github.com/bitcoin/bips/blob/master/bip-0016/qa.mediawiki bip-0016]〉, 《깃허브》, 2018-09-26 | ||
| + | * dergigi, 〈[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki bip-0016 2]〉, 《깃허브》, 2019-05-10 | ||
| − | + | ==같이 보기== | |
| + | * [[BIP]] | ||
| − | + | {{블록체인 기술|검토 필요}} | |
| − | |||
2019년 9월 1일 (일) 16:05 기준 최신판
BIP16은 비트코인 스크립팅 시스템의 새로운 표준 트랜잭션 유형을 설명하고 새 트랜잭션에만 적용되는 추가 유효성 검사 규칙을 정의한다.
개요[편집]
스크립트 대금 지불 해시의 목적은 거래를 상환하기위한 조건을 공급하는 책임을 자금을 보낸 사람으로부터 상환 자로 옮기는 것이다. 이점은 발신자가 QR 코드에서 스캔하거나 쉽게 복사하여 붙여 넣을 수있는 고정 길이 20 바이트 해시를 사용하여 아무리 복잡하더라도 임의의 트랜잭션에 자금을 조달 할 수 있다.
사양[편집]
릴레이되고 마이닝된 블록에 포함된 새로운 표준 트랜잭션 유형이 정의된다.
OP_HASH160 [20 바이트 해시 값] OP_EQUAL
[20- 바이트-해시-값]은 푸시 -20- 바이트-스택-스택 opcode (0x14)와 정확히 20 바이트 여야한다. 이 새로운 거래 유형은 표준 scriptSig로 사용된다 :
... 서명 ... {직렬화된 스크립트}
스크립트로 지불 시점을 상환하는 거래는 직렬화된 스크립트('상환 스크립트'라고도 함) 자체가 다른 표준 거래 유형 중 하나 인 경우에만 표준으로 간주된다.
트랜잭션을 중계하거나 새 블록에 포함시킬 때 이러한 아웃 포인트를 검증하는 규칙은 다음과 같다. scriptSig에 "푸시 데이터"조작 이외의 조작이 있으면 유효성 검증에 실패한다. 일반 유효성 검사가 수행된다. 서명 및 {직렬화 된 스크립트}에서 초기 스택이 생성되고 스크립트의 해시가 계산되고 아웃 포인트의 해시와 일치하지 않으면 즉시 유효성 검사가 실패한다. {serialized script}가 초기 스택에서 튀어 나와서 팝 스택과 deserialized 스크립트를 scriptPubKey로 사용하여 트랜잭션의 유효성이 다시 확인됩니다.이 새로운 규칙은 타임 스탬프가> = 1333238400 (2012 년 4 월 1 일) 인 블록에서 트랜잭션을 확인할 때만 적용해야 한다 . 블록체인에는 이러한 새로운 유효성 검사 규칙에 실패하는 1333238400 이전의 트랜잭션이 있다 이전 거래는 이전 규칙에 따라 검증해야한다. 예를 들어, 한 서명이 필요한 트랜잭션에 대한 scriptPubKey 및 해당 scriptSig는 다음과 같다.
scriptSig : [서명] {[pubkey] OP_CHECKSIG}
scriptPubKey : OP_HASH160 [{[pubkey]의 20 바이트 해시 OP_CHECKSIG}] OP_EQUAL
{직렬화 된 스크립트}의 서명 작업은 다음과 같이 블록 당 허용되는 최대 수 (20,000)에 기여한다. OP_CHECKSIG 및 OP_CHECKSIGVERIFY는 평가 여부에 관계없이 1 개의 서명 작업으로 계산된다. OP_1부터 OP_16까지 바로 앞에 오는 OP_CHECKMULTISIG 및 OP_CHECKMULTISIGVERIFY는 평가 여부에 관계없이 1-16 개의 서명 작업으로 계산된다. 다른 모든 OP_CHECKMULTISIG 및 OP_CHECKMULTISIGVERIFY는 20 개의 서명 작업으로 계산된다. 예 : +3 서명 작업 :
{2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}
서명 작업 +22
{OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}
이론적 해석[편집]
이 BIP는이 BIP 등의 모든 것을 달성하기 위해 새로운 스크립트 opcode ( "OP_EVAL")를 제안한 BIP 12를 대체한다. 이 BIP (및 스크립트 대 해시 주소 유형 BIP 13)의 동기는 다소 논란의 여지가 있다. 몇몇 사람들은 이것이 불필요하다고 생각하며, 발신자에게 완전한 {직렬화 된 스크립트}를 제공함으로써 복잡한 / 다중 서명 트랜잭션 유형을 지원해야한다. 저자는이 BIP가 자금을 base58로 인코딩 된 20 바이트 비트코인 주소로 송금하기 위해 이미 생성 된 모든 지원 인프라에 필요한 변경을 최소화하여 판매자와 교환 및 기타 소프트웨어가보다 빨리 다중 서명 트랜잭션을 지원할 수 있다고 생각한다 . 하나의 '특별한'형식의 scriptPubKey를 인식하고 감지 될 때 추가 유효성 검사를 수행하는 것은 추악하다. 그러나, 대안은 더 나쁘고, 구현하기가 더 복잡하고, 및 / 또는 표현 언어의 힘을 위험한 방식으로 확장한다는 데 공감대가 있다. 서명 연산 계산 규칙은 {직렬화 된 스크립트}를 정적으로 스캔하여 쉽고 빠르게 구현할 수 있도록 고안되었다. 비트코인은 채굴자에 대한 서비스 거부 공격을 방지하기 위해 블록 당 최대 수의 서명 작업을 시행한다. 제한이 없다면, 불량 광부는 검증을 위해 수십만 개의 ECDSA 서명 작업이 필요한 블록을 브로드 캐스트 할 수 있으며 나머지 네트워크가 현재의 유효성을 검증하는 동안 다음 블록을 계산할 수 있다. 하나. 기존 구현에 대해 1 번의 확인 공격이 있지만 실제로는 비용이 많이 들고 어렵다. 공격은 다음과같다. 공격자는 기존 소프트웨어에서 볼 수 있지만 새 구현에는 유효하지 않은 스크립트에 지불하는 트랜잭션을 생성하고이를 사용하여 동전을 보낸다. 또한 공격자는 P2P 트랜잭션을 사용하고 이전 소프트웨어를 실행중인 피해자에게 지불하는 표준 트랜잭션을 만든다. 공격자는 두 거래를 모두 포함하는 블록을 채굴한다. 피해자가 1- 확인 지불을 수락하면 나머지 네트워크가 공격자의 잘못된 블록을 덮어 쓸 때 두 트랜잭션이 모두 무효화되므로 공격자가 승리한다. 공격자는 공격자가 나머지 네트워크에 의해 무효화 될 것으로 알고있는 블록을 생성해야하므로 비용이 많이 든다. 블록 생성이 어렵고 사용자가 고 가치 거래에 대해 1- 확인 거래를 수락해서는 안되기 때문에 어렵다.
이전 버전과의 호환성[편집]
이러한 트랜잭션은 표준 구현에서 비 구현 구현으로, 일반적으로 트랜잭션을 릴레이하거나 블록에 포함하지 않는다. 이전 구현에서는이 BIP를 완전히 지원하는 소프트웨어로 작성된 블록을 유효성 검증 할 때 {serialize script}의 해시 값이 일치하는지 검증하지만 다른 유효성 검증은 수행하지 않는다. 악의적인 P2P 트랜잭션으로 인한 블록체인 분할을 피하려면 한 가지 경우를 신중하게 처리해야 한다. 새 클라이언트 / 광부에는 유효하지 않지만 이전 클라이언트 / 광부에는 유효하다. 오래 지속되는 블록체인 분할이 정상적으로 업그레이드되고 보장되지 않도록하려면 채굴 자 중 50 % 이상이 새로운 트랜잭션 유형의 전체 유효성 검사를 지원해야하며 동시에 이전 유효성 검사 규칙에서 새 규칙으로 전환해야 한다. 해시 파워의 50 % 이상이이 BIP를 지원하는지 여부를 판단하기 위해 채굴 자들은 소프트웨어를 업그레이드하고 코인베이스 트랜잭션 입력에 "/ P2SH /"문자열을 넣어 블록을 생성해야한다. 2012년 2월 1일에 블록체인을 검사하여 이전 7일 동안의 스크립트 대 해시를 지원하는 블록 수를 결정한다. 550개 이상의 코인베이스에 "/ P2SH /"가 포함된 경우, 2012년 2월 15일 00:00:00 GMT 이후 타임 스탬프가 있는 모든 블록은 스크립트 대 해시 트랜잭션이 완전히 검증된다. 일주일에 약 1,000 개의 블록이 생성된다. 따라서 550은 새 기능을 지원하는 네트워크의 약 55%여야 한다. 대부분의 해시 성능이 새로운 유효성 검사 규칙을 지원하지 않으면 롤아웃이 연기된다.[1]
직렬화된 스크립트 크기에 대한 520바이트 제한[편집]
이전 버전과의 호환성 요구 사항의 결과로 직렬화된 스크립트 자체는 520 바이트보다 큰 데이터를 스택에 푸시할 수 없다는 규칙을 포함하여 다른 PUSHDATA 작업과 동일한 규칙을 따릅니다. 따라서 참조하는 구속 스크립트 길이가> 520 바이트 인 경우 P2SH 출력을 사용할 수 없습니다. 예를 들어 OP_CHECKMULTISIG opcode 자체는 최대 20 개의 pubkey를 수용 할 수 있지만 33 바이트 압축 pubkey는 최대 15개의 pubkey를 요구하는 P2SH 출력을 사용하는 것이 가능하다 : 3 바이트 + 15 개의 pubkeys * 34byte / pubkey = 513 바이트.
각주[편집]
참고자료[편집]
- 받을만한, 〈OP_EVAL 제안〉, 《비트코인토크》, 2011-10-02
- danra, 〈BIP : 13〉, 《깃허브》, 2017-10-23
- Varunram, 〈bip-0011〉, 《깃허브》, 2018-07-06
- kaidiren, 〈bip-0016〉, 《깃허브》, 2018-09-26
- dergigi, 〈bip-0016 2〉, 《깃허브》, 2019-05-10
같이 보기[편집]
