원저자: HashKey Capital 투자 연구 책임자 Jeffrey HU, HashKey Capital 투자 관리자 Harper LI
최근 비트코인 커뮤니티에서는 OP_CAT과 같은 opcode를 다시 활성화하는 것에 대한 논의가 활발해졌습니다. Taproot Wizard도 Quantum Cats NFT를 출시하고 BIP-420 번호를 획득했다고 주장하여 많은 사람들의 관심을 끌었습니다. 지지자들은 OP_CAT을 활성화하면 비트코인의 계약, 스마트 계약 또는 프로그래밍 기능을 활성화할 수 있다고 주장합니다.
제한 사항이라는 단어를 발견하고 조금만 검색해 보면 이것이 또 다른 큰 토끼굴이라는 것을 알게 될 것입니다. 개발자들은 OP_CAT 외에도 OP_CTV, APO, OP_VAULT 및 기타 제한 조항을 구현하는 기술에 대해 수년간 논의해 왔습니다.
그렇다면 비트코인의 제한 사항은 정확히 무엇입니까? 수년 동안 왜 그렇게 많은 개발자의 관심과 논의를 끌어왔습니까? 비트코인으로 어떤 종류의 프로그래밍 가능성을 달성할 수 있나요? 그 뒤에 숨은 디자인 원리는 무엇입니까? 이 기사에서는 개요 소개 및 토론을 제공하려고 시도합니다.
제한사항이란 무엇입니까?
중국어로 제한으로 번역되고 때로는 계약으로 번역되는 규약은 향후 비트코인 거래에 대한 조건을 설정할 수 있는 메커니즘입니다.
현재 비트코인 스크립트에는 지출 시 법적 서명 입력, 일치하는 스크립트 전송 등과 같은 제한적인 조건도 포함되어 있습니다. 그러나 사용자가 잠금을 해제할 수 있는 한 그는 원하는 곳 어디에서나 UTXO를 사용할 수 있습니다.
제한 조항은 UTXO 이후 지출을 제한하는 등 이 제한을 해제하는 방법에 따라 더 많은 제한을 가하는 것입니다. 이는 전용 자금과 유사한 효과를 달성하거나 거래 대기 시 전송되는 기타 입력 조건입니다.
더 엄밀히 말하면 현재 비트코인 스크립트에도 일정한 제한이 있습니다. 예를 들어 연산 코드를 기반으로 한 시간 잠금은 트랜잭션의 nLock 또는 nSequence 필드를 검사하여 트랜잭션이 소비되기 전에 시간 제한을 실현하는 것이지만 기본적으로는 그렇습니다. 시간 제약으로 제한됩니다.
그렇다면 개발자와 연구원은 왜 이러한 제한 확인을 설계합니까? 제한 조항은 단지 제한을 위한 제한이 아니기 때문에 트랜잭션 실행에 대한 규칙도 설정합니다. 이러한 방식으로 사용자는 미리 설정된 규칙에 따라 거래를 실행하여 미리 결정된 비즈니스 프로세스를 완료할 수 있습니다.
따라서 반직관적으로 이는 더 많은 애플리케이션 시나리오를 잠금 해제할 수 있습니다.
애플리케이션 시나리오
스테이킹 페널티 보장
제한 조항의 가장 직관적인 예 중 하나는 비트코인 스테이킹 프로세스에서 바빌론의 슬래시 거래입니다.
Babylon의 비트코인 스테이킹 프로세스는 사용자가 BTC 자산을 메인 체인의 특수 스크립트로 보내는 것입니다. 지출 조건에는 두 가지 유형이 포함됩니다.
해피엔딩: 일정 시간이 지난 후 사용자는 자신의 서명으로 잠금을 해제할 수 있으며 이를 통해 언스테이크 프로세스가 완료됩니다.
배드엔딩: 바빌론이 임대한 특정 PoS 체인에서 사용자가 이중 서명 등의 사악한 행위를 저지르면 EOTS(추출 가능한 일회성 서명, 일회성 추출 가능한 서명)를 통해 이 부분의 자산이 잠금 해제될 수 있습니다. 네트워크의 실행 행위자는 자산의 일부를 소각 주소(슬래시)로 보내도록 강제합니다.
출처: 비트코인 스테이킹: 지분 증명 경제를 확보하기 위해 2100만 비트코인 잠금 해제
여기서 강제 전송에 주의하세요. 즉, 이 UTXO를 잠금 해제할 수 있더라도 해당 자산을 임의로 다른 곳으로 보낼 수 없으며 소각만 가능하다는 의미입니다. 이렇게 하면 악의적인 사용자가 처벌을 피하기 위해 알려진 서명을 사용하여 자산을 자신에게 다시 전송하는 것을 방지할 수 있습니다.
OP_CTV와 같은 제한 사항이 구현된 후에 이 기능이 구현되면 스테이킹 스크립트의 배드 엔딩 분기에 OP_CTV와 같은 opcode를 추가하여 제한 사항을 구현할 수 있습니다.
OP_CTV가 활성화되기 전에 Babylon은 제한 조항 시행 효과를 시뮬레이션하기 위해 사용자와 위원회가 공동으로 구현하는 유연한 방법을 사용해야 합니다.
혼잡 제어
일반적으로 정체란 비트코인 네트워크의 거래 수수료가 매우 높고 패키징을 기다리는 거래 풀에 더 많은 거래가 축적되어 있는 경우를 의미합니다. 따라서 사용자가 거래를 빠르게 확인하려면 거래 수수료를 높여야 합니다.
이때 사용자가 여러 수취인에게 여러 거래를 보내야 하는 경우 처리 수수료가 증가하고 상대적으로 높은 비용을 부담해야 합니다. 동시에 전체 네트워크의 처리 속도도 더욱 높아질 것입니다.
제한사항이 있는 경우 한 가지 해결책은 발신자가 일괄 전송 트랜잭션을 커밋하는 것입니다. 이 약속은 모든 수신자가 최종 거래가 수행될 것이라고 믿게 만들 수 있으며, 특정 거래를 보내기 전에 처리율이 낮아질 때까지 기다릴 수 있습니다.
아래 차트에서 볼 수 있듯이 블록 공간에 대한 수요가 높을 때 거래를 수행하는 데 드는 비용이 매우 높아집니다. OP_CHECKTEMPLATEVERIFY를 사용하면 대량 결제 프로세서가 확인을 위해 모든 결제를 단일 O(1) 거래로 집계할 수 있습니다. 그런 다음 시간이 지남에 따라 블록 공간에 대한 수요가 감소하면 해당 UTXO에서 지불이 확장될 수 있습니다. 
출처: https://utxos.org/uses/scaling/
본 시나리오는 OP_CTV 제한 조항에서 제안하는 일반적인 적용 사례입니다. 더 많은 적용 사례는 https://utxos.org/uses/에서 확인할 수 있습니다. 위의 혼잡 제어 외에도 해당 페이지에는 Soft Fork Bets, Decentralized options, Drivechains, Batch Channels, Non Interactive Channels, Trustless Coordination-Free Mining이 나열되어 있습니다. 풀, 볼트, 안전한 해시 시간 잠금 계약(HTLCS) 제한 등
둥근 천장
Vault는 비트코인 애플리케이션, 특히 제한 조항 분야에서 널리 논의되는 애플리케이션 시나리오입니다. 일상적인 운영에는 필연적으로 자금 보관과 자금 사용 요구 사이의 균형이 필요하기 때문에 사람들은 자금의 안전을 보장하고 계정이 해킹되더라도 자금의 보안을 제한할 수 있는 일종의 금고 애플리케이션을 갖고 싶어합니다(개인 키는 유출).
Vault 클래스 응용 프로그램은 제한 사항을 구현하는 기술을 기반으로 비교적 쉽게 구축할 수 있습니다.
OP_VAULT의 설계를 예로 들어보겠습니다. 금고에서 자금을 사용할 때 거래가 먼저 체인으로 전송되어야 합니다. 이 거래는 트리거인 볼트를 사용하려는 의도를 나타내며 그 안에 조건을 설정합니다.
모든 것이 괜찮다면 두 번째 거래가 최종 인출이 이루어지는 거래입니다. N 블록을 기다린 후 자금은 어디에서나 추가로 사용될 수 있습니다.
이 거래가 도난당한(또는 렌치 공격 중에 강요된) 것으로 밝혀지면 N 블록의 출금 거래가 전송되기 전에 즉시 다른 안전한 주소(사용자에게 더 안전한 저장소)로 전송될 수 있습니다.
OP_VAULT 프로세스, 출처: BIP-345
볼트 애플리케이션은 제한 없이 구축할 수도 있습니다. 가능한 방법은 개인 키를 사용하여 향후 지출을 위한 서명을 준비한 다음 개인 키를 파기하는 것입니다. 그러나 개인 키가 파기되었는지 확인해야 하는 필요성(영지식 증명의 신뢰할 수 있는 설정 프로세스와 유사), 금액 및 처리 수수료가 사전에 결정되는 등(수수료가 필요하기 때문에) 여전히 많은 제한 사항이 있습니다. 사전 서명) 유연성이 부족합니다.
OP_VAULT와 사전 서명된 볼트 프로세스 비교, 출처: BIP-345
더욱 강력하고 유연한 상태 채널
일반적으로 라이트닝 네트워크를 포함한 상태 채널은 메인 체인과 거의 동일한 보안을 가지고 있다고 간주할 수 있습니다(노드가 최신 상태를 관찰할 수 있고 일반적으로 최신 상태를 체인에 게시할 수 있는 경우). 그러나 제한 사항이 적용되면 일부 새로운 상태 채널 디자인 아이디어가 라이트닝 네트워크를 기반으로 더욱 강력하거나 유연해질 수 있습니다. 가장 잘 알려진 것으로는 Eltoo, Ark 등이 있습니다.
Eltoo(LN-Symmetry라고도 함)는 가장 일반적인 예 중 하나입니다. 이 기술 솔루션은 L2와 동음이며 후속 채널 상태가 페널티 메커니즘 없이 이전 상태를 대체할 수 있도록 하는 라이트닝 네트워크에 대한 실행 계층을 제안합니다. 따라서 라이트닝과 유사하게 저장할 필요도 없습니다. 네트워크 노드. 상대방이 악한 일을 하는 것을 방지하기 위한 여러 이전 상태입니다. 위와 같은 효과를 얻기 위해 Eltoo에서는 SIGHASH_NOINPUT 서명 방식, 즉 APO(BIP-118)를 제안했습니다.
Ark는 라이트닝 네트워크의 인바운드 유동성 및 채널 관리의 어려움을 줄이는 것을 목표로 합니다. 조인풀 형태의 프로토콜로, 다수의 사용자가 일정 기간 내에 하나의 서비스 제공자를 상대방으로 받아들여 체인 외부에서 가상 UTXO(vUTXO) 트랜잭션을 수행하지만, 비용 절감을 위해 체인 상에서 UTXO를 공유할 수 있습니다. 볼트와 유사하게 Ark는 현재 비트코인 네트워크에서도 구현할 수 있습니다. 그러나 제한 사항을 도입한 후 Ark는 거래 템플릿을 기반으로 필요한 상호 작용의 양을 줄이고 보다 신뢰할 수 없는 일방적인 종료를 달성할 수 있습니다.
제한사항의 기술 개요
위의 적용 사례에서 볼 수 있듯이 제한 조항은 특정 기술이라기보다는 효과에 가깝기 때문에 이를 구현하는 기술적 방법은 다양합니다. 분류된 경우 여기에는 다음이 포함될 수 있습니다.
유형: 일반형, 특수형
구현방식 : Opcode 기반, 시그니처 기반
재귀: 재귀적, 비재귀적
그 중 재귀는 다음 출력을 제한하여 다음 출력을 제한할 수도 있으며, 추가된 제한은 하나의 트랜잭션을 초과하고 더 높은 트랜잭션 깊이에 도달할 수도 있습니다.
널리 사용되는 제한 조항 디자인은 다음과 같습니다. 
* 재귀: OP_CAT과 결합된 경우
제한의 설계
이전 소개에서 볼 수 있듯이 현재 비트코인 스크립트는 주로 잠금 해제 조건을 제한하며 UTXO를 추가로 사용할 수 있는 방법을 제한하지 않습니다. 제한 사항을 구현하려면 반대로 생각해야 합니다. 현재 비트코인 스크립트가 제한 사항을 구현할 수 없는 이유는 무엇입니까?
주된 이유는 현재 비트코인 스크립트가 거래 자체의 내용, 즉 거래의 내성을 읽을 수 없기 때문입니다.
트랜잭션 자체 검사(출력 포함)를 검사하는 트랜잭션 자체 검사를 구현할 수 있다면 제약 조건을 구현할 수 있습니다.
따라서 제한 조항의 디자인 아이디어는 주로 성찰을 달성하는 방법에 중점을 둡니다.
Opcode 기반 및 서명 기반
가장 간단하고 조잡한 아이디어는 하나 이상의 opcode(즉, 하나의 opcode + 여러 매개변수 또는 서로 다른 기능을 가진 여러 개의 opcode)를 추가하여 트랜잭션의 내용을 직접 읽는 것입니다. 이는 작업 코드를 기반으로 한 아이디어입니다.
또 다른 아이디어는 트랜잭션 자체의 내용을 스크립트에서 직접 읽고 확인할 수는 없지만 트랜잭션 내용의 해시를 사용할 수 있다는 것입니다. 해시가 서명된 경우 OP_CHECKSIG와 같은 스크립트에서 수정하면 됩니다. 이 서명을 확인하면 트랜잭션 자체 검사 및 제한을 간접적으로 구현할 수 있습니다. 이 아이디어는 시그니처 디자인을 기반으로 합니다. 주로 APO, OP_CSFS 등을 포함합니다.
APO
SIGHASH_ANYPREVOUT(APO)은 제안된 비트코인 서명 방법입니다. 가장 간단한 서명 방법은 트랜잭션의 입력과 출력을 모두 커밋하는 것이지만 비트코인에는 트랜잭션의 입력 또는 출력을 선택적으로 커밋하는 보다 유연한 방법, 즉 SIGHASH도 있습니다.
SIGHASH의 현재 서명 범위와 거래 입력 및 출력 조합(출처: Mastering Bitcoin, 2nd)
위 그림과 같이 모든 데이터에 적용되는 ALL 외에 NONE 시그니처 방식은 모든 입력에만 적용되고 출력에는 사용되지 않으며, SINGLE은 이를 기반으로 동일한 입력 시퀀스 번호를 갖는 출력에만 적용됩니다. 또한 SIGHASH는 ANYONECANPAY 수정자를 중첩한 후 하나의 입력에만 적용 가능합니다.
APO의 SIGHASH는 입력 부분이 아닌 출력에만 서명합니다. 이는 또한 APO로 서명된 거래가 나중에 조건을 충족하는 모든 UTXO에 첨부될 수 있음을 의미합니다.
이러한 유연성은 APO가 제한 조항을 구현하는 이론적 기반입니다.
하나 이상의 거래를 미리 생성할 수 있습니다.
이러한 거래 정보를 이용하여 서명만 얻을 수 있는 공개키가 생성됩니다.
이렇게 하면 해당 공개 키 주소로 전송된 모든 자산은 사전 생성된 거래를 통해서만 사용될 수 있습니다.
이 공개 키에는 해당 개인 키가 없기 때문에 이러한 자산은 사전 생성된 거래를 통해서만 사용할 수 있다는 점에 유의할 가치가 있습니다. 그런 다음 사전 생성된 거래에서 자산의 목적지를 규정하여 제한적인 조건을 구현할 수 있습니다.
이더리움의 스마트 계약을 비교하면 더 잘 이해할 수 있습니다. 스마트 계약을 통해 얻을 수 있는 것은 EOA 서명으로 임의로 지출하는 대신 특정 조건을 통과해야만 계약 주소에서 돈을 인출할 수 있다는 것입니다. 이러한 관점에서 비트코인은 서명 메커니즘의 개선을 통해 이러한 효과를 얻을 수 있습니다.
그러나 위 프로세스의 문제점은 트랜잭션을 사전 서명하고 생성하려면 입력을 알아야 하기 때문에 계산에 순환 종속성이 있다는 것입니다.
이 서명 방법을 구현하는 APO 및 SIGHASH_NOINPUT의 중요성은 계산할 때 트랜잭션의 모든 출력만 알면(지정하면) 이 순환 종속성 문제를 해결할 수 있다는 것입니다.
OP_CTV
OP_CHECKTEMPLATEVERIFY(CTV), BIP-119는 Opcode를 개선하는 방법을 채택합니다. 커밋 해시를 매개변수로 사용하고 opcode를 실행하는 모든 트랜잭션에는 해당 커밋과 일치하는 출력 집합이 포함되어야 합니다. CTV를 통해 비트코인 사용자는 비트코인 사용 방법을 제한할 수 있습니다.
이 제안은 원래 OP_CHECKOUTPUTSHASHVERIFY(COSHV)라는 이름으로 시작되었으며 초기에는 혼잡 제어 트랜잭션을 생성하는 기능에 중점을 두었습니다. 따라서 제안에 대한 비판도 계획이 충분히 일반적이지 않고 혼잡 제어 사용 사례에 너무 구체적이라는 점에 초점을 맞췄습니다.
위에서 언급한 혼잡 제어 사용 사례에서 보낸 사람 Alice는 10개의 출력을 생성 및 해시하고 결과 다이제스트를 사용하여 COSHV가 포함된 Tapleaf 스크립트를 생성할 수 있습니다. 또한 Alice는 참가자의 공개 키를 사용하여 Taproot 내부 키를 형성할 수 있으므로 Taproot 스크립트 경로를 공개하지 않고도 지출에 대해 협업할 수 있습니다.
그런 다음 Alice는 각 수신자에게 10개 출력의 복사본을 모두 제공하여 각 수신자가 Alice의 설정 트랜잭션을 확인할 수 있도록 합니다. 나중에 지불금을 사용하고 싶을 때 둘 중 하나는 약속된 출력이 포함된 거래를 생성할 수 있습니다.
프로세스 전반에 걸쳐 Alice가 설정 트랜잭션을 생성하고 전송하면서 Alice는 이메일이나 클라우드 드라이브와 같은 기존 비동기 통신 방법을 통해 이러한 10개의 출력 복사본을 보낼 수 있습니다. 이는 수신자가 온라인 상태이거나 서로 상호 작용할 필요가 없음을 의미합니다.
출처: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
APO와 마찬가지로 주소도 지출 조건에 따라 구성할 수 있으며, 다른 키 추가, 시간 잠금, 결합 가능한 논리 등 다양한 방법으로 잠금을 만들 수 있습니다.
출처: https://twitter.com/OwenKemeys/status/1741575353716326835
이를 바탕으로 CTV는 해싱 후 소비된 트랜잭션이 정의된 트랜잭션과 일치하는지 확인할 수 있다고 제안했습니다. 즉, 트랜잭션 데이터를 잠금을 여는 키로 사용할 수 있습니다.
위의 10개 수신기 예를 계속 확장하면 수신기는 주소 키를 서명되었지만 브로드캐스트되지 않은 tx로 추가로 설정하고 이를 다음 수신기 주소 배치로 보내는 등의 작업을 수행하여 아래 그림과 같은 시스템을 구성할 수 있습니다. . 트리 구조. Alice는 체인에서 단 1개의 utxo 블록 공간을 사용하여 여러 사용자가 참여하는 계정 잔액 변경을 구성할 수 있습니다.
출처: https://twitter.com/OwenKemeys/status/1741575353716326835
그리고 나뭇잎 중 하나가 라이트닝 채널, 콜드 스토리지, 기타 결제 경로라면 어떨까요? 그런 다음 이 트리는 1차원 및 다단계 지출 트리에서 다차원 및 다단계 지출 트리로 확장되며, 지원할 수 있는 시나리오는 더 풍부하고 유연해집니다.
출처: https://twitter.com/OwenKemeys/status/1744181234417140076
CTV가 제안된 이후 2019년 COSHV에서 이름 변경을 거쳐 2020년 BIP-119로 지정되었으며 22, 23년에는 CTV 계약 지원을 위해 프로그래밍 언어 Sapio로 등장하여 많은 논의를 받았습니다. 활성화 계획에 대한 논쟁은 여전히 커뮤니티에서 가장 많이 논의되는 소프트 포크 업그레이드 제안 중 하나입니다.
OP_CAT
처음에 소개한 것처럼 OP_CAT도 현재 많은 관심을 받고 있는 업그레이드 제안입니다. 그것이 구현하는 기능은 스택의 두 요소를 연결(concatenante)하는 것입니다. 간단해 보이지만 OP_CAT은 스크립트에서 많은 기능을 구현하는 데 매우 유연할 수 있습니다.
가장 직접적인 예는 머클 트리와 관련된 작업입니다. 머클 트리는 두 요소가 먼저 접합된 후 해싱되는 것으로 이해될 수 있습니다. 현재 비트코인 스크립트에는 OP_SHA 256과 같은 해시 연산 코드가 있으므로 OP_CAT을 사용하여 두 요소를 연결할 수 있다면 머클 트리의 검증 기능을 스크립트에서 구현할 수 있으며 특정 클라이언트에 대한 라이트 클라이언트 검증도 가능합니다. 정도.
추가 구현 기반에는 Schnorr 서명에 대한 개선 사항도 포함됩니다. 스크립트의 지출 서명 조건은 사용자의 공개 키와 공개 nonce의 연결로 설정될 수 있으며, 서명자가 다른 거래에 서명하려는 경우 자금이 다른 곳에서 지출됩니다. 동일한 nonce를 사용하여 개인 키가 유출되도록 합니다. 즉, OP_CAT을 통해 nonce에 대한 커밋이 실현되어 서명된 트랜잭션의 유효성이 보장됩니다.
OP_CAT의 다른 애플리케이션 시나리오에는 Bistream, 트리 서명, 양자 방지 Lamport 서명, Vault 등이 포함됩니다.
OP_CAT 자체는 새로운 기능이 아니지만 비트코인의 초기 버전에는 존재했지만 공격에 악용될 수 있기 때문에 2010년에 비활성화되었습니다. 예를 들어 OP_DUP 및 OP_CAT을 재사용하면 해당 스크립트를 처리할 때 전체 노드가 스택을 쉽게 폭발시킬 수 있습니다.
그런데 지금 OP_CAT을 다시 활성화하면 위에서 언급한 스택 폭발 문제가 발생하지 않을까요? 현재 OP_CAT 제안은 탭스크립트에서만 활성화하는 것과 관련되어 있고 탭스크립트는 각 스택 요소를 520바이트 이하로 제한하므로 이전 스택 폭발 문제는 발생하지 않습니다. 나카모토 사토시가 OP_CAT을 직접 금지한 것이 너무 가혹하다고 생각하는 개발자도 있습니다. 그러나 OP_CAT의 유연성으로 인해 취약점을 일으킬 수 있는 일부 애플리케이션 시나리오는 현재 소진될 수 없습니다.
따라서 적용 시나리오와 잠재적 위험을 고려하여 OP_CAT은 최근 많은 관심을 받았으며 현재 가장 인기 있는 업그레이드 제안 중 하나입니다.
결론
자기 규율은 자유를 가져옵니다. 위의 소개에서 볼 수 있듯이 비트코인 스크립트에서 제한 조항을 직접 구현하여 추가 거래 지출을 제한함으로써 스마트 계약 효과와 유사한 거래 규칙을 달성할 수 있습니다. BitVM과 같은 오프체인 방법과 비교하여 이 프로그래밍 방법은 비트코인에서 더 기본적으로 검증될 수 있으며 메인 체인의 애플리케이션(혼잡 제어), 오프체인 애플리케이션(상태 채널) 및 기타 새로운 애플리케이션 방향을 개선할 수도 있습니다( 스테이킹 페널티 등).
제한 조항의 구현 기술이 일부 기본 업그레이드와 결합될 수 있다면 프로그래밍 가능성의 잠재력이 더욱 발휘될 것입니다. 예를 들어, 최근 검토 중인 64비트 연산자 제안은 제안된 OP_TLUV 또는 트랜잭션의 사토시 출력 수에 따라 프로그래밍할 수 있는 기타 제한 사항과 추가로 결합될 수 있습니다.
그러나 제한적인 용어는 계획되지 않은 남용이나 허점을 초래할 수도 있으므로 커뮤니티에서는 이에 대해 더욱 주의를 기울이고 있습니다. 또한 제한 조항을 업그레이드하려면 합의 규칙의 소프트 포크 업그레이드도 필요합니다. 탭루트 업그레이드 중 상황으로 인해 제한 사항과 관련된 업그레이드도 완료하는 데 시간이 걸릴 수 있습니다.
이 기사를 검토하고 제안해 준 Ajian, Fisher, Ben에게 감사드립니다!
참고자료
https://utxos.org/
성약과 관련된 자료 모음:
https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
https://anyprevout.xyz/
BIP 345: OP_VAULT 제안: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf
https://maltemoeser.de/paper/covenants.pdf
https://bitcoinops.org/en/topics/op_cat/
OP_CAT:
https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
CAT 및 Schnorr 트릭: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
