|
|
| 1번째 줄: |
1번째 줄: |
| − | 이 BIP는 Bitcoin 스크립팅 시스템의 새로운 "표준"트랜잭션 유형을 설명하고 새 트랜잭션에만 적용되는 추가 유효성 검사 규칙을 정의한다.
| + | #넘겨주기 [[BIP 16]] |
| − | 자극
| |
| − | 스크립트 대금 지불 해시의 목적은 거래를 상환하기위한 조건을 공급하는 책임을 자금을 보낸 사람으로부터 상환 자로 옮기는 것입니다.
| |
| − | | |
| − | 이점은 발신자가 QR 코드에서 스캔하거나 쉽게 복사하여 붙여 넣을 수있는 고정 길이 20 바이트 해시를 사용하여 아무리 복잡하더라도 임의의 트랜잭션에 자금을 조달 할 수 있다는 것입니다.
| |
| − | | |
| − | 사양
| |
| − | 릴레이되고 마이닝 된 블록에 포함 된 새로운 표준 트랜잭션 유형이 정의됩니다.
| |
| − | | |
| − | OP_HASH160 [20 바이트 해시 값] OP_EQUAL
| |
| − | [20- 바이트-해시-값]은 푸시 -20- 바이트-스택-스택 opcode (0x14)와 정확히 20 바이트 여야합니다. | |
| − | | |
| − | 이 새로운 거래 유형은 표준 scriptSig로 사용됩니다 :
| |
| − | | |
| − | ... 서명 ... {직렬화 된 스크립트}
| |
| − | 스크립트로 지불 시점 을 상환하는 거래는 직렬화 된 스크립트 ( 상환 스크립트 라고도 함 ) 자체가 다른 표준 거래 유형 중 하나 인 경우에만 표준으로 간주됩니다 .
| |
| − | | |
| − | 트랜잭션을 중계하거나 새 블록에 포함시킬 때 이러한 아웃 포인트를 검증하는 규칙은 다음과 같습니다.
| |
| − | | |
| − | scriptSig에 "푸시 데이터"조작 이외의 조작이 있으면 유효성 검증에 실패합니다.
| |
| − | 일반 유효성 검사가 수행됩니다. 서명 및 {직렬화 된 스크립트}에서 초기 스택이 생성되고 스크립트의 해시가 계산되고 아웃 포인트의 해시와 일치하지 않으면 즉시 유효성 검사가 실패합니다.
| |
| − | {serialized script}가 초기 스택에서 튀어 나와서 팝 스택과 deserialized 스크립트를 scriptPubKey로 사용하여 트랜잭션의 유효성이 다시 확인됩니다.
| |
| − | 이 새로운 규칙은 타임 스탬프가> = 1333238400 (2012 년 4 월 1 일) [ 1 ] 인 블록에서 트랜잭션을 확인할 때만 적용해야합니다 . 블록 체인에는 이러한 새로운 유효성 검사 규칙에 실패하는 1333238400 이전의 트랜잭션이 있습니다. [ 2 ] . 이전 거래는 이전 규칙에 따라 검증해야합니다. 자세한 내용은 이전 버전과의 호환성 섹션을 참조하십시오.
| |
| − | 예를 들어, 한 서명이 필요한 트랜잭션에 대한 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 % 여야합니다.
| |
| − | | |
| − | 대부분의 해시 성능이 새로운 유효성 검사 규칙을 지원하지 않으면 롤아웃이 연기됩니다 (또는 다수가 달성되지 않을 것이 확실하면 거부됩니다).
| |
| − | | |
| − | 직렬화 된 스크립트 크기에 대한 520 바이트 제한
| |
| − | 이전 버전과의 호환성 요구 사항의 결과로 직렬화 된 스크립트 자체는 520 바이트보다 큰 데이터를 스택에 푸시 할 수 없다는 규칙을 포함하여 다른 PUSHDATA 작업과 동일한 규칙을 따릅니다. 따라서 참조하는 구속 스크립트 길이가> 520 바이트 인 경우 P2SH 출력을 사용할 수 없습니다. 예를 들어 OP_CHECKMULTISIG opcode 자체는 최대 20 개의 pubkey를 수용 할 수 있지만 33 바이트 압축 pubkey는 최대 15 개의 pubkey를 요구하는 P2SH 출력을 사용하는 것이 가능합니다 : 3 바이트 + 15 개의 pubkeys * 34byte / pubkey = 513 바이트.
| |
위키원
