PP merchant data

결제를 주문과 대조하는 일은 모든 결제 화면이 해결해야 하는 눈에 띄지 않는 문제이며, 비트코인은 트랜잭션에 청구서 번호가 실리지 않아 이를 더 어렵게 만듭니다. BIP70은 고객의 지갑에 쿠키를 건네고 되돌려 달라고 요청하는 방식으로 이 문제를 해결했습니다. 오늘날 상인들은 주문마다 일회용 주소를 쓰는 방식으로 같은 문제를 해결하며, 이는 더 단순하고 프라이버시를 더 잘 보호합니다.

작동 방식

상태: 역사적입니다. merchant data는 PaymentDetails의 7번 필드이자 돌아오는 Payment 메시지의 1번 필드였고, 2020년 6월 3일에 Bitcoin Core 0.20.0이 출시되면서 BIP70의 나머지와 함께 사라졌습니다.

불투명성 자체가 핵심이었습니다. 지갑은 그 바이트를 의미 없는 것으로 취급하고 변경 없이 반환하라는 지시를 받았으며, 이 덕분에 각 상인은 다른 누구도 이해할 필요 없이 자체 방식을 만들 수 있었습니다.

두 가지 방식이 흔했습니다. 예를 들어 16바이트 주문 식별자 같은 짧은 조회 키는 요청을 작게 유지하고 작업을 상인의 데이터베이스로 넘겼습니다. 자체 완결형 덩어리는 장바구니 전체를 담고 서버가 상태를 갖지 않게 했지만 크기를 대가로 치렀습니다.

두 번째 방식에는 명세서가 경고한 허점이 있습니다. 그 바이트는 상인이 통제하지 않는 소프트웨어에서 돌아오므로, 그 안에서 읽어 낸 것은 무엇이든 공격자가 제공한 입력입니다. 가격이나 할인 코드를 그 안에 저장하고 반환된 사본을 신뢰한 상점은 스스로 쿠폰 생성기를 만들어 둔 셈입니다. 해결책은 왕복하는 상태에 대한 통상적인 방법입니다. 메시지 인증 코드를 붙이고 필드를 하나라도 읽기 전에 검증하는 것입니다.

크기는 겉보기보다 중요했습니다. 서명된 요청 전체가 고객에게 도달해야 했고, 이를 QR 코드로 표현하면 엄격한 상한이 생깁니다. 가장 큰 심볼인 버전 40에 가장 낮은 오류 정정 수준을 적용해도 이진 데이터 2,953바이트만 담을 수 있습니다. 그 상한 때문에 BIP72가 r= 매개변수를 정의했으며, 짧은 링크가 요청을 직접 담는 대신 HTTPS로 제공되는 요청을 가리킬 수 있게 했습니다.

확인할 수 있는 곳

merchant data가 하던 일은 이제 주소 자체가 합니다.

BTCPay Server 같은 결제 소프트웨어는 청구서마다 새로운 주소를 도출하므로, 도착한 결제는 왕복도, 반환되는 상태도 없이 스스로의 주문을 식별합니다. 이는 BIP70보다 두 가지 점에서 낫습니다. 지불인이 조작할 대상이 없고, 그렇지 않았다면 체인을 읽는 누구에게나 상인의 수익 전체를 공개했을 주소 재사용을 피합니다. 수탁형 플랫폼도 같은 방식으로 작동하며, 입금이 다른 사람의 계좌가 아니라 본인 계좌로 들어오는 이유가 여기에 있습니다.

이 모든 것에서 가져갈 만한 경고가 하나 있습니다. 여러 다른 네트워크는 입금과 함께 메모나 목적지 태그를 요구하며, 이를 빼면 자금과 본인을 이어 주는 정보가 아무것도 없는 통합 계좌로 떨어집니다. 비트코인에는 그런 필드가 없습니다. 입금 페이지가 비트코인 트랜잭션에 태그, 메모 또는 참조 코드를 붙이라고 요구한다면 그 양식은 설정이 잘못되었거나 가짜이며, 실제로 잘못 보낸 입금을 되찾는 일은 느리고 흔히 불가능합니다.

PP merchant data vs PP memo

merchant data는 기계를 위해 쓰였고, memo는 사람을 위해 쓰였습니다. 하나는 고객에게 절대 표시되지 않았고, 다른 하나는 표시되기 위해서만 존재했습니다. 실패 방식도 그에 맞게 다릅니다. 검증하지 않은 memo는 확인 화면을 읽는 사람을 오도하고, 검증하지 않은 merchant data는 상인 자신의 회계 소프트웨어를 오도합니다. 둘 다 반환 구간에서 서명되지 않았고, 그것이 둘 다 신뢰할 수 없는 것으로 다루어야 했던 이유입니다.