이중 지불

톰이 이전에 받은 100 000 sat짜리 출력 하나를 가지고 있다고 합시다. sat는 비트코인의 최소 단위이고, 아직 쓰지 않은 출력은 UTXO라고 합니다. 톰은 앨리스에게 99 000 sat를 보내고 1 000 sat를 수수료로 남기는 결제를 준비합니다. 하지만 같은 UTXO를 쓰면서 다른 곳으로 돈을 보내는 거래에도 서명할 수 있습니다. 두 거래는 같은 자금에 의존하므로 충돌합니다. 파일을 복사하는 것과는 다릅니다. 규칙을 검증하는 컴퓨터인 Bitcoin 노드는 하나의 유효한 체인에서 같은 출력을 두 번 쓰도록 허용하지 않습니다. 앨리스가 첫 결제를 믿고 상품을 넘겼는데 채택된 기록에는 두 번째 거래가 남는다면 사기는 성공합니다. 새 코인이 생긴 것이 아니라 앨리스가 패한 버전을 믿었던 것입니다. 기술적으로 각 입력은 이전 거래의 식별자인 txid와 출력 번호로 특정 출력을 가리킵니다. 이 둘을 합쳐 outpoint라고 합니다. [1] [3] [7]

앨리스는 몇 초 만에 입금을 볼 수 있습니다. 그렇다고 블록에 기록되었다는 뜻은 아닙니다. Mempool은 각 노드가 미확인 거래를 보관하는 곳입니다. 전 세계가 공유하는 하나의 Mempool이나 공통된 도착 순서는 없습니다. 다른 노드는 충돌하는 버전을 먼저 받았거나 앨리스의 버전을 아직 못 봤을 수 있습니다. first-seen 정책은 거래를 중계할 때 먼저 받은 버전을 우선합니다. 채굴자가 그 버전을 블록에 넣겠다는 약속은 아닙니다. 따라서 지갑 화면 캡처나 txid만으로 정산을 입증할 수는 없습니다. 신뢰할 수 있게 검증된 체인에서 그 결제가 어떤 상태인지가 중요합니다. [2] [5]

반대로 앨리스가 정상적인 결제를 보냈는데 오래 기다리는 상황일 수도 있습니다. Replace-by-Fee(RBF)는 미확인 거래를 다른 거래로 바꾸는 기능이며, 보통 수수료를 높일 때 씁니다. txid가 바뀌어도 수취인은 같은 금액을 받을 수 있습니다. 대체 거래는 적어도 일부 같은 자금을 쓰므로 원래 거래와 기술적으로 충돌하지만, 누군가 수취인을 속이려는 것은 아닐 수 있습니다. RBF 표시 자체보다 새 결제의 내용과 상황을 봐야 합니다. 다만 같은 방식으로 돈을 다른 곳으로 돌릴 수도 있습니다. Bitcoin Core는 버전 28부터 Full-RBF를 기본 정책으로 사용하며, 원래 거래가 대체 가능성을 표시하지 않아도 됩니다. 대체 거래는 여전히 노드의 수수료 및 남용 방지 규칙을 따라야 합니다. 따라서 RBF 표시가 없는 미확인 결제도 되돌릴 수 없는 결제가 되지는 않습니다. [5] [6] [15]

결제가 노드가 받아들인 유효한 블록에 들어가면 확인을 얻습니다. 이후 블록이 쌓일수록 보통 기록을 바꾸기가 어려워지고 사기 성공 위험이 줄어듭니다. 하지만 모든 상황에 안전한 확인 횟수는 없습니다. 커피값을 잃는 것과 자동차를 넘기거나 거래소의 큰 출금을 승인하는 것은 손실 규모가 다릅니다. 흔히 말하는 여섯 번의 확인은 관행이지 Bitcoin 규칙이 아닙니다. 금액, 피해를 복구할 방법, 체인의 이상 징후, 정보원의 신뢰도를 고려해야 합니다. 노드를 고립시키는 Eclipse Attack은 그 노드가 보는 네트워크를 왜곡할 수 있습니다. 기다림은 검증과 함께해야 하며, 검증을 대신하지 않습니다. [2] [10]

노드가 다른 유효한 분기로 이동하는 것을 재구성이라고 합니다. Proof of Work는 블록 생성에 필요한 작업을 입증하며, 한 분기의 누적 작업량을 chainwork라고 합니다. 결제가 확인되고 나면 Mempool 안에서 거래를 대체하는 방식으로 취소할 수 없습니다. 다른 유효한 분기가 원래 결제를 제외하고 두 번째 지출을 포함한 뒤, 수취인의 활성 체인보다 더 많은 누적 작업량, 즉 chainwork를 쌓아야 합니다. 거의 동시에 채굴된 블록이나 소프트웨어 또는 네트워크 오류처럼, 사기 없이도 체인 재구성은 일어날 수 있습니다. 충돌 거래의 승리 덕분에 공격자가 가치를 얻었을 때에만 피해자에 대한 이중 지불이 성공했다고 합니다. Bitcoin Core는 지갑에서 패배한 거래의 confirmations 필드에 음수 확인 횟수를 표시하고, walletconflicts 필드에 관련 충돌을 표시할 수 있습니다. [4] [7] [8]

