해시키 캐피털: '언약' 비트코인의 프로그래밍 가능성

해시키 캐피탈 투자 연구 책임자 제프리 후의 원본 게시글, 해시키 캐피탈 투자 매니저 하퍼 리

최근 비트코인 커뮤니티에서 OP_CAT과 같은 옵코드를 다시 활성화하는 것에 대한 논의가 활발히 진행되고 있습니다. 탭루트 마법사도 퀀텀 캣츠용 NFT를 통해 출시했습니다, 탭루트 위자드는 퀀텀 캣츠의 NFT를 출시하며 BIP-420 번호를 획득했다고 주장하는 등 많은 관심을 끌었습니다. 지지자들은 OP_CAT이 비트코인에 대한 "언약", 스마트 콘트랙트 또는 프로그래밍을 가능하게 한다고 주장했습니다.

'언약'이라는 단어를 발견하고 조금만 검색해보면 이것이 또 다른 큰 토끼굴이라는 것을 알 수 있습니다. 개발자들은 수년 동안 이에 대해 이야기해 왔으며, 제한 조항을 구현하기 위한 OP_CAT 외에도 OP_CTV, APO, OP_VAULT 및 기타 기법들이 있습니다.

그렇다면 비트코인의 '제한 조항'이란 정확히 무엇일까요? 왜 수년 동안 개발자들로부터 많은 관심과 토론을 불러일으켰을까요? 비트코인은 어떤 프로그래밍이 가능한가요? 그 이면의 설계 원칙은 무엇일까요? 이 글은 이에 대한 개요와 논의를 제공하고자 합니다.

"컨벤트란 무엇인가요?"

"계약"으로 번역되기도 하는 컨벤트란 향후 비트코인 거래에 조건을 설정할 수 있는 메커니즘입니다.

현재 비트코인 스크립트에는 지출 시 합법적인 서명 입력, 준수 스크립트 전송 등과 같은 제한 사항도 포함되어 있습니다. 하지만 사용자가 잠금을 해제할 수만 있다면 원하는 곳 어디에서나 UTXO를 사용할 수 있습니다.

반면, 제한 사항에는 UTXO를 잠금 해제하는 방법에 대한 이러한 제한을 넘어 UTXO를 사용한 후 사용할 수 있는 금액 제한, 즉 '할당' 효과 또는 거래에 입력할 수 있는 다른 입력값 제한 등과 같은 추가 제한이 포함됩니다.

제한 사항에는 UTXO를 사용하는 방법에 대한 제한도 포함되어 있습니다.

더 엄밀히 말하면, 현재 비트코인 스크립트에는 트랜잭션의 nLock 또는 nSequence 필드를 내성적으로 검사하여 트랜잭션이 사용될 수 있는 시간을 제한하는 옵코드 기반 시간 잠금과 같은 몇 가지 제한이 있지만 대부분 시간으로 제한되어 있습니다.

그렇다면 개발자와 연구자들이 이러한 제한 검사를 설계하는 이유는 무엇일까요? 제한은 단순히 제한을 위한 제한이 아니라 트랜잭션이 실행되는 규칙을 설정하기 때문입니다. 이렇게 하면 사용자는 미리 정의된 규칙에 따라서만 트랜잭션을 실행할 수 있으므로 의도한 비즈니스 프로세스를 완료할 수 있습니다.

따라서 더 많은 애플리케이션 시나리오를 활용할 수 있다는 것은 직관적이지 않습니다.

적용 시나리오

스테이킹에 대한 페널티 보장

제한 조항의 가장 직관적인 예시 중 하나는 다음과 같습니다. 비트코인 스테이킹 과정에서 바빌론의 슬래시 트랜잭션입니다.

바빌론의 비트코인 스테이킹 프로세스는 사용자가 메인 체인에 있는 BTC 자산을 두 가지 지출 조건이 있는 특수 스크립트로 전송하는 과정을 포함합니다.

• 해피엔딩: 일정 시간이 지나면 사용자가 자신의 서명으로 잠금을 해제할 수 있으며, 즉 스테이킹 해제 프로세스가 완료됩니다

• 나쁜 결말: 사용자가 보안을 위해 Babylon이 임대하는 PoS 체인에 이중 서명한 경우, 자산의 이 부분은 EOTS(추출 가능한 일회용 서명)를 통해 잠금 해제될 수 있으며, 자산의 일부를 강제로 네트워크에 전송할 수 있습니다. 자산의 일부를 소각 주소로 강제 전송하는 실행 역할(슬래시)

