MSG_FILTERED_WITNESS_BLOCK

MSG_FILTERED_WITNESS_BLOCK는 인벤토리 코드 0x40000003으로, 2016년에 세그윗의 피어 규칙이 작성될 때 예약되었고 구현은 주어진 적이 없습니다. Bitcoin Core는 이를 enum 항목으로 담고 있으며, 주석에 바로 그 사실이 기록되어 있습니다. 이 유형이 확장했을 라이트 지갑 기능인 BIP37 블룸 필터링은 Bitcoin Core 0.19.0에서 기본값으로 꺼졌으며, 이는 휴대폰 지갑이 아직 이에 의존하는 경우에만 관련이 있습니다.

작동 방식

상태: 예약되었고 구현된 적이 없습니다. BIP144가 이 유형의 이름을 붙였고, Bitcoin Core는 src/protocol.h에서 처리기가 존재하지 않는다는 주석과 함께 enum 항목으로 담고 있습니다. 이 유형이 처리했을 BIP37 필터링은 2019년 11월 Bitcoin Core 0.19.0부터 기본값으로 비활성화되었고, BIP157과 BIP158 컴팩트 블록 필터가 그 대체물입니다.

이 간극을 이해하려면 필터링된 블록이 무엇이었는지 이해해야 합니다. BIP37을 사용하는 라이트 클라이언트는 관심 있는 주소를 대략적으로 기술하는 filterload 메시지를 보냅니다. 그런 다음 인벤토리 유형 3, 즉 MSG_FILTERED_BLOCK를 요청하고, 응답하는 노드는 merkleblock 메시지로 답합니다. 여기에는 80바이트 블록 헤더, 트랜잭션 수, 부분 머클 가지, 그리고 트리를 어느 방향으로 순회할지 알려주는 비트필드가 들어 있습니다. 일치하는 트랜잭션은 별도 메시지로 이어서 전송됩니다. 클라이언트는 각 트랜잭션이 실제로 헤더의 머클 루트에 연결되는지 확인하며, 이 확인은 txid만으로 수행합니다.

위트니스는 그 계산에 전혀 들어가지 않았습니다. 머클 루트가 txid로 구성되므로 라이트 클라이언트는 서명 하나 없이 포함을 증명할 수 있고, 따라서 후속 트랜잭션은 위트니스를 제거한 채 전송되었습니다. 위트니스 플래그가 추가된 예약 유형 3, 0x40000003은 클라이언트가 그러한 트랜잭션을 전체 형태로 요청할 수 있게 했을 것입니다. 아무도 이를 구현하지 않았는데, 라이트 지갑을 만드는 사람 중 BIP37을 더 원한 사람이 없었기 때문입니다.

그 이유는 노력이 아니라 프라이버시입니다. 클라이언트가 업로드하는 필터는 응답 노드에게 어떤 주소가 자신의 것인지 대략적으로 알려주며, 2010년대 중반까지의 연구는 그러한 필터가 의도한 것보다 훨씬 많은 정보를 누설한다는 것을 보여주었습니다. Bitcoin Core의 대응은 설계를 고치는 대신 기본적으로 이를 제공하지 않는 것이었습니다. BIP158은 대신 흐름을 뒤집습니다. 노드는 블록마다 하나의 작은 Golomb 부호화 필터를 만들어 784,931분의 1의 거짓 양성 비율에 맞추고 이를 공개합니다. 클라이언트는 필터를 내려받아 로컬에서 검사하고, 적중이 있을 때만 블록 전체를 가져오므로 서버는 어떤 주소에 관심이 있었는지 전혀 알지 못합니다.

확인할 수 있는 곳

거의 어디에서도 볼 수 없으며, 이는 참고 표에서 MSG_FILTERED_WITNESS_BLOCK를 발견한 사람에게 정직한 답입니다.

Bitcoin Core에서 이 상수를 grep해 보면 enum 멤버 하나만 나옵니다. btcd 같은 대체 구현은 완전성을 위해 wire 패키지에서 이름을 그대로 옮겨 두었지만, 역시 그 뒤에 동작은 없습니다. 어떤 지갑도 이를 보낸 적이 없습니다.

이 주제가 구매자와 실제로 닿는 지점은 모바일 지갑이 데이터를 얻는 방식입니다. 지갑이 스스로를 SPV라고 설명하고 블룸 필터로 무작위 공개 노드에 연결한다면, 그 지갑은 참조 구현이 수년 전부터 기본적으로 제공하지 않게 된 메커니즘을 사용하는 것이며, 그 노드들에게 사용자의 주소에 관한 정보를 알려주는 것입니다. lnd의 Neutrino 뒤에 있는 설계인 컴팩트 블록 필터 기반 지갑은 훨씬 적은 정보를 요청합니다. 지갑 제공업체의 자체 서버를 향하는 지갑이 세 번째 선택지이자 가장 흔한 경우입니다. 빠르고, 낯선 이로부터는 프라이버시가 지켜지고, 제공업체에게는 완전히 노출됩니다.

MSG_FILTERED_WITNESS_BLOCK vs 머클 블록

머클 블록은 응답이고, MSG_FILTERED_WITNESS_BLOCK는 그것을 생성하도록 연결된 적이 없는 요청입니다. merkleblock 메시지는 블록을 전송하지 않고도 트랜잭션 집합이 특정 블록에 속함을 증명하는, 실제로 구현된 구조입니다. 예약된 위트니스 변형은 그 증명 뒤에 오는 것, 즉 일치하는 트랜잭션이 서명과 함께 도착하는지만 바꿨을 것입니다. 포함 증명은 txid로 작동하므로, 빠진 기능으로 인해 누구도 손해를 보지 않았습니다.