확인

발송이 확인되지 않습니다. 각 노드는 자신의 멤풀 허용 정책을 독립적으로 적용하며, 시간, 수수료, 충돌, 패키지 제한 또는 설정으로 인해 서로 다른 노드가 서로 다른 세트를 볼 수 있습니다. RBF는 확인되지 않은 거래를 대체할 수 있으며 판매자가 본 결제는 블록에 들어가지 않고 사라질 수 있습니다. 따라서 zero-conf는 이중 지출 위험과 불완전한 네트워크 보기를 위해 속도를 교환합니다. txid나 Explorer 페이지 모두 결제가 아닙니다. [비트코인 개발자 가이드 - 거래] [비트코인 코어 - JSON-RPC 일관성] [BIP 125 - 수수료에 의한 전체 교체 옵트인]

채굴자는 트랜잭션을 후보 블록으로 선택할 수 있지만, 첫 번째 확인은 검증 노드가 블록을 수락하고 블록이 가장 큰 체인워크를 가진 활성 체인에 있는 경우에만 발생합니다. 풀 노드는 작업 증명, 스크립트, 입력, 금액 및 기타 합의 규칙의 존재 및 비지출을 확인합니다. 채굴자는 단순히 상장만으로 유효하지 않은 지출을 상환할 수 없습니다. Merkle 루트는 트랜잭션을 블록에 커밋하고 이전 블록에 대한 참조를 작업 기록 증명에 넣습니다. [비트코인 코어 - 검증] [비트코인 코어 - 유효성 검사.cpp]

트랜잭션 블록의 높이가 h이고 노드의 현재 팁이 H인 경우 개수는 H − h + 1입니다. 블록 자체가 먼저 계산됩니다. 값은 해당 노드의 가장 잘 검증된 블록에 대해 생성되므로 팁은 노드마다 약간 다를 수 있습니다. 이는 트랜잭션에 기록되지 않고 시간이 지나도 증가하지 않으며 타임스탬프에서 안정적으로 확인할 수 없습니다. 비트코인 코어는 블록해시, 블록 높이 및 확인을 지갑 상태 또는 UTXO 보기로 반환합니다. [비트코인 개발자 가이드 - 블록체인] [비트코인 코어 RPC - gettransaction] [비트코인 코어 RPC - getbestblockhash]

경쟁하는 유효한 분기가 더 많은 체인 작업을 얻으면 노드는 이전 팁의 블록을 분리하고 승리하는 분기를 연결합니다. 분리된 블록의 트랜잭션은 유효한 상태로 유지되거나, 다른 높이에서 커밋되거나, 새 분기가 동일한 입력을 사용했기 때문에 충돌이 발생하는 경우 mempool로 반환될 수 있습니다. 비트코인 코어의 부정적인 확인은 합의의 부정적인 블록이 아니라 충돌 깊이에 대한 지갑 규칙입니다. [비트코인 코어 RPC - gettransaction] [비트코인 코어 - 유효성 검사.cpp]

추가 확인은 거래에 대한 작업 증명을 추가하므로 일반적으로 비용이 더 많이 들고 기록을 다시 작성할 가능성이 낮습니다. 그들은 결정론적인 최종성을 생성하지 않습니다. 백서의 추격 계산과 이후 모델은 모두 공격자의 해시 비율, 정직한 네트워크의 행동 및 수신자의 관찰에 따라 달라집니다. "6가지 확인"은 합의 상수나 보편적인 안전 한계가 아닌 역사적 장치입니다. 원칙적으로는 여전히 심층적인 재구성이 가능합니다. [비트코인 백서 - 작업 증명 및 계산] [Rosenfeld - 해시레이트 기반 이중 지출 분석]

개수는 거래 자체가 아닌 수신자, 교환기 또는 다운스트림 프로토콜에 의해 필요합니다. 커피, 고가상품 미반환 발행, 거래소 예금, 채널 개설 등은 손실율과 대기율이 다릅니다. 정책은 가치, 성과의 가역성, 공격자의 동기 및 해시 비율, 충돌 또는 RBF, 보관 및 백엔드, Eclipse 위험 및 체인의 비정상적인 상태를 고려해야 합니다. 확인은 체인을 덮어쓸 위험을 완화합니다. 도난당한 키, 잘못된 주소 또는 상대방 사기를 수정하지 않습니다. [BIP 125 - 수수료로 전체 교체 옵트인] [Rosenfeld - 해시레이트 기반 이중 지출 분석]

비트코인은 블록 간 평균 약 10분을 목표로 하지만 작업 증명 도착은 무작위입니다. 다음 블록은 몇 초 또는 몇 시간 안에 도착할 수 있습니다. 수수료가 높을수록 채굴자 선택 순서와 RBF 또는 CPFP 패키지 경제가 향상될 수 있지만, 고정된 시간을 구매하는 데 수수료가 없고 블록 생성 속도가 빨라지지 않습니다. 저렴한 트랜잭션은 많은 블록을 기다리거나 멤풀에서 제거될 수 있습니다. 추정치는 기한이 아니라 확률입니다. [비트코인 개발자 가이드 - 블록체인] [비트코인 개발자 가이드 - 거래]

전체 노드는 문자열의 유효성을 검사하고 자체 활성 팁에 따라 응답합니다. SPV 클라이언트는 헤더의 작업 증명과 Merkle 증명 포함을 확인하지만 모든 합의 규칙 자체를 실행하지는 않습니다. 관리 서비스는 또한 자체 신용 및 위험 정책을 추가합니다. 전체 노드의 RPC 결과도 Reorg에 의해 변경될 수 있는 스냅샷입니다. 따라서 문제는 "얼마나 많은 확인을 받았는지"뿐만 아니라 사용자가 누구의 체인 뷰, 검증 및 보관을 신뢰하는지입니다. [비트코인 백서 - 작업 증명 및 계산] [비트코인 코어 - 검증] [비트코인 코어 - JSON-RPC 일관성]

다른 수업도 확인으로 시작됩니다. 코인베이스 출력에는 COINBASE_MATURITY = 100이 적용되며 100개의 새 블록 이후에만 사용할 수 있습니다. 이는 일반 결제 정책과는 다른 규칙입니다. BIP112 CHECKSEQUENCEVERIFY(CSV) 스크립트에 의해 시행되는 BIP68 상대 시간 잠금은 출력 커밋 블록의 기간을 측정합니다. 확인되지 않은 부모는 자손을 종속되게 유지합니다. 하위 항목이 어설션되려면 해당 상위 항목이 동일하거나 이전 블록에 있어야 합니다. [비트코인 코어 - 합의.h] [BIP 112 - CHECKSEQUENCEVERIFY]

BOLT 2를 사용하면 Lightning 채널 수신기가 채널 준비 이전에 최소 심도 자금 거래를 선택할 수 있습니다. 숫자는 이중 지출 위험 자금 조달을 중요하게 생각합니다. zero-conf 채널은 최소 깊이를 0으로 설정하고 즉각적인 최종성보다는 자금 신뢰 및 프로토콜 제약 조건에 의식적으로 의존합니다. Coinbase 자금 조달은 입학 대기 중입니다. 운영자는 자금 조달 지점, 활성 체인의 깊이 및 재구성을 모니터링해야 하며 전송된 txid를 공개 채널로 간주하지 않아야 합니다. [BOLT 2 - 피어 프로토콜] [Bitcoin Optech - Zero-conf 채널]