원격 노드 vs 자체 노드: 지갑은 무엇을 흘리는가 (2026 실측)

두 질문이 하나로 섞이면서 잘못된 조언이 나옵니다. 첫째, 지갑이 연결된 서버가 당신의 행동을 볼 수 있는가. 둘째, 블록체인이 당신이 누구인지 기록하는가. 2026년 10월 27일 18:00 UTC에 우리는 첫 번째를 직접 측정했습니다. 공개 모네로 노드 node.monerodevs.org:18089와 xmr-node.cakewallet.com:18081은 같은 tip 해시 c0268f79, 같은 높이 3,793,455를 보고했고 8개 읽기 전용 메서드에는 응답하고 9개에는 JSON-RPC -32601 Method not found를 돌려줬습니다. 이 결과 하나가 어떤 프라이버시 구호보다 많이 설명합니다.

모든 RPC 호출은 남의 디스크에 남는 한 줄의 로그입니다. IP, 메서드 이름, 인자, 타임스탬프. 측정에서 통과한 것은 get_info, get_version, get_block_count, get_block, get_last_block_header, get_block_headers_range, get_fee_estimate, get_output_histogram. 거부된 것은 get_peer_list, get_connections, get_net_stats, get_transaction_pool, get_transaction_pool_hashes, get_transactions, get_outs, get_coinbase_tx_sum, send_raw_transaction. 제한 모드는 메서드를 숨길 뿐 아니라 필드를 0으로 지웁니다. 이것 자체가 좋은 단서입니다. get_info는 restricted true, 입출력 연결 수 0, alt_blocks 0, start_time 0, free_space 18,446,744,073,709,551,615(2^64-1), version 빈 문자열을 반환했습니다. 소스에서도 각 필드가 restricted ? 0 : 값으로 처리됩니다. (모네로 수수료 메커니즘)

지갑은 노드에 잔고를 묻지 않습니다. 블록을 요청해 내려받고 자기 기계에서 view key로 복호화합니다. 그래서 노드 선택과 키 보관은 별개 문제입니다. 헤더만 주는 공개 엔드포인트로 동기화가 끝나지 않는 이유도 여기 있습니다. 높이 3,793,455 블록은 272,341바이트, 38건으로 보고됐지만 get_block이 준 blob은 1,401바이트, 0.51%로 헤더와 채굴 트랜잭션뿐이었습니다. 1,000개 헤더 범위 요청은 JSON 891,929바이트를 돌려줬습니다. 메인넷 데이터베이스는 295,279,001,600바이트, 275.0 GiB입니다. 이렇게 깎인 엔드포인트로는 동기화가 끝나지 않습니다.

경계는 이렇습니다. 원격 노드가 얻는 것은 IP, 대략의 접속 시간, 요청한 블록 높이, 그리고 broadcast를 받는 엔드포인트라면 txid와 제출한 IP입니다. 얻지 못하는 것은 주소, 잔고, 출력입니다. view key가 없고 체인상 금액은 이미 숨겨져 있기 때문입니다. 실제로 얻는 것은 상관관계입니다. 같은 IP가 새 블록을 반복 요청하면 지갑이고, 18:0x에 거래를 제출한 IP는 그 거래를 만든 사람일 가능성이 큽니다.

자체 노드는 그 경로에서 제3자를 제거합니다. 중계는 자기 데몬이 하고 모네로는 중계를 Dandelion++로 감쌉니다. 상수는 그대로입니다. CRYPTONOTE_DANDELIONPP_STEMS는 2(에포크당 stem 연결 2개), 에포크는 10분±30초, embargo 평균 39초, fluff 확률은 100분의 20. levin_notify.cpp는 100 미만 난수와 이 상수를 비교하므로 다섯 번 중 한 번의 에포크는 stem 없이 즉시 broadcast합니다. 기본 노드는 나가는 연결 12개와 anchor 2개를 유지합니다.

