확인

앨리스가 친구에게 20 000 sat를 보냅니다. sat는 비트코인의 최소 단위입니다. 지갑에는 전송됨이 표시되고 친구도 들어오는 결제를 보지만, 확인 수는 영입니다. 모순이 아닙니다. 비트코인을 검증하는 컴퓨터인 노드들 사이에 결제 정보는 퍼졌지만 아직 블록에 들어가지 않았습니다. Mempool은 각 노드가 미확인 거래를 보관하는 곳이지, 네트워크 전체의 단일 대기열이 아닙니다. 결제가 채택된 블록에 들어가면 첫 확인을 얻습니다. 다음 블록은 두 번째, 그다음은 세 번째 확인을 줍니다. 앨리스가 다시 보낼 필요는 없습니다. 거래를 전파하거나 식별자 txid를 얻었다고 확인이 보장되지는 않습니다. 미확인 거래는 수수료를 높이는 Replace-by-Fee(RBF) 등으로 교체될 수 있습니다. 확인 없이 결제를 받아들이는 zero-conf는 같은 자금을 쓰는 다른 거래가 대신 확인될 위험을 감수한다는 뜻입니다. [4] [8] [11]

채굴자는 새 블록에 넣을 거래를 고르고, 비트코인 규칙이 요구하는 비용이 드는 계산의 결과인 유효한 Proof of Work를 찾습니다. 다른 풀 노드는 그 블록을 직접 검증합니다. 서명, 금액, 사용 조건이 맞는지, 자금이 이미 쓰이지 않았는지 확인합니다. 채굴자 투표도, 한 회사의 승인 도장도 아닙니다. 채굴자가 무효인 결제를 블록에 넣는다고 유효해지지는 않습니다. 노드는 자신이 채택한 체인에서만 거래를 확인된 것으로 셉니다. 유효한 분기 가운데 chainwork라는 누적 작업량이 가장 큰 것을 선택합니다. 각 블록은 이전 블록을 가리키므로 옛 기록을 바꾸려면 그 뒤도 다시 만들어야 합니다. [2] [7]

비트코인은 블록 사이 평균 십 분을 목표로 할 뿐 시간표대로 움직이지 않습니다. 새 블록은 몇 초 뒤나 훨씬 나중에 나올 수 있습니다. 한 시간을 기다렸다고 자동으로 여섯 번 확인되는 것은 아닙니다. 높은 수수료율은 채굴자가 거래를 고를 가능성을 높일 수 있지만 블록 생성은 앞당기지 못합니다. 지갑에 따라 미확인 거래를 더 높은 수수료의 거래로 바꾸는 RBF, 또는 후속 거래가 충분한 수수료를 더해 부모 거래와 함께 채굴할 유인을 만드는 CPFP (Child Pays for Parent)를 쓸 수 있습니다. 가능 여부는 지갑과 거래에 달려 있습니다. 수수료가 낮으면 오래 기다리거나 노드의 Mempool에서 빠질 수 있습니다. 지갑의 예상 시간은 예측으로 받아들이고 약속된 기한으로 보지 마세요. [3] [4]

받는 사람이나 서비스가 결제를 인정하기 전에 몇 번 확인할지 정합니다. 소액 구매와 돌이킬 수 없이 고가 상품을 넘기는 경우는 감수할 위험이 다릅니다. 거래소가 여러 확인을 기다린다면 거래가 이미 블록체인에 있어도 계정 잔액은 아직 늘지 않을 수 있습니다. 반드시 결제 오류인 것은 아닙니다. 자기 지갑에서 금액, 목적지, 상태를 확인하고 서비스의 입금 반영 조건도 살펴보세요. 정보 출처도 중요합니다. 공격자가 노드를 고립시켜 제한된 네트워크 모습만 보여 주는 것을 Eclipse Attack이라고 합니다. 적절한 기다림은 금액, 수습 가능성, 상대방에 대한 신뢰, 검증 방법에 달려 있습니다. 확인 수만으로 키 도난을 막을 수는 없습니다. [11] [13]

결제를 기록한 페이지 위로 역사의 새 페이지가 쌓인다고 생각해 보세요. 공격자는 옛 한 페이지만 바꿔서는 안 되고, 충분한 누적 작업량을 가진 별도의 유효한 뒷부분도 만들어야 합니다. 일반적인 가정에서는 확인이 늘수록 어려워집니다. 하지만 공격자의 계산 능력과 네트워크 상태도 결과에 영향을 줍니다. 흔히 말하는 여섯 번의 확인은 역사적인 지침이지, 합의 규칙이나 완전한 안전의 마법 같은 경계가 아닙니다. 모든 상황의 기록 변경 확률을 하나의 고정 수치로 설명할 수는 없습니다. 확인이 많아져도 잘못된 주소나 사기꾼에게 보낸 돈이 바로잡히지는 않습니다. [1] [13]

