BIP 110

두 노드 운영자가 같은 블록을 받았다고 생각해 보세요. 한쪽은 기존 규칙에 따라 받아들이지만, 다른 쪽은 새로운 제한 때문에 거부합니다. BIP 110이 바꾸려던 것은 이 수준입니다. 거래를 전달하거나 미확인 결제의 로컬 대기 공간인 mempool에 보관할지뿐 아니라, 블록 자체의 유효성을 바꾸려 했습니다. 2026-10-23 확인 당시 명세 버전 1.0.1의 상태는 Closed, 즉 종료였습니다. BIP 번호를 받거나 프로그램을 공개했다고 네트워크가 채택한 것은 아닙니다. 제안 등록부는 문서와 이력을 보존하며 각 노드의 규칙을 원격으로 바꾸지 않습니다. [1] [2]

새 거래 출력에는 나중에 자금을 쓸 조건을 정하는 스크립트인 scriptPubKey가 있습니다. 제안은 최대 34바이트를 허용하되, 출력이 사용 불가능함을 증명할 수 있게 만드는 명령 OP_RETURN으로 시작하면 83바이트까지 허용했습니다. 스크립트 전체를 셉니다. 별도의 256바이트 한도는 개별 OP_PUSHDATA* 데이터와 witness의 인수 항목에 적용됩니다. Witness는 지출 검증에 첨부하는 정보입니다. BIP16의 scriptSig에 공개된 지출 조건 스크립트인 redeemScript를 넣는 경우는 예외입니다. Witness scripts와 Tapleaf scripts 자체는 해당 인수가 아니지만, 그 안에서 데이터를 넣는 명령은 여전히 제한됩니다. 특정 부분의 한도이지 거래 전체나 witness 전체 길이의 한도가 아닙니다. [1]

제안은 지출 조건을 표현하는 방식인 Taproot에도 영향을 줬습니다. 정의되지 않은 witness나 Tapleaf 버전의 출력을 쓰는 것은 금지하지만, 그런 출력을 만드는 것은 금지하지 않았습니다. 추가 필드인 annex와 257바이트가 넘는 control block도 금지 대상입니다. Control block은 스크립트가 미리 약정한 구조에 속한다는 증명으로, 그 길이가 제한되는 것입니다. Tapscript에는 실행하지 않는 코드라도 OP_SUCCESS*가 없어야 하며, 조건 결과와 무관하게 OP_IF나 OP_NOTIF를 실행할 수 없습니다. 기술적으로 대조할 정의된 형식은 P2WPKH, P2WSH, Tapleaf 버전 0xc0의 P2TR, 프로그램 0x4e73의 P2A이며 마지막 형식은 witness 스택이 비어 있어야 합니다. 이는 정확한 형식 이름이지 일반 사용자가 지갑에 입력해야 하는 항목이 아닙니다. [1]

UTXO는 아직 쓰지 않은 출력입니다. 특정 금액에 그것을 쓸 조건이 붙어 있습니다. 제안은 활성화 전에 확인된 UTXO를 쓰는 입력에 새 규칙의 예외를 둡니다. 하지만 같은 거래에서 만드는 새 출력까지 자유롭게 허용하지는 않습니다. 미리 서명했더라도 출력이 활성 기간에 생성된다면 보호받지 못합니다. 일부 사전 서명된 Taproot 구조에 대해서는, 제한으로 예정된 지출 경로가 무효가 되고 쓸 수 있는 다른 경로가 없으면 자금 동결이나 손실이 가능하다고 명세가 인정합니다. 지출 조건을 구성하는 도구인 Miniscript와 계산 검증 구조인 BitVM에 미치는 영향도 문제입니다. 따라서 화폐와 무관한 데이터만 영향을 받는다고 약속할 수 없습니다. [1] [3]

채굴자는 블록에 지지 신호를 넣을 수 있습니다. 여기서는 bit 4를 쓰고 2016개 블록 중 1109개, 약 55퍼센트를 기준으로 삼았습니다. 그러나 자발적인 신호만 요구한 것은 아닙니다. 기준을 먼저 충족하지 못하면 높이 961632–963647에서 신호를 의무화하고, 963648부터 LOCKED_IN, 965664부터 ACTIVE로 전환하도록 했습니다. 해당 체인이 그 높이에 도달한다는 전제입니다. 높이는 체인에서 블록의 위치입니다. LOCKED_IN은 전환이 확정된 상태, ACTIVE는 데이터 제한을 실제 적용하는 상태입니다. 클라이언트는 의무 신호 기간부터 신호 없는 블록을 거부하므로, 데이터 제한이 시작되기 전에 노드가 갈라질 수 있습니다. 제한은 실제 활성화 후 52416개 블록 동안 유지되고 EXPIRED로 전환해 끝나도록 설계됐으며, 정확한 달력상의 일 년을 뜻하지 않습니다. [1] [4]

지지자들은 노드 운영 비용, UTXO 집합의 부담, 원치 않는 콘텐츠를 줄이고 결제에 초점을 맞추려 했습니다. 이는 동기의 설명이지 효과의 증명은 아닙니다. 비판자들은 유용한 스크립트와 향후 확장에 미치는 영향, 네트워크 분열 위험을 지적했습니다. 데이터를 작은 조각으로 나누는 것도 가능합니다. 초기 토론에서 Peter Todd는 당시 제안 전체를 그런 방식으로 담은 거래를 제시했습니다. 명세조차 다른 데이터 속에 정보를 숨기는 스테가노그래피를 완전히 없앤다고 약속하지 않습니다. 저장 비용을 높이는 것과 저장을 완전히 막는 것은 다릅니다. 마찬가지로 콘텐츠에 대한 법적 책임을 걱정한다고 특정 법적 의무가 입증되는 것은 아닙니다. [1] [3]

PR 2247 기록은 2026-08-08 높이 961632에서 일어난 분열을 설명합니다. 주 체인에는 필요한 신호가 없는 블록이 있었고, OCEAN은 신호가 있는 대체 블록을 채굴했습니다. 2026-08-09 Murch는 소수 체인이 2개 블록만 만든 뒤 멈췄지만 주 체인은 100개 넘는 블록을 진행했다고 보고했습니다. 이 보고는 날짜와 작성자를 함께 읽어야 합니다. 이 글을 위해 블록체인을 독립적으로 재검증한 결과도, 소수 체인의 현재 상태에 대한 설명도 아닙니다. 신호 요구로 인한 분열을 ACTIVE 도달이나 데이터 제한의 실제 시작과 혼동하면 안 되는 이유도 보여 줍니다. [5] [6]

문서는 명세 완성을 뜻하는 Complete를 거쳐 Closed로 끝났습니다. 종료를 위한 PR 2245는 2026-08-10 병합됐고, 명세 변경 기록은 2026-08-09로 표시합니다. 서로 다른 기록의 날짜이지 또 다른 활성화가 아닙니다. 클라이언트 버전 v0.4.1은 EXPIRED와 vbrequired를 설명합니다. 후자는 블록 템플릿에서 필수 신호 비트를 나타내는 필드입니다. 그 클라이언트가 존재한다고 Bitcoin Core가 채택한 것은 아닙니다. 예상 결과가 붙은 예제 거래인 test vectors와 기능 테스트도 있지만, 이 글은 실행하지 않으며 현재 소수 체인도 검증하지 않습니다. 목적은 제안과 기록된 경과를 이해하는 것이지, 역사적 문서를 오늘날 네트워크의 공통 규칙으로 소개하는 것이 아닙니다. [7] [1] [4]