교환 분쟁 증거: 다섯 개의 시계 중 무엇이 기준인가
한 번의 교환에서 다섯 개의 시계가 동시에 돕니다. 브라우저, 저희 서버, 상류의 가격 잠금, 채굴자가 쓰는 블록 헤더, 풀의 장부. 2026년 11월 6일 각 시계의 오차를 측정했습니다. 결정하는 것은 마지막 하나뿐입니다.
교환 분쟁은 시계 싸움이고, 인용되는 시계는 대개 틀렸습니다. 9월 24일부터 오늘 06:05 UTC까지 주문 장부에는 151건이 쌓였습니다 — 만료 123, 완료 21, 실패 5, 환불 2 — 입금 주소는 142개였습니다. 그중 마감 시각이 저장된 것은 23건뿐이고 나머지 128건은 없어서 사이트 내부 30분 규칙을 따랐습니다. 이 비율이 '제때 보냈다'는 논쟁의 대부분을 설명합니다. 여섯 건 중 다섯 건은 상류 마감이 없고, 있는 경우에도 30분이 아니라 10분입니다.
첫 번째 시계는 눈에 보이는 것이고, 당신 기기의 것입니다. 주문 페이지는 서버에 남은 시간을 묻지 않습니다. 서버가 준 마감에서 당신 브라우저의 `Date.now()`를 1초마다 빼고, 상태는 5초마다 폴링합니다. 계산은 정확하지만 입력은 아닙니다. 5분 빠른 휴대폰은 5분을 더 보여주고, 5분 느린 노트북은 5분을 덜 보여주며, 페이지는 어느 쪽이 맞는지 알 방법이 없습니다. 그래서 카운트다운 스크린숏은 거의 아무것도 증명하지 못합니다. 시간에 대한 의견을 기록한 것이고, 그 의견을 낸 기기가 바로 주장하는 기기입니다.
두 번째 시계는 저희 것이고, 당신 앞에 내놓을 수 있는 유일한 것입니다. 주문은 밀리초로 저장되며, 06:04:44 UTC에 오리진 서버의 시스템 시계는 Cloudflare의 `Date` 헤더와 같은 초 안에 일치했습니다. 기준이 흔들리지 않는다는 뜻입니다. 마감이 저장된 23건 중 ChangeNOW 13건은 생성에서 마감까지 599.4~599.9초(중앙값 599.9), FixedFloat 10건은 중앙값 599.1초였습니다. 서로 무관한 두 풀이 같은 10분을 냅니다. 덮지 않고 짚어야 할 예외가 하나 있습니다. 어떤 FixedFloat 주문은 마감이 생성 시각과 밀리초까지 같았고, 즉 0초 창이었는데도 `waiting_deposit` 상태로 2,402.7초를 머물렀습니다. 누군가 그 주문을 읽기 전에는 상태를 다시 쓰는 것이 없기 때문입니다.
세 번째 시계는 가격 잠금이고, 주문보다 짧습니다. 06:06 UTC에 100 USDT-TRC20→XMR 견적의 `validUntil`은 119.8초 뒤였습니다. 같은 엔드포인트가 200, 500, 1,000, 2,000, 5,000 USDT에서는 `validUntil: null`을 돌려줬습니다. 더 짧은 잠금이 아니라 잠금이 없는 것입니다. 견적 라우트는 서버에서 8초 캐시하므로 그 사이 두 번 누르면 같은 숫자가 나오는 것이 정상입니다. 세 상수를 함께 읽으면 이렇습니다. 화면의 가격은 2분 뒤 만료되고, 그것으로 만든 주문에는 10분 입금 창이 있으며, 약 130 USDT를 넘으면 상류 가격 약속이 아예 없고 버튼을 누른 순간의 재견적만 있습니다. (XMR→USDT 출구 루트)
네 번째 시계는 체인이고, 당신의 시간을 따르지 않습니다. 블록 타임스탬프는 그 블록을 캔 사람이 쓰고, 제약은 합의 규칙 두 개뿐입니다. 비트코인은 직전 11개 블록 중앙값보다 뒤, 노드 시계보다 2시간 이내. 라이트코인도 같은 2시간. Zcash는 더 엄격해 중앙값보다 90분, 로컬 시계 대비 2시간. 모네로는 최근 60개 블록 중앙값보다 2시간 앞까지 허용합니다. 06:05~06:06 UTC 실측에서 비트코인 최신 블록은 이미 1,866초 '낡았고', 그 시각은 11블록 중앙값보다 3,436.8초 위였으며 15블록 간격 중앙값은 441.5초였습니다. 라이트코인 선단은 623초 전이고 중앙값 여유는 424.5초, Zcash 최신 블록은 840초 전, 모네로 선단은 109초 전이지만 60블록 중앙값보다 3,847초 위였습니다. 블록 시각은 코인이 실제로 움직인 순간과 한 시간 떨어질 수 있습니다. (Zcash vs 모네로 2026 비교)
다섯 번째 시계는 풀의 장부이고, 결정하는 것은 이것뿐입니다. 입금을 계상할 때 상류는 자기 도착 시각을 씁니다. 당신의 스크린숏도, 블록 헤더도, 저희 행도 아닙니다. 만료 123건 중 90건이 `local_timeout`인 이유가 이것입니다. 저희 창이 끝나 닫은 것이고 상류는 만료라고 말한 적이 없습니다. 반대도 성립합니다. 11월 3일 09:28:17 UTC에 생성된 완료 주문은 마지막 기록이 자체 마감보다 259초 뒤였는데도 paid로 끝났고, 같은 날 아침 환불 주문은 생성에서 refunded까지 약 40초였습니다. '늦었다'는 상류의 판단이지 산수가 아닙니다. 당신이 통제하는 입력은 브로드캐스트 순간 하나뿐입니다.
다툼이 예상되면 네 가지를 남기십시오. 첫째, 전송 순간 자신의 지갑에서 복사한 txid와 지갑 자체의 타임스탬프. 끝에서 끝까지 당신이 소유한 유일한 시계입니다. 둘째, 그 거래가 담긴 블록 높이와 그 블록의 시각. 도착 시점을 한 시간 이내로 위치시킬 수 있습니다. 다만 주문 API는 마감만 반환하고 생성 시각은 절대 반환하지 않으므로 창의 시작은 당신이 기록해야 합니다. 셋째, 주문 생성 당시 화면 그대로의 주문 ID와 입금 주소. 넷째, 마감 자체가 쟁점이라면 스크린숏이 아니라 화면 녹화입니다. 상태 폴링마다 상류의 `validUntil`을 다시 읽어 저장값을 덮어쓰기 때문에 화면의 숫자가 처음 본 숫자라고 보장할 수 없습니다.
다섯 가지 규칙과, 공학으로 없앨 수 없는 경계 하나. 주문 생성 후 1분 안에 입금 주소와 마감이 같은 화면에 있을 때 캡처하십시오. txid는 주문 ID와 같은 메시지로 지원팀에 보내십시오(답장을 기다렸다가 보내면 늦습니다). 자신의 브로드캐스트에 시각을 붙이는 지갑을 쓰십시오. '06:09에 보낸 기억이 있다'는 증거가 아닙니다. 블록 시각은 초가 아니라 한 시간 정밀도로 다루십시오. 견적에 마감이 붙지 않는 금액이라면 견적과 주문 사이에 가격이 움직인다고 전제하십시오. 가격의 사실이지 시계의 사실이 아닙니다. 경계는 이렇습니다. 풀이 언제 입금을 계상했는지 알려주는 공개 출처는 없습니다. 저희는 `created_at`, `valid_until`, 만료 기록 시각, 블록을 보여줄 수 있지만 상류의 내부 시각은 상류의 것이고, 실제 다툼에서 모두가 싸우는 숫자가 그것입니다. 이 글의 스냅샷: 06:02 UTC 기준 436개 자산·64개 네트워크, XMR 617.74달러, 100 USDT-TRC20은 0.14208343 XMR(1 XMR=703.8달러, 잠금 금리 구간), 1 XMR은 612.143 USDT. 가격은 매분 움직이지만 시계의 구조는 움직이지 않습니다. (XMR→USDT 출구 루트)