어느 것도 체인에 남는 기록을 바꾸지 않습니다. 내 입력, 교환 사이트가 준 입금 주소, 금액, 시각은 어느 노드가 중계하든 연결된 채로 남습니다. 네트워크 계층도 같습니다. ISP는 모네로 P2P로 향하는 긴 암호화 연결을 계속 봅니다. 그 연결에 대한 트래픽 분석은 RPC 로그와 다른 공격면입니다. 실제로 자체 노드는 IP와 거래의 연결을 낯선 운영자에서 ISP와 거래를 처음 본 피어로 옮길 뿐입니다. 범위는 좁아지지만 비지는 않습니다. 네트워크 계층이 목적이라면 --proxy socks5://127.0.0.1:9050이고 --proxy-allow-dns-leaks의 기본값은 false입니다.

더 나쁜 버전도 볼 가치가 있습니다. 비트코인 electrum.blockstream.info:50002에 인증 없는 TLS 연결 하나를 열자 electrs-esplora 0.4.1, 프로토콜 1.4라고 밝혔습니다. 키도 계정도 핸드셰이크도 필요 없습니다. 주소 하나의 scripthash를 물었더니 67,156건의 이력, 확인된 잔고 5,769,022,283 sat(미확인 3,672), 그리고 갱신을 밀어주는 구독이 돌아왔습니다. 비트코인 경량 지갑은 자기가 가진 주소를 scripthash 단위로 서버에 알려야 합니다. 모네로 원격 노드는 훨씬 좁습니다. 같은 경량 클라이언트라도 넘기는 정보량은 차원이 다릅니다. (모네로 확인 대기)

남의 노드에 지갑을 연결하기 전 여섯 가지 점검. 첫째, get_info의 restricted를 봅니다(true면 남의 공개 엔드포인트). 둘째, Method not found를 버그가 아니라 신호로 봅니다. 공개 엔드포인트가 상태 변경과 해시 조회를 숨기는 방식입니다. 셋째, 신뢰하지 않는 공개 노드로 내 txid를 조회하지 않습니다. IP와 txid를 묶는 유일한 호출입니다. 넷째, 원격으로 broadcast한다면 최초 목격 시각이 남는다고 가정합니다. 다섯째, 데몬을 Tor로 돌린다면 --proxy를 쓰고 --proxy-allow-dns-leaks는 false로 둡니다. 여섯째, 직접 노드를 운영할 때 남에게 제공할 생각이 아니면 --public-node를 켜지 않습니다. (Tor 스왑은 안전한가?)

실제 교환에서 중요한 것은 이렇습니다. 주문은 어느 노드를 쓰는지 묻지 않고 지갑에도 연결하지 않습니다. VeilSwap이 받는 것은 판매 자산, 구매 자산, 수량, 수취 주소, 환불 주소이고 입금 주소는 주문마다 생성됩니다. 노드 선택이 바꾸는 것은 내 IP가 인프라에 무엇을 드러내는가이고 주문이 드러내는 것이 아닙니다. 나머지는 산수입니다. 2026년 10월 27일 18:0x UTC 기준 100/500/1,000/5,000 USDT-TRC20은 0.14632886/0.80265134/1.62303474/8.18504305 XMR, XMR당 683.39/622.94/616.13/610.87달러였습니다. 소액 주문은 고정비로 약 11% 불리합니다. 1 XMR은 581.884075 USDT, 0.05 BTC는 6.60798844 XMR(132.15977 XMR/BTC, BTC 환산 약 79,699달러), 같은 시각 현물은 XMR 599.33, BTC 80,546. 표시가는 움직이므로 페이지가 기준입니다. 같은 시간대 1,534바이트 거래는 20,000 piconero/바이트 하한으로 0.00003068 XMR, 약 2센트였습니다. (XMR→USDT 출구 루트)

짧게 정리합니다. 원격 노드는 타임스탬프를 가진 관측자이지 키 보유자가 아닙니다. IP와 활동, IP와 제출을 연결할 수 있지만 금액, 주소, 잔고는 읽지 못합니다. 자체 노드는 그 관측자를 broadcast 경로에서 빼고 같은 상관관계를 ISP에 넘깁니다. Dandelion++는 다섯 에포크 중 네 번 출처를 숨깁니다. 어느 쪽도 체인 기록은 건드리지 않습니다. 새는 것 기준으로 노드를 고르고 남는 것 기준으로 체인을 고르고, 믿기 전에 restricted를 확인하십시오. (모네로 확인 대기)