Finality

거래 위에 추가되는 블록은 기록 대체에 필요한 작업을 늘린다. 보안 판단에는 공격자 자원과 네트워크 상태도 영향을 준다. Finality는 프로토콜이 수학적 불가역 증서를 발급하는 고정 시점이 아니다. [Bitcoin Developer Guide — Block Chain][Bitcoin Developer Guide — Payment Processing]

노드는 먼저 규칙을 검증한 뒤 누적 작업이 가장 많은 유효 체인을 선택한다. 블록 수, 연결 노드 수나 코인 보유자 투표만으로 이 선택을 대체할 수 없다. 많은 작업이 무효 거래를 유효하게 만들지는 않는다. [Bitcoin Developer Guide — Block Chain]

자체 예시: 거래 블록 높이가 800000이고 같은 활성 체인 끝이 800005다. 확인 수는 800005 − 800000 + 1 = 6으로 거래 블록 자체도 포함한다. mempool에만 있으면 0 확인이며 첫 확인이 아니다. [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]

재구성으로 이전 블록이 활성 분기에서 빠질 수 있다. Bitcoin Core 28.0 getblockheader는 그 블록에 confirmations = -1을 표시한다. 모든 지급이 손실됐다는 뜻은 아니다. 거래가 새 분기에 있거나 미확인 또는 충돌 상태일 수 있어 다시 확인해야 한다. [Bitcoin Developer Guide — Block Chain][Bitcoin Core 28.0 — getblockheader]

개발자 가이드는 고가 지급의 일반적 기준으로 6 확인을 들면서 위험 분석도 고려한다. 이는 수취인의 결정이지 합의 규칙 변경이 아니다. 평균 약 한 시간이어도 여섯 블록이 항상 한 시간 안에 생기는 것은 아니다. [Bitcoin Developer Guide — Payment Processing]

PFMI는 최종 결제 시점과 지시 취소 가능 한계를 명확히 정의하도록 한다. 비트코인 확인 수만으로 계약, 은행 지급, 소유권 이전의 법적 효과가 정해지지 않는다. 기술적 BTC 수용이 거래의 모든 의무를 이행하는 것은 아니다. [BIS — PFMI principle 8]

Bitcoin에는 보통의 제공자 버튼으로 확인된 지급을 취소하는 기능이 없다. 자발적 환불은 수취인의 새로운 거래이며 원래 이전을 기록에서 지우지 않는다. 수취인과 금액은 확인 기준 이후뿐 아니라 전송 전에 검증해야 한다. [Bitcoin.org — Some things you need to know]

거래, 블록, 검증 출처를 기록하고 노드 최신 상태와 활성 분기 변화를 감시한다. confirmations는 조회 순간 상태이지 영구 증서가 아니다. 확인 감소나 충돌 대응도 정해 오래된 스냅샷을 새 증거로 오해하지 않도록 한다. [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]