PP amount

결제 버그는 단위에서 비롯됩니다. BIP70의 amount는 사토시를 센 64비트 정수였고, BIP21 URI의 amount 매개변수는 비트코인 소수 표기이므로, 같은 결제를 전자에서는 250000으로, 후자에서는 0.0025로 적습니다. 시스템 사이에서 자금을 이동하는 사람은 합계를 신뢰하기 전에 각 필드가 어떤 단위를 기대하는지 확인해야 합니다.

작동 방식

상태: 역사적 필드입니다. 이 필드는 BIP70에 속했으며, Bitcoin Core는 0.19에서 이 필드를 폐기 예정으로 표시했고 2020년 6월 3일에 0.20.0에서 제거했습니다.

PaymentDetails 메시지 안의 Output은 두 필드로 구성되었습니다. 자금이 어디로 가는지 지정하는 스크립트와 얼마인지를 지정하는 amount입니다. amount는 기본값이 영인 사토시 단위의 부호 없는 64비트 정수였고, 영에는 특정한 의미가 있었습니다. 영은 아무것도 지불하지 말라는 뜻이 아니었습니다. 판매자가 금액을 제시하지 않겠다는 뜻이며 지갑이 고객에게 얼마를 보낼지 물어야 한다는 뜻이었고, 기부 페이지가 이렇게 작동했습니다.

한 요청에 여러 출력이 각자의 amount와 함께 나타날 수 있었고, 결제하는 지갑은 이들 모두를 단일 트랜잭션으로 충족해야 했습니다. 이는 들리는 것보다 유용합니다. 판매자는 고객이 세 번 결제하거나 분할 사실을 알 필요 없이 판매 대금의 일부를 콜드 스토리지로, 일부를 환불용 핫월렛으로, 일부를 제휴 파트너에게 보낼 수 있었습니다.

범위는 제약이 된 적이 없습니다. 부호 없는 64비트 정수의 최댓값은 18,446,744,073,709,551,615 사토시로, 앞으로 존재할 2,100,000,000,000,000 사토시의 약 8,800배입니다. 흥미로운 경계는 반대쪽 끝에 있었습니다. 더스트 임계값 미만의 amount는 네트워크가 중계하지 않는 출력을 만들었고, Bitcoin Core의 정책은 이 임계값을 레거시 pay-to-public-key-hash 출력의 경우 546 사토시, 단일 키 segwit 출력의 경우 294 사토시로 정합니다.

확인할 수 있는 곳

오늘날 BIP70의 amount 필드를 구현한 것은 없지만, 그 배경에 있는 단위 혼동은 여전히 건재합니다.

세 가지 명세, 세 가지 단위. BIP21 URI는 비트코인으로 금액을 표기합니다. BIP70은 사토시로 표기했습니다. 라이트닝 BOLT11 인보이스는 더 세밀하게 밀리사토시, 즉 사토시의 1,000분의 1로 표기합니다. 여기에 지갑 인터페이스가 표시 설정을 더하므로, 같은 잔액이 한 번 설정하고 잊어버린 환경설정에 따라 0.00250000으로 또는 250,000으로 나타납니다.

이를 틀렸을 때의 실질적 비용은 상당한 돈입니다. 수수료 추정치는 가상 바이트당 사토시로 제시되므로, 입력 1개와 출력 2개인 segwit 지출 약 141 vbytes는 5 sat/vB에서 705 사토시가 듭니다. 이 수치를 비트코인으로 읽으면 일상적인 트랜잭션 하나에 대부분의 사람이 1년 동안 수수료로 쓰는 금액보다 많은 돈이 드는 것으로 여기게 됩니다.

두 가지 습관이 이를 해결합니다. 지갑 설정에서 단위를 하나 골라 그대로 두어 기대하는 자릿수가 절대 바뀌지 않게 하십시오. 그리고 출금 화면에서는 숫자를 읽기 전에 단위 라벨을 읽으십시오. 거래소 최소 출금액, 네트워크 수수료, 잔액이 같은 페이지에서 서로 다른 단위로 표기되는 경우가 흔하기 때문입니다.

PP amount vs Bitcoin URI amount

BIP70의 amount는 사토시 정수였고, BIP21의 amount는 비트코인 소수이며, 둘 사이의 배수는 100,000,000입니다. 그것이 전부이며, 그것만으로도 중요합니다. 한 형식에서 0.0025를 담는 필드는 다른 형식에서 250000을 담으며, 변환 없이 두 형식을 오가는 소프트웨어는 기우는 방향에 따라 8자릿수 규모의 오류를 냅니다. 현대 형식이 이겼으므로, 오늘날 결제 링크에서 보는 숫자는 무언가가 명시적으로 sats라고 하지 않는 한 비트코인입니다.