출처:비트코인 스테이킹: 2100만 비트코인을 확보하여 증명을 보호하는 -스테이크 경제

여기에서 "강제 전송"에 주목하세요. 즉, UTXO를 잠금 해제할 수 있더라도 자산을 다른 곳으로 보낼 수 없고 소각할 수밖에 없다는 뜻입니다. 이렇게 하면 악의적인 사용자가 자신의 서명을 이용해 자산을 미리 자신에게 다시 전송하여 도주할 수 없게 됩니다.

이 기능은 스테이킹 스크립트의 "나쁜 결말" 브랜치에 OP_CTV와 같은 옵코드를 추가하여 구현할 수 있으며, OP_CTV와 같은 제한을 통해 구현할 수 있습니다.

OP_CTV가 활성화되기 전에는 사용자 + 위원회가 함께 작동하여 제한을 적용하는 효과를 시뮬레이션할 수 있는 해결 방법이 필요했습니다.

혼잡 제어

일반적으로 혼잡이란 비트코인 네트워크의 수수료율이 높고 풀에 대기 중인 거래가 많아서 사용자가 거래를 빨리 확정하고 싶으면 처리 수수료를 인상해야 합니다.

이 시점에서 사용자가 여러 수취인에게 여러 거래를 보내야 하는 경우 수수료를 인상해야 하고 더 많은 비용이 발생합니다. 이는 전체 네트워크의 수수료율도 상승시킵니다.

한 가지 해결책은 제한이 있는 경우 발신자가 먼저 대량으로 전송되는 단일 트랜잭션에 커밋하는 것입니다. 이 약정은 모든 수신자에게 최종 거래가 진행될 것이며 특정 거래를 보내기 전에 수수료율이 낮아질 때까지 기다릴 수 있다는 확신을 줄 수 있습니다.

아래 그림과 같이 블록 공간에 대한 수요가 많으면 트랜잭션 비용이 매우 높아집니다. 대량 결제 처리자는 OP_CHECKTEMPLATEVERIFY를 사용하여 모든 결제를 단일 O(1) 트랜잭션으로 집계하여 확인할 수 있습니다. 그런 다음 일정 시간이 지나 블록 공간의 필요성이 줄어들면 해당 UTXO에서 결제를 확장할 수 있습니다.

출처: https://utxos.org/uses/scaling/

이 시나리오는 이 OP_CTV 단서에서 제시하는 보다 일반적인 사용 사례 중 하나입니다. 더 많은 사용 사례는 https://utxos.org/uses/ 위의 혼잡 제어 외에도 이 페이지에는 소프트 포크 베팅, 탈중앙화 옵션, 드라이브체인, 배치 채널, 비대화형 채널, 무신뢰 조정이 필요 없는 채굴 풀, 볼트, 더 안전한 해시된 시간 고정 콘트랙트(HTLCS) 한도 등이 있습니다.

볼트

볼트는 특히 한도 영역에서 가장 널리 논의되는 비트코인 적용 시나리오 중 하나입니다. 일상적인 작업에는 필연적으로 자금을 안전하게 보관해야 할 필요성과 자금을 사용해야 할 필요성의 균형이 필요하기 때문에, 자금을 안전하게 보관하고 계정이 해킹(개인 키 손상)되더라도 사용을 제한할 수 있는 애플리케이션인 볼트 애플리케이션에 대한 요구가 있습니다.

사용 제한 조항을 구현하는 기술을 기반으로 비교적 쉽게 보관소 앱 클래스를 구축할 수 있습니다.

OP_VAULT의 설계를 예로 들어보자: 볼트에 자금을 사용하려면 먼저 트랜잭션을 체인 위로 전송해야 합니다. 이 트랜잭션은 볼트를 사용하려는 의도, 즉 '트리거'를 나타내며 조건이 설정되어 있습니다.

• 모든 것이 정상이면 두 번째 트랜잭션이 최종 인출을 위한 트랜잭션입니다. N 블록을 기다린 후 자금은 어디에서나 더 사용할 수 있습니다

• 이 거래가 도난당한 것으로 밝혀지면(또는 "스패너 공격" 중에 강제로 이루어진 것으로 밝혀지면) 즉시 다른 보안 주소로 보낼 수 있습니다(사용자가 보관하는 것이 더 안전합니다)

• 이 거래가 도난당한 것으로 밝혀지면(또는 "스패너 공격" 중에 강제로 이루어진 것으로 밝혀지면) 즉시 다른 보안 주소로 보낼 수 있습니다(사용자가 안전하게 안전하게 보관)