Hashrate는 채굴 계산의 속도입니다. 비중이 크면 기록을 둘러싼 경쟁에 유리하지만 다른 규칙의 예외가 되지는 않습니다. 비공개로 채굴한 분기가 정직하게 채굴된 체인을 따라잡을 확률은 공격자가 차지하는 전체 네트워크 연산 능력의 비중과 확인 횟수 등에 달려 있습니다. 얻을 수 있는 가치는 주로 공격이 경제적으로 이득인지에 영향을 줍니다. 비중이 50 % 미만이라고 성공 가능성이 없는 것은 아닙니다. 지속적으로 과반을 유지하면 다른 분기를 따라잡을 가능성이 크게 높아집니다. 그러나 과반을 확보해도 채굴자가 서명을 위조하거나, 타인의 UTXO를 쓰거나, 발행 규칙을 어기거나, 풀 노드가 무효한 블록을 받아들이도록 강제할 수는 없습니다. 공격을 평가할 때는 연산 능력과 에너지뿐 아니라 정직한 채굴을 했다면 받을 수 있었던 보상도 고려해야 합니다. 동원할 수 있는 자금, 실패 위험, 발각 가능성도 중요합니다. 이익에는 금융시장 포지션에서 얻는 수익도 포함될 수 있으므로, 채굴 장비 임대료만으로는 이를 추정하기 어렵습니다. [1] [10] [12]

여기서 race는 시간 경쟁을 뜻합니다. 수취인과 채굴자는 서로 다른 거래를 먼저 볼 수 있습니다. race attack은 결제 수락과 거래 확인 사이에서 먼저 목적을 달성하려는 경쟁 공격입니다. 지급자는 한 거래를 판매자에게 보내고, 충돌하는 거래를 채굴자나 다른 노드에 보냅니다. 블록이 한쪽을 선택하기 전에 판매자가 되돌릴 수 없는 방식으로 상품을 넘기도록 유도합니다. 결과는 거래 전파, 판매자가 보는 네트워크 상황, 채굴자의 선택, 상품 인도 시점에 달려 있습니다. 여러 독립 노드로 네트워크를 감시하면 충돌을 더 잘 발견할 수 있지만, 되돌릴 수 없는 정산을 보장하지는 않습니다. race, Finney, Vector76이라는 이름은 공격 시나리오를 가리키며, 거래 데이터 필드나 서로 다른 합의 규칙을 뜻하지 않습니다. [2] [11]

Finney attack은 공격자가 결제뿐 아니라 채굴 능력도 가진 상황의 이름입니다. 지갑의 일반적인 수수료 인상과는 다릅니다. Finney attack에서는 채굴 능력이 있는 공격자가 먼저 자금을 자신에게 돌려주는 충돌 거래를 담은 블록을 비공개로 채굴합니다. 이어 같은 UTXO로 미확인 결제를 받아 주는 판매자에게 대금을 보내고, 상품을 받은 다음 숨겨 두었던 블록을 공개합니다. 이 계획은 해당 블록이 여전히 사용 가능한 상태이고, 정직하게 채굴된 경쟁 블록이 준비를 무산시키기 전에 네트워크가 그 블록을 받아들여야만 성공합니다. 따라서 공격자는 블록 보상과 채굴 비용을 잃을 위험을 감수합니다. 판매자의 거래가 검증된 블록에 들어갈 때까지 기다리면 이 고전적인 공격 절차는 막을 수 있지만, 이후 체인이 재구성될 위험까지 없어지지는 않습니다. [1] [11]

RPC는 노드의 프로그래밍 인터페이스입니다. 아래 이름들은 결제 시스템 개발자를 위한 명령과 필드이지 또 다른 확인 방식이 아닙니다. 판매자의 시스템은 자체 풀 노드로 Mempool의 충돌 지출을 감시하고, gettxspendingprevout를 호출하고, walletconflicts 필드를 읽고, 활성 체인의 최신 블록을 비교하며, 확인이 사라지면 알림을 보낼 수 있습니다. 연결된 노드나 독립 노드가 많아지면 사각지대는 줄어듭니다. 하지만 충돌을 발견하지 못했다는 것은 안전을 뒷받침하는 약한 근거에 불과합니다. 공격자가 충돌 거래를 공개하지 않거나 다른 경로로 보낼 수 있기 때문입니다. 블록 탐색기도 자신의 노드에서 보이는 상황을 보여 주며 지연될 수 있습니다. 충돌을 발견하면 상품 인도를 중단할 수 있습니다. 그러나 채굴자에게 어떤 거래를 선택하라고 명령하거나, 미확인 결제를 확인된 결제와 동등하게 만들 수는 없습니다. [8] [9] [11]

실제 입금 거래의 목적지, 금액, 확인 횟수를 확인하세요. 송금자가 제시하는 영수증으로 대신할 수는 없습니다. 자신의 풀 노드로는 규칙을 직접 검증할 수 있습니다. 다른 서비스를 쓴다면 누구의 정보와 자금 보관에 의존하는지 이해해야 합니다. 상점 시스템은 주문을 특정 출력과 연결하고 대체 거래도 추적해야 합니다. 충돌이나 확인 상실이 있으면 되돌릴 수 없는 상품 인도를 멈춰야 합니다. 미확인 잔돈을 쓰는 다음 결제도 원래 거래에 의존하므로, 그 안전성을 독립적으로 증명하지 않습니다. Lightning Network는 Bitcoin 거래로 자금을 넣은 채널을 통해 빠른 결제를 제공합니다. 채널 참여자는 자금 배분을 기록한 서명된 commitment 거래를 교환합니다. 채널을 갱신할 때는 나중에 오래된 상태를 공개하면 상대방이 벌칙을 적용할 수 있도록 비밀 정보를 넘깁니다. 이렇게 이전 상태를 무효화하는 방식을 revocation이라고 합니다. 보호를 받으려면 그런 시도를 제때 발견하고 대응해야 합니다. 미확인 온체인 송금을 보고 상품을 넘기는 것과는 다른 방식입니다. 확인 없이 여는 zero-conf channel은 자금 제공자를 의도적으로 신뢰하며, 그 자금이 이중 지불될 위험을 없애지는 않습니다. [13] [14]