갈등은 합의 이전에도 관찰될 수 있지만 성공적인 이중 지출은 피해자가 한 거래에 가치를 지출하고 다른 거래가 수신된 체인에서 승리할 때만 발생합니다. 따라서 교체된 지갑 결제, 의도하지 않은 수수료 인상 또는 실패한 충돌은 자동으로 사기가 아닙니다. Zero-conf 경쟁과 커밋된 블록 덮어쓰기는 비용과 위험이 근본적으로 다릅니다.
각 입력은 txid와 인덱스를 사용하여 이전 출력을 참조합니다. 하나 이상의 입력이 사용되지 않은 동일한 아웃포인트를 참조하지만 동시에 지불할 수 없는 경우 두 트랜잭션이 충돌합니다. 블록을 검증할 때 노드는 입력이 존재하는지, 주어진 기록의 이전 부분이나 동일한 블록의 다른 곳에서 사용되지 않았는지 확인합니다. 유효한 UTXO 세트에는 하나의 분기만 남아 있습니다. 공격은 사토시의 복사본을 생성하지 않으며, 수신자가 손실을 입은 지점에서 행동하도록 시도합니다. [비트코인 백서 - 트랜잭션, 타임스탬프 서버 및 계산] [비트코인 개발자 가이드 - 트랜잭션] [비트코인 코어 - 유효성 검사.cpp]
채굴 전에는 커밋되지 않은 거래에 대한 글로벌 멤풀이나 합의 순서가 없습니다. 피어는 먼저 프로모션, 토폴로지, 수수료 정책, 패키지 상태 또는 Eclipse 격리로 인한 다양한 충돌을 확인할 수 있습니다. 처음 보는 것은 릴레이 정책이지 첫 번째 옵션을 확인해야 하는 채굴자의 의무는 아닙니다. 판매자의 백엔드에 있는 txid는 서명된 후보 한 명이 도착했다는 것만 증명할 뿐 전체 네트워크가 이를 보았거나 블록을 획득했다는 것을 증명하지는 않습니다. [비트코인 개발자 가이드 - 결제 처리] [비트코인 코어 - 멤풀 교체]
수수료로 교체를 통해 노드는 수수료 및 DoS 방지 규칙을 충족하는 멤풀 충돌을 교체할 수 있습니다. 전체 RBF는 버전 28부터 비트코인 코어의 기본 정책이었습니다. 발신자는 정체된 결제 수수료를 합법적으로 늘리고 수신자의 출력을 보존하거나 값을 리디렉션할 수 있습니다. 두 경우 모두 합의는 공통 후보를 확인하고 유효한 마이닝 기록의 변형을 받아들입니다. RBF 신호, 교체 또는 범프만으로는 사기가 입증되지 않습니다. 신호가 없는 트랜잭션은 다시 zero-conf에 안전하지 않습니다. [비트코인 코어 - 멤풀 교체] [BIP 125 - 수수료에 의한 전체 교체 옵트인]
경쟁 공격에서 지불인은 하나의 거래를 판매자에게 보내고 충돌은 채굴자나 다른 동료에게 보내므로 판매자는 블록이 하나의 옵션을 선택하기 전에 반품할 수 없는 상품을 발행합니다. 결과는 프로모션, 판매자의 네트워크 보기, 채굴자 선택 및 전송 시간에 따라 달라집니다. 더 독립적인 리스너는 감지 기능을 향상시키지만 결정론적 최종성을 생성하지는 않습니다. Race, Finney 및 Vector76 이름은 트랜잭션 배열이나 다양한 합의 규칙이 아닌 시나리오 모델입니다. [비트코인 개발자 가이드 - 결제 처리] [Karam et al. — 비트코인의 잘못된 행동]
채굴 능력을 갖춘 Finney 스타일의 공격자는 먼저 자신에게 가치를 반환하는 충돌이 포함된 블록을 개인적으로 찾아낸 다음 동일한 UTXO로 상인에게 zero-conf를 지불하고 상품을 받은 후 숨겨진 블록을 게시합니다. 계획은 정직한 경쟁 블록이 준비를 방해하기 전에 블록이 계속 사용 가능하고 네트워크에서 승인된 경우에만 성공합니다. 공격자는 블록 보상과 채굴 비용을 모두 위험에 빠뜨립니다. 판매자의 거래가 확인된 블록에 포함될 때까지 기다리면 클래식 시퀀스가 종료되지만 나중에 재구성될 위험이 제거되지는 않습니다. [비트코인 백서 - 거래, 타임스탬프 서버 및 계산] [Karame et al. — 비트코인의 잘못된 행동]
일단 확인되면 충돌은 더 이상 멤풀 밖으로 지불을 밀어낼 수 없습니다. 대체 유효한 분기는 지불을 건너뛰고 두 번째 지출을 포함해야 하며 수신자의 활성 체인보다 더 많은 체인워크를 얻어야 합니다. 거의 동시적인 블록이나 소프트웨어 또는 네트워크 사고로 인한 사기 없이도 재구성이 발생할 수 있습니다. 피해자에 대한 성공적인 이중 지출은 갈등에서 승리함으로써 가치를 얻는 것입니다. Bitcoin Core는 분실된 지갑 거래에 대해 부정적인 확인 및 지갑 충돌을 표시할 수 있습니다. [비트코인 코어 - 유효성 검사] [비트코인 코어 - 유효성 검사.cpp] [비트코인 코어 RPC - gettransaction]
공격자의 해시레이트 점유율, 확인 깊이, 획득 가능한 가치에 따라 개인적이고 정직한 작업의 확률론적 경쟁이 결정됩니다. 50% 미만이라고 해서 가능성이 전혀 없다는 의미는 아닙니다. 영구 다수는 따라잡을 가능성을 크게 높이지만, 채굴자가 서명을 위조하거나, 해외 UTXO를 사용하거나, 발행량을 초과하거나, 전체 노드가 유효하지 않은 블록을 수락하도록 강제하는 것을 허용하지 않습니다. 비용에는 해시파워, 에너지, 손실된 정직한 보상, 손실 위험, 유동성 및 노출이 포함됩니다. 소득에는 시장 지위도 포함될 수 있으므로 단순한 기계 임대 가격만으로는 충분하지 않습니다. [비트코인 백서 - 거래, 타임스탬프 서버 및 계산] [Rosenfeld - 해시레이트 기반 이중 지출 분석] [Garay, Kiayias 및 Leonardos - 비트코인 백본 프로토콜]
각각의 추가 커밋은 대체 분기가 더 많은 백로그를 다시 실행하도록 강제하고 가정에 따라 성공 가능성을 줄입니다. 보편적인 안전번호는 없습니다. 커피, 자동차, 증권 거래소 예금 및 환불 불가능한 출금은 서로 다른 가치, 동기 및 교정 가능성을 나타냅니다. 자주 인용되는 6가지 확언은 합의가 아니라 관례입니다. 정책은 또한 해시 비율 분포, 비정상적인 재구성, 백엔드에 대한 신뢰, Eclipse 위험 및 핸드오버 가역성을 모니터링해야 합니다. [비트코인 개발자 가이드 - 결제 처리] [Rosenfeld - 해시레이트 기반 이중 지출 분석]
백엔드는 자체 전체 노드에서 충돌하는 mempool 지출을 모니터링하고, gettxspendingprevout를 호출하고, 지갑 충돌을 읽고, 활성 팁을 비교하고, 확인 손실에 대해 경고할 수 있습니다. 더 많은 피어 또는 독립 노드가 사각지대를 줄이지만, 감지된 충돌이 없다는 것은 약한 증거입니다. 공격자가 이를 가로채거나 다른 곳으로 보낼 수 있습니다. Explorer는 사용자 정의 노드 보기를 표시하며 지연될 수 있습니다. 감지하면 분배를 중지할 수 있습니다. 채굴자에게 승리를 지시하거나 zero-conf를 확인으로 전환할 수는 없습니다. [비트코인 코어 RPC — gettransaction] [비트코인 코어 RPC — gettxspendingprevout] [Karame et al. — 비트코인의 잘못된 행동]
온체인 결제의 경우 자체 전체 노드로 검증하고 정확한 txid, 출력 및 금액으로 주문을 바인딩하고 손실 가능성에 따라 깊이를 설정합니다. 재구성 또는 충돌이 발생하는 경우 이행을 중지하고 적립 잔액을 인출 가능 금액에서 분리합니다. 확인되지 않은 변경 하위 항목을 상위 항목과 독립적인 것으로 취급하지 마세요. Lightning은 빠르게 반복되는 결제를 다르게 처리합니다. 확인된 자금 아웃포인트가 채널을 고정하고 약속/해지 규칙이 오프체인 상태를 제어합니다. zero-conf 채널은 자금 제공자를 고의로 신뢰하며 자금 이중 지출 위험을 제거하지 않습니다. [BOLT 2 - 피어 프로토콜] [Bitcoin Optech - Zero-conf 채널]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 트랜잭션, 확인, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. 다음 항목에서도 이 글을 참조합니다 확인, Reorg, Stale Block, Replace-by-Fee (RBF).