OP_VAULT의 프로세스, 출처: BIP-345 

제한 조항 없이 볼트 애플리케이션을 구축할 수 있으며, 이를 위한 한 가지 가능한 방법은 개인 키를 사용하여 나중에 사용할 서명을 준비한 다음 해당 개인 키를 파기하는 것입니다. 그러나 개인키가 파기되었는지 확인해야 하고(영지식 증명의 신뢰 설정 프로세스와 유사), 사전 서명으로 인해 금액과 수수료를 미리 결정할 수 있는 유연성이 부족하다는 등의 한계가 여전히 존재합니다.

OP_VAULT와 사전 서명된 볼트 프로세스 비교, 출처: BIP-345

더 강력하고 유연한 상태 채널

일반적으로 라이트닝 네트워크를 포함한 스테이트 채널은 메인체인과 거의 동일한 수준의 보안을 가지고 있다고 볼 수 있습니다(노드가 최신 상태를 준수하고 최신 상태를 체인에 제대로 게시할 수 있도록 보장한다는 측면에서). 그러나 일부 새로운 상태 채널 설계 아이디어는 라이트닝 네트워크 위에서 더 강력하거나 유연할 수 있다는 단서가 붙습니다. 더 잘 알려진 것들로는 Eltoo, Ark 등이 있습니다.

엘투(LN-Symmetry라고도 함)가 대표적인 예입니다. "L2"라는 단어에서 착안한 이 기술 솔루션은 라이트닝 네트워크에 페널티 메커니즘 없이도 이후 채널 상태가 이전 상태를 대체할 수 있도록 하는 시행 계층을 제안하며, 따라서 라이트닝 네트워크 노드가 적의 악의적인 행위를 방지하기 위해 여러 이전 상태를 저장할 필요도 없게 합니다. 위와 같은 효과를 달성하기 위해 엘투는 SIGHASH_NOINPUT 시그니처인 APO(BIP-118)를 제안합니다.

반면, 아크는 라이트닝 네트워크에서 인바운드 이동성 및 채널 관리의 어려움을 줄이는 것을 목표로 합니다. 여러 사용자가 일정 기간 동안 서비스 제공자를 거래 상대방으로 받아들여 오프체인에서는 가상 UTXO(vUTXO)를 거래하지만, 온체인에서는 하나의 UTXO를 공유하여 비용을 절감할 수 있는 조인풀(joinpool) 형식의 프로토콜입니다. 아크는 볼팅과 유사하게 현재 비트코인 네트워크에서 구현할 수 있지만, 제한을 도입하면 거래 템플릿을 기반으로 필요한 상호작용을 줄여 보다 신뢰할 수 없는 일방적인 출구를 구현할 수 있습니다.

리미테이션 기술 개요

위의 적용 사례에서 볼 수 있듯이 리미테이션은 기술이라기보다 효과에 가깝기 때문에 이를 구현하는 방법은 여러 가지가 있습니다. 분류하면 다음과 같습니다.

• 유형: 일반, 특수

• p style="text-align: 왼쪽;">구현: 옵코드 기반, 서명 기반

• 재귀: 재귀, 비재귀

그리고 무엇보다도 재귀는 다음 거래의 출력을 다음 거래의 출력으로 제한함으로써 다음 거래의 출력도 제한하는 제한의 구현이 있으며, 추가되는 제한은 단일 거래를 넘어 더 깊은 거래로 이어질 수 있다는 것을 의미하기도 합니다.

주류의 제한 조항 설계에는 다음이 포함됩니다:

* 재귀: OP_CAT과 결합한 경우

제한 절의 설계

앞의 소개에서 보셨듯이 현재 비트코인 스크립트는 주로 잠금 해제 조건을 제한하고 있으며, 해당 UTXO의 추가 사용 방법을 제한하지 않습니다. 제한 조항을 구현하려면 반대로 생각해야 합니다. 현재 비트코인 스크립트에서 제한 조항을 구현할 수 없는 이유는 무엇일까요?

주요 이유는 현재 비트코인 스크립트가 트랜잭션 자체, 즉 트랜잭션의 '인트로스펙션'을 읽을 수 없기 때문입니다.

트랜잭션에 대한 인트로스펙션을 구현할 수 있다면, 즉 트랜잭션의 모든 것(출력 포함)을 검사할 수 있다면 제한 조항이 구현될 것입니다.

