OP_CAT

연결은 사소해 보이지만 그렇지 않습니다. 이것이 있으면 스크립트가 스택에 밀어 넣은 조각들로부터 트랜잭션의 서명 해시를 520바이트 이하의 청크 단위로 다시 조립한 뒤, 평범한 서명 검사로 그 해시를 확인할 수 있습니다. 위험하다는 이유로 꺼 두었던 옵코드가 코버넌트 목록에서 가장 많이 논의되는 항목이 된 경위가 바로 이것입니다.

작동 방식

상태: 2010년 8월부터 비활성화되어 있으며, 당시 스크립트 엔진을 방어적으로 정비하면서 문자열·산술 옵코드 한 묶음이 꺼졌습니다. BIP-347은 tapscript에서만 다시 활성화할 것을 제안합니다. 메인넷에서는 활성화되어 있지 않습니다.

연산 자체는 한 줄입니다. 두 요소를 꺼내고 그 바이트를 끝에서 끝으로 이어 붙여 밀어 넣습니다. 2010년에 이것이 위험했던 이유는 스택 요소가 얼마나 커질 수 있는지 아무것도 제한하지 않았기 때문입니다. 요소를 자기 자신과 연결하면 크기가 두 배가 되므로, 밀어 넣기와 연결을 짧게 반복하는 것만으로 몇 바이트가 기가바이트로 부풀어 노드의 메모리를 차지할 수 있었습니다. 현대 엔진은 스택 요소 하나에 520바이트라는 엄격한 한도를 두므로, BIP-347은 결과가 이 한도를 넘으면 연산을 그냥 실패시키고, 예전의 공격은 사라집니다.

번호 부여에 특이한 점이 있어서 되살리는 일이 유난히 깔끔합니다. OP_CAT는 옵코드 126입니다. BIP-342가 tapscript를 정의할 때 옵코드 126부터 129까지를 비롯한 여러 옵코드를 OP_SUCCESS로 선언했습니다. 하나를 만나면 스크립트가 그 자리에서 성공합니다. 그래서 구형 노드는 이미 바이트 126을 포함한 어떤 tapscript든 실행하지 않고 받아들입니다. 이를 연결을 수행하는 것으로 재정의하면 그 노드들이 허용했을 범위를 좁힐 뿐이므로, 이 변경은 체인 분열이 아니라 소프트포크가 됩니다.

연결이 열어 주는 것은 그 크기에 비해 터무니없이 큽니다. 바이트 문자열을 만들 수 있는 스크립트는 머클 증명을 검증할 수 있고, 타원 곡선이 아니라 해시로 만든 Lamport 또는 Winternitz 서명을 확인할 수 있으며, 서명이 고정된 nonce를 쓰도록 강제해 서명 방정식 자체가 지출 트랜잭션을 스크립트에 드러내게 할 수 있습니다. 마지막 기법이 OP_CAT를 코버넌트 전용 옵코드 없이 범용 코버넌트 도구로 바꾸는 것입니다.

볼 수 있는 곳

OP_CAT는 비트코인에서는 전혀 실행되지 않습니다. 실행되는 곳은 비트코인의 스크립트 엔진을 복사한 뒤 2010년의 결정을 뒤집은 사이드체인과 테스트 네트워크입니다.

Elements에는, 따라서 Liquid에도 이 옵코드가 활성화되어 있으며, 그래서 공개된 코버넌트 시연 대부분이 비트코인이 아니라 Liquid를 대상으로 작성됩니다. BIP-347 규칙을 담은 맞춤형 signet이 다른 무대이며, 이는 개발자들이 누구에게도 합의 변경을 요청하기 전에 먼저 만들어 볼 수 있도록 존재합니다.

코인을 구매하거나 보유하는 사람에게 실질적인 내용은 짧습니다. OP_CAT가 활성화되든 영원히 되지 않든 지갑, 주소, 백업에는 아무 변화가 없습니다. 이 이름을 알아 둘 가치는 비트코인이 얼마나 많은 프로그래머빌리티를 가져야 하는가에 대한 실제 이견의 한가운데에 있다는 점, 그리고 양자 컴퓨터가 있는 미래를 대비해 해시 기반 서명을 추가하려는 제안들이 대개 이곳을 거친다는 점에 있습니다.