10만 바이트의 백지수표: 비트코인 코어 v30과 낫츠(Knots)의 OP_RETURN 내전

1. 83바이트의 휴전

수년간 비트코인 코어 기본 정책은 단일 OP_RETURN 출력에 최대 83바이트를 담은 트랜잭션을 중계·채굴 대상으로 삼았다. OP_RETURN은 첨부 데이터를 증명 가능하게 사용할 수 없는 상태로 표시하는 opcode다. 이 상한과 단일 출력 규칙은 표준성 기본값이지 블록 유효성 규칙이 아니었다.^[1][11]

이 규칙은 합의(consensus)가 아니었다. 코어 문서에 따르면 멤풀과 릴레이 정책은 미확인 트랜잭션에 적용되는 로컬·설정 가능 규칙이며 블록 내 트랜잭션에는 적용되지 않는다. 한 노드가 비표준으로 거부해도 채굴자가 포함할 수 있고, 중계 수용이 내용의 승인을 뜻하지도 않는다.^[8]

데이터 정책 분쟁은 2025년 이전부터 이어졌다. #32406 스레드는 병합되지 않은 과거 인스크립션 필터링 제안을 언급했다. 2025년 4월 bitcoin-dev 메일링 리스트에서 기본 OP_RETURN 한도의 증액 또는 삭제 논쟁이 다시 열렸다.^[3][10]

2. 메일링 리스트를 가득 채운 격론

스레드가 방대해지자 비트코인 옵테크는 2025년 5월 2일 뉴스레터에서 전체 요약 대신 찬반 양측에서 가장 설득력 있다고 본 논거를 하나씩 소개했다.^[10]

한도 해제를 지지한 피터르 우일러(Pieter Wuille)는 자금력 있는 조직이 채굴자에게 직접 보내는 데이터 트랜잭션을 표준성 정책으로 막기 어렵다고 주장했다. 또한 데이터 포함 여부와 무관하게 블록은 대개 가득 차므로 노드가 보관할 전체 데이터양은 실질적으로 같다고 보았다.^[10]

반대 측의 제이슨 휴스(Jason Hughes)는 한도를 늘리면 풀 노드에 임의의 데이터를 저장하기 쉬워지며, 노드 암호화 여부와 무관하게 대부분의 관할권에서 불법인 정보를 포함해 유해한 데이터가 저장될 위험이 커진다고 경고했다.^[10]

2025년 4월 27일 피터 토드(Peter Todd)는 PR #32359를 발의해 한도와 -datacarrier 옵션의 완전 삭제를 제안했다. 그는 MARA의 슬립스트림(Slipstream) 같은 채굴자 직접 제출과 리브레 릴레이(Libre Relay) 같은 비필터링 포크로 인해 이미 제한이 무력화되었다고 주장했다. 이 PR은 5월 12일 미병합 종료되었다.^[9]

3. Concept NACK: 폭발하는 저장소

2025년 5월 2일 코어 기여자 그레고리 샌더스(Gregory Sanders, instagibbs)는 PR #32406을 열었다. 최대 트랜잭션 크기에 맞먹는 10만 바이트의 OP_RETURN을 허용하도록 기본 -datacarriersize를 올리고 다중 출력을 허용하며, -datacarrier 옵션은 사용 중단(deprecated) 상태로 남기는 안이었다.^[3][11]

리뷰 스레드에는 Concept ACK와 NACK이 이어졌다. 메인테이너는 동기가 아닌 아이디어를 비판하고 패치에 집중하라는 관리 가이드라인을 환기했다. 가장 날카로운 반대는 비트코인 낫츠 메인테이너 루크 대시주니어에게서 나왔다.^[3][5]

Concept NACK(개념 반대). 이미 여러 PR에서 다룬 내용이다. 중요하지 않은 사소한 차이점으로 도배한다고 해서 이 개념의 근본적인 광기와 악의가 바뀌지는 않는다.^[5]

— Luke Dashjr

샌더스는 기존 제한이 필수 보호 장치라는 주장을 일축했다. 데이터 캐리어 제한이 P2P 및 멤풀 계층을 보호하기 위해 존재한다는 주장에 그는 단호히 답했다.^[4]

전혀 사실이 아니다. 이 규칙의 유일한 동기는 피할 수 있을 때 온체인에 임의의 데이터를 저장하지 않도록 사람들을 유도(nudge)하는 것뿐이다.^[4]

— Gregory Sanders

4. 두 개의 클라이언트, 정반대의 기본값

PR #32406은 2025년 6월 9일 병합되었다. 옵테크에 따르면 기본 -datacarriersize 설정은 83바이트에서 10만 바이트로 상향되었고, 단일 출력 제한이 풀려 한도가 모든 출력의 합산에 적용되었으며, -datacarrier 옵션은 향후 제거 예정인 지원 중단 상태로 남았다.^[3][11]

2025년 10월 13일 배포된 비트코인 코어 30.0은 이 변경을 공식화했다. 릴리스 노트는 기본값이 10만 바이트로 늘어 사실상 한도가 풀렸고 -datacarriersize=83으로 이전 설정을 복원할 수 있다고 안내했다. 또한 다중 데이터 출력이 릴레이 및 채굴에 허용된다고 밝혔다.^[1][2]

인용한 비트코인 낫츠 v28.1 코드는 이미 반대 방향의 기본값을 갖고 있었다. 정책 헤더는 OP_RETURN을 42바이트(데이터 40바이트+opcode)로 제한하고 알려진 데이터 운반 방식을 합산하도록 했다. 초기화 코드는 추가 멤풀 가중치용 -datacarriercost와 -datacarriersize=83 등을 설정하는 -corepolicy 스위치를 제공했다.^[12][7]

두 클라이언트는 합의를 바꾸지 않은 채 서로 다른 로컬 정책을 제공했다. 더 넓은 삭제안을 냈다가 종료된 피터 토드는 반대자들에게 대체 구현이 있다고 말했다.^[3][6]

여기서 우리는 비트코인 코어에 적극적으로 기여하는 합리적인 개발자들 사이에서 이번 변경이 좋은 아이디어라는 훌륭한 합의를 이루었다. 둘째로, 여전히 이 변경에 동의하지 않는 이들은 Knots와 같은 대체 포크를 자유롭게 실행하면 된다.^[6]

— Peter Todd

5. 아무도 승리할 수 없는 전쟁

이 분쟁에서도 합의 규칙은 바뀌지 않았다. 릴레이 정책은 미확인 트랜잭션에만 적용되는 로컬 설정이어서 한 노드가 비표준으로 거부해도 채굴자가 수용하면 유효하게 블록에 기록되었다. 릴레이 수용이 데이터 승인을 뜻하지 않으며 멤풀은 원장이 아닌 임시 대기소일 뿐이다.^[1][8]

'스팸'과 '검열'이라는 규정도 논쟁상의 주장에 불과했다. 옵테크는 판정 대신 양측 논거를 병기했으며, MARA 슬립스트림 같은 채굴자 직접 제출 경로는 자금력 있는 송신자에게 기본 릴레이 정책이 넘을 수 없는 벽이 아님을 보여주었다.^[9][10]

분쟁은 서로 다른 기본값을 남겼다. 참여자들은 코어에서 낫츠로의 이전을 주장했지만 스레드에는 확정 통계가 없었다. 인용한 버전은 코어 30.0의 10만 바이트와 낫츠 v28.1의 42바이트를 제시했고, 운영자는 실행할 소프트웨어와 설정으로 선호를 표현할 수 있었다.^[3][12]