따라서 제한 조항에 대한 디자인 사고도 인트로스펙션을 구현하는 방법을 중심으로 이루어집니다.

오퍼랜드 기반과 서명 기반

가장 간단하고 조잡한 아이디어는 하나 이상의 옵코드(즉, 하나의 옵코드 + 여러 매개변수 또는 기능이 다른 여러 옵코드)를 추가하여 트랜잭션을 직접 읽어들이는 것입니다. 이것 역시 옵코드의 아이디어를 기반으로 합니다. 이것 역시 옵코드를 기반으로 한 아이디어입니다.

또 다른 생각은 스크립트에서 트랜잭션 자체의 내용을 직접 읽고 확인하는 대신 트랜잭션 내용의 해시를 사용할 수 있다는 것입니다. 이미 서명된 경우 스크립트를 수정하여 OP CHECKSIG 등을 사용하여 이 서명을 검사할 수 있도록 스크립트를 수정하면 트랜잭션 내사 및 제한 조항을 간접적으로 구현할 수 있습니다. 이 아이디어는 서명 설계 접근 방식을 기반으로 합니다. 주요한 것은 APO와 OP_CSFS입니다.

APO

SIGHASH_ANYPREVOUT(APO)는 비트코인 서명 방법 중 하나입니다. 가장 간단한 서명 방법은 트랜잭션의 입력과 출력을 모두 커밋하는 것이지만, 비트코인이 트랜잭션의 입력 또는 출력 중 하나를 선택적으로 커밋하는 더 유연한 방법인 SIGHASH가 있습니다.

SIGHASH와 그 포트폴리오의 거래 입출력에 대한 현재 서명 범위(출처 "마스터링 비트코인, 2 nd"

위 그림과 같이 모든 데이터에 적용되는 ALL 외에도 모든 입력에만 적용되고 출력에는 적용되지 않는 NONE의 서명이 있으며, 이를 기반으로 한 SINGLE은 입력 일련번호가 동일한 출력에만 적용됩니다. 또한, SIGHASH는 ANYONECANPAY 수정자를 겹쳐서 단일 입력에만 적용하도록 결합할 수 있습니다.

반면, APO의 SIGHASH는 입력이 아닌 출력에만 서명합니다. 즉, APO로 서명된 트랜잭션은 기준을 충족하는 모든 UTXO에 첨부할 수 있습니다.

이러한 유연성은 APO가 제한 조항을 구현하는 이론적 근거입니다.

• 하나 이상의 트랜잭션을 미리 생성할 수 있습니다

• 이 트랜잭션의 정보는 하나의 서명만 도출할 수 있는 공개키를 구성하는 데 사용됩니다

• 이 거래의 정보는 하나의 서명만 도출할 수 있는 공개키를 구성하는 데 사용됩니다

. li>

• 이 공개 키 주소로 전송된 모든 자산은 미리 생성된 거래를 통해서만 사용될 수 있습니다

이 공개 키에는 대응하는 개인 키가 없기 때문에, 이 공개 키는 는 이러한 자산이 미리 생성된 트랜잭션을 통해서만 사용될 수 있도록 보장할 수 있습니다. 그런 다음 미리 생성된 트랜잭션에서 자산이 어디로 이동하는지 지정하여 제한 조항을 구현할 수 있습니다.

이를 이더리움의 스마트 콘트랙트와 비교하면 더 이해할 수 있습니다. 스마트 콘트랙트를 통해 달성할 수 있는 것은 EOA 서명을 통해 임의로 돈을 쓰는 것이 아니라 특정 조건이 충족되는 경우에만 계약된 주소에서 돈을 인출할 수 있다는 점입니다. 이러한 의미에서 비트코인은 서명 메커니즘의 개선을 통해 이러한 효과를 달성할 수 있습니다.

그러나 위 프로세스의 문제점은 트랜잭션을 미리 서명하고 생성하려면 입력값을 알아야 하기 때문에 계산에 순환 의존성이 존재한다는 것입니다.

이 서명을 구현한 APO와 SIGHASH_NOINPUT의 중요성은 계산 시 (지정된) 트랜잭션의 전체 출력만 알면 순환 의존성 문제를 해결할 수 있다는 점입니다.

OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV) 또는 BIP-119는 Opcode에 대한 개선된 접근 방식을 취합니다. 이는 커미션 해시를 인수로 사용하며, 옵코드를 실행하는 모든 트랜잭션에 해당 커미션과 일치하는 일련의 출력을 포함하도록 요구합니다. CTV를 사용하면 비트코인 사용자가 비트코인 사용 방식을 제한할 수 있습니다.