두 채굴자가 거의 동시에 블록을 찾으면 공격 없이도 잠시 분기할 수 있습니다. 노드가 다른 승리한 분기로 옮기는 것을 재구성이라고 합니다. 거래 출력은 금액과 사용 조건을 기록하고, 나중 거래의 입력은 그 출력을 가리켜 사용합니다. 아직 쓰지 않은 출력을 UTXO라고 합니다. 경쟁하는 유효한 분기가 더 많은 누적 작업량, 즉 chainwork를 쌓으면 노드는 원래 체인의 끝부분 블록을 분리하고 승리한 분기를 연결합니다. 분리된 블록에 있던 거래가 여전히 유효하다면 Mempool로 돌아갈 수 있고, 다른 높이에서 확인될 수도 있습니다. 새 분기가 그 거래의 입력이 가리키는 동일한 출력을 이미 사용했다면 충돌 거래가 될 수도 있습니다. Bitcoin Core에서 confirmations의 음수 값은 지갑이 충돌 깊이를 나타내는 방식입니다. 합의 규칙에서 블록 개수가 음수가 된다는 뜻은 아닙니다. [5] [7]

블록 높이는 번호 영인 최초 블록부터 센 순서입니다. 거래가 포함된 블록의 높이가 h이고 노드 활성 체인의 마지막 블록 높이가 H라면, 확인 횟수는 H − h + 1입니다. 거래를 담은 블록 자체를 첫 확인으로 셉니다. 결과는 해당 노드가 검증한 최선의 블록을 기준으로 하므로, 새 블록이 도착할 때 노드 사이에서 잠시 다를 수 있습니다. 이 값은 거래의 일부가 아니며, 시간만 흐른다고 늘어나지 않고, 타임스탬프만으로 정확히 구할 수도 없습니다. Bitcoin Core는 해당 지갑이나 UTXO 조회 상태가 알고 있는 정보에 따라 blockhash, blockheight, confirmations 같은 데이터를 반환합니다. [3] [5] [6]

SPV는 간이 결제 검증이고 RPC는 노드에 질의하는 프로그래밍 인터페이스입니다. 두 앱이 같은 확인 수를 표시해도 검증 방법의 차이는 중요합니다. 풀 노드는 체인을 검증하고, 자신이 검증한 체인의 현재 끝을 기준으로 답합니다. SPV 클라이언트는 블록 헤더의 Proof of Work와 거래 포함 여부를 증명하는 Merkle 증명을 확인하지만, 모든 합의 규칙을 직접 검증하지는 않습니다. Merkle 증명은 소수의 암호학적 데이터 지문으로 거래가 블록에 포함되었음을 보여 줍니다. 그 블록의 모든 거래를 내려받을 필요는 없습니다. 사용자를 대신해 자금을 보관하는 서비스는 별도의 입금 반영 규칙과 위험 관리 규칙도 적용합니다. 풀 노드가 반환한 RPC 결과조차 특정 시점의 상태를 담고 있으며, 재구성이 일어나면 달라질 수 있습니다. 따라서 확인 횟수뿐 아니라 누구의 체인 관측, 검증, 자금 보관을 신뢰하는지도 중요합니다. [1] [2] [8]

Coinbase Transaction은 채굴자에게 보상을 주는 블록의 특별한 첫 거래이며 Coinbase 거래소와는 관계없습니다. 시간 잠금은 자금을 쓸 수 있는 시점을 제한합니다. BIP는 기술 제안이나 표준 문서입니다. 확인은 프로토콜의 일부 대기 기간을 시작하기도 합니다. coinbase 거래의 출력에는 COINBASE_MATURITY = 100 규칙이 적용됩니다. 가장 일찍 사용할 수 있는 블록은 그 coinbase 거래를 담은 블록보다 높이가 100 큰 블록입니다. 이는 블록 보상을 쓰기 전에 반드시 기다려야 하는 기간이며, 일반 결제의 수취인이 선택하는 기준이 아닙니다. BIP68 상대 시간 잠금은 사용하려는 출력의 확인을 기준으로 삼고, 블록 수 또는 시간에 관한 규칙에 따라 경과 정도를 평가합니다. 스크립트는 출력을 사용하기 위한 조건을 정하는 짧은 프로그램입니다. BIP112의 CHECKSEQUENCEVERIFY(CSV) 명령은 스크립트에서 이 상대적 조건을 강제할 수 있게 합니다. 미확인 출력을 사용하는 거래는 그 출력을 만든 거래에 계속 의존합니다. 후속 거래가 확인되려면 선행 거래들이 같은 블록이나 이전 블록에 포함되어야 합니다. [9] [10]

Lightning Network는 비트코인 거래로 자금을 넣은 채널을 통해 결제합니다. BOLT는 그 기술 규격의 이름입니다. 여기서는 채널 개설을 다루며, 채널 안의 모든 결제가 블록을 기다려야 한다는 뜻은 아닙니다. BOLT 2는 Lightning 채널을 받아들이는 쪽이 channel_ready 메시지를 보내기 전에 자금 조달 거래에 필요한 확인 횟수를 minimum_depth 필드로 정할 수 있도록 합니다. 이 요구에는 자금 조달의 이중 지불 위험이 반영됩니다. 확인 없이 여는 채널인 zero-conf channel은 minimum_depth를 영으로 설정하고, 자금 제공자에 대한 신뢰와 프로토콜 제한에 의도적으로 의존합니다. 그 결과 즉각적이고 되돌릴 수 없는 정산을 얻는 것은 아닙니다. 자금 조달 거래 자체가 coinbase 거래라면, BOLT 2는 채널을 개설하는 쪽이 아닌 상대방에게 최소 100개 블록을 기다리도록 요구합니다. 운영자는 특정 자금 조달 출력인 funding outpoint, 활성 체인에서의 깊이, 재구성을 감시해야 합니다. txid를 전파했다는 사실만으로 채널이 열린 것은 아닙니다. [12] [14]