이 제안은 원래 OP_CHECKOUTSHASHVERIFY(COSHV)로 소개되었으며, 초기에는 혼잡 제어 거래를 생성하는 기능에 중점을 두었지만, 충분히 일반적이지 않고 혼잡 제어 사용 사례에 너무 구체적이라는 비판도 제기되었습니다.

위에서 언급한 혼잡 제어 사용 사례에서 발신자인 앨리스는 10개의 출력을 생성하고 이 10개의 출력을 해시한 다음 결과 다이제스트를 사용하여 COSHV가 포함된 탭리프 스크립트를 만들 수 있습니다.앨리스는 또한 참가자의 공개 키를 사용하여 탭루트 내부 키를 생성하여 탭루트 스크립트의 경로를 공개하지 않고도 지출에 대해 공동 작업할 수 있습니다.

그런 다음 앨리스는 각 수신자가 앨리스의 설정 트랜잭션을 확인할 수 있도록 10개의 출력물 사본을 모두 제공합니다. 나중에 결제금을 사용하고자 할 때 누구든 약속된 출력물로 트랜잭션을 생성할 수 있습니다.

이 과정에서 앨리스가 설정 트랜잭션을 생성하여 전송하면 이메일이나 클라우드 드라이브와 같은 기존의 비동기 통신 방법을 통해 10개의 출력 사본을 전송할 수 있습니다. 즉, 수신자가 온라인 상태이거나 서로 상호 작용할 필요가 없습니다.

출처: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed- 트랜잭션-출력-약속

APO와 마찬가지로 지출 조건에 따라 주소를 구성할 수 있으며 추가 키, 시간 잠금, 구성 가능한 로직 추가 등 다양한 방식으로 '잠금'을 만들 수 있습니다.

출처: https://twitter.com/OwenKemeys/status/1741575353716326835

CTV는 이를 기반으로 구축합니다. CTV는 해시를 사용한 트랜잭션이 정의된 트랜잭션과 일치하는지 확인하는 기능, 즉 트랜잭션 데이터를 '잠금'을 해제하는 키로 사용하는 기능을 제안함으로써 이를 기반으로 구축됩니다.

위와 같은 10명의 수신자 예시를 확장하면 다음 수신자 주소 배치에 대해 주소 키를 서명했지만 tx를 브로드캐스트하지 않은 상태로 설정할 수 있으며, 다음 다이어그램과 같이 트리 구조를 형성할 수 있습니다. 앨리스는 여러 사용자가 참여하는 계정 잔액 변경을 구성하기 위해 체인에서 1 utxo의 블록 공간만 사용합니다.

출처: https://twitter.com/OwenKemeys/status/1741575353716326835

나뭇잎 중 하나가 번개 채널이고, 콜드 스토리지이며, 다른 결제 경로라면 어떨까요? 그러면 트리가 단일 차원 다층 비용 트리에서 다차원 다층 비용 트리로 확장되고 지원할 수 있는 시나리오가 훨씬 더 풍부하고 유연해질 것입니다.

출처: https://twitter.com/OwenKemeys/status/1744181234417140076

CCTV는 제안 이후 2019년에 COSHV에서 이름이 변경되었고, 2020년에 BIP-119를 배정받았으며, 22년과 23년에 많은 커뮤니티 토론, 업데이트 및 활성화 옵션이 제공된 프로그래밍 언어인 Sapio로 등장했습니다. 사피오는 22년과 23년에 많은 커뮤니티 토론과 업데이트, 활성화 방안에 대한 논쟁이 있었으며, 여전히 커뮤니티에서 가장 많이 논의되는 소프트 포크 업그레이드 제안 중 하나입니다.

OP_CAT

OP_CAT 역시 첫 단락에서 설명한 것처럼 현재 많은 관심을 받고 있는 업그레이드 제안으로, 스택의 두 요소를 연결하는 기능("concatenante")을 구현하고 있습니다. concatenante). 간단해 보이지만 OP_CAT은 매우 유연하며 스크립트에서 구현할 수 있습니다.

가장 직접적인 예는 머클 트리 조작으로, 두 요소를 연결한 다음 해시하는 것으로 해석할 수 있습니다. 현재 비트코인 스크립트에는 해시를 위한 OP_SHA Ā과 같은 op코드가 있으므로 OP_CAT을 사용하여 이를 구현할 수 있다면 다음과 같은 작업을 수행할 수 있습니다. 현재 비트코인 스크립트에는 OP_SHA 256 등의 해시 연산자가 있으므로 OP_CAT을 사용하여 두 요소를 연결할 수 있다면 머클 트리의 검증 기능을 스크립트에서 구현할 수 있고, 어느 정도 라이트 클라이언트를 검증할 수 있는 기능이 생깁니다.

또 다른 구현 기반에는 슈노르 서명에 대한 개선이 포함됩니다. 스크립트의 지출 서명 조건을 사용자의 공개 키와 공개 논스의 연결로 설정한 다음 서명자가 다른 거래에 서명하여 자금을 다른 곳에 사용하려는 경우, 동일한 논스를 사용해야 할 수 있습니다. 서명자가 자금을 다른 곳에 사용하기 위해 다른 트랜잭션에 서명하려면 동일한 논스를 사용해야 하며, 이는 개인 키 공개로 이어집니다. 즉, OP_CAT은 서명된 트랜잭션의 유효성을 보장하기 위해 논스의 헌신을 가능하게 합니다.

OP_CAT의 다른 시나리오로는 비스트림, 트리 서명, 양자 내성 램포트 서명, 볼트 등이 있습니다.

OP_CAT 자체는 새로운 기능이 아니며, 비트코인 초기 버전에 존재했지만 공격에 악용될 가능성이 있어 2010년에 비활성화되었습니다. 예를 들어, 이 데모에서 볼 수 있듯이 OP_DUP과 OP_CAT을 반복적으로 사용하면 이러한 스크립트를 처리할 때 스택에서 전체 노드가 쉽게 폭발할 수 있습니다.

하지만 지금 OP_CAT을 다시 활성화하면 앞서 언급한 스택 폭발 문제가 발생하지 않나요? 현재 OP_CAT 제안은 스택 요소당 520바이트 이하로 제한되는 탭스크립트에서만 활성화하는 것이므로 이전의 스택 폭발 문제를 일으키지 않습니다. 사토시 나카모토가 OP_CAT을 완전히 비활성화하는 것은 너무 가혹하다고 생각하는 개발자들도 있습니다. 그러나 OP_CAT의 유연성 때문에 취약점을 유발할 수 있는 일부 애플리케이션 시나리오를 현재로서는 모두 처리할 수 없는 것이 사실일 수 있습니다.

따라서 적용 시나리오와 잠재적 위험을 고려할 때 OP_CAT은 최근 많은 관심을 받고 있으며, PR 검토를 거쳤고 현재 가장 인기 있는 업그레이드 제안 중 하나입니다.

결론

"자율 규제가 자유로 이어진다"는 말처럼, 위의 소개에서 볼 수 있듯이 비트코인 스크립트에 직접 제한 조항을 구현하여 거래에 대한 추가 지출을 검증하여 스마트 콘트랙트와 유사한 효과를 얻을 수 있습니다. 트랜잭션 규칙. 이 프로그래밍 접근 방식은 BitVM과 같은 오프체인 접근 방식보다 비트코인에서 더 기본적으로 검증할 수 있으며, 메인 체인 애플리케이션(혼잡 제어), 오프체인 애플리케이션(상태 채널링), 기타 새로운 방향의 애플리케이션(스테이킹 페널티 등)을 개선할 수 있습니다.

제약 조건의 구현 기술은 일부 기본 업그레이드와 결합하면 프로그래밍 가능성의 잠재력을 더욱 끌어올릴 수 있습니다. 예를 들어, 최근 검토 중인 64비트 연산자를 위한 제안은 트랜잭션이 출력하는 사토시의 수를 기반으로 프로그래밍할 수 있는 OP_TLUV 또는 기타 제약 조건과 결합될 수 있습니다.

그러나 제한 조항은 의도치 않은 남용이나 취약점으로 이어질 수 있으므로 커뮤니티는 이를 경계하고 있습니다. 또한, 제한 조항을 확대하려면 합의 규칙의 소프트 포크 업그레이드도 수반되어야 합니다. 탭루트 업그레이드를 둘러싼 상황을 고려할 때, 제한 조항과 관련된 업그레이드도 완료하는 데 시간이 걸릴 수 있습니다.

검토와 제안을 해주신 Jian, Fisher, Ben에게 감사드립니다!

참고자료
https://utxos.org/

https://bitcoincovenants.com/

언약과 관련된 자료 모음:

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 및 슈노르 트릭: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298