PaymentDetails

PaymentDetails, satıcının gerçekte imzaladığı bölümdü; dış zarf ise yalnızca bunu kanıtlayan sertifikayı taşıyordu. Yedi alan içeriyordu: varsayılanı main olan bir ağ adı, bir çıktı listesi, zorunlu bir zaman damgası, isteğe bağlı bir sona erme zamanı, bir not, bir geri çağrı URL'i ve opak bir merchant_data veri bloğu. Bugün bir BIP21 URI'si ile bir ödeme sayfası aynı işi imza ve sunucu olmadan yapıyor.

Nasıl çalışır

Durum: tarihsel. Bitcoin Core, BIP70'i 3 Haziran 2020 tarihinde 0.20.0 sürümünde kaldırdı ve PaymentDetails'in çalışan bir uygulaması yok. Bu sitede belgelenmesinin nedeni, alan adlarının hâlâ eski entegrasyon rehberlerinde ve Bitcoin.org geliştirici referansında görünmesi.

Yapıyı JSON değil, Protocol Buffers taşıyordu. Bu seçim, üzerinde durmaya değer bir nedenle önemliydi: satıcı PaymentDetails'i bir bayt dizisine serileştiriyor ve tam o baytları, iç içe bir mesaj olarak değil, opak bir alan olarak dış PaymentRequest içine yerleştiriyordu. İmza bayt dizisini kapsıyordu, böylece aynı alanları farklı bir sırayla yeniden kodlayan hiçbir kütüphane geçerli bir imzayı geçersiz kılamıyordu.

Yedi alan talimatlar ve kayıt tutma olarak ikiye ayrılıyordu.

• network, varsayılanı "main" olan bir dize; tanımlı tek diğer değer "test".
• outputs, her girdisi satoshi cinsinden bir tutarı bir betikle eşleştiren, yinelenen bir liste. Birden fazla çıktı yasaldı ve satıcılar bunu, müşteriden iki kez göndermesini istemeden tek bir müşteri ödemesini sıcak cüzdan ile soğuk saklama arasında bölmek için kullanıyordu.
• time, talebin ne zaman oluşturulduğunu kaydeden zorunlu bir unix zaman damgası.
• expires, ardından cüzdanın talebi reddetmesi beklenen isteğe bağlı bir unix zaman damgası. BIP70'i kart terminaline benzeten alan buydu, çünkü satıcı bir itibari para fiyatı verebiliyor ve onu sabit bir süre için garanti edebiliyordu.
• memo, ödeyiciye gösterilen UTF-8 bir not.
• payment_url, cüzdanın işlemi yayımladıktan sonra Payment mesajını gönderdiği yer.
• merchant_data, satıcının bir ödemeyi bir alışveriş sepetiyle eşleştirebilmesi için değiştirilmeden geri gönderilen opak baytlar.

Yalnızca time ve çıktı betikleri zorunluydu. Geri kalan her şeyi satıcı atlayabilirdi ve çoğu atlıyordu.

Nerede karşınıza çıkar

PaymentDetails'in arkasındaki fikir mesajdan daha uzun yaşadı; fark edilmesi gereken yararlı nokta da bu.

Fiyatın sona ermesi artık cüzdanınızda değil, borsada ele alınıyor. Anında alım ekranından alım yaptığınızda yanında geri sayım bulunan bir fiyat teklifi alırsınız; geri sayım biterse teklif yeni fiyattan yeniden oluşturulur. Bu, bir web uygulamasında yeniden uygulanmış expires alanıdır ve satıcıyı oynaklığa karşı tam olarak aynı şekilde korur. Bir borsanın emir defterindeki emir eşleştirmesi aynı işi farklı yapar: hiçbir zaman sabit bir fiyat teklif etmez.

Mesajın tamamının satıcı tarafındaki karşılığı, ödeme yazılımındaki bir fatura kaydıdır. BTCPay Server ve benzeri araçlar bir BIP21 URI'si oluşturur, onu yapılandırılmış bir dakika sayısı boyunca açık tutar ve gelen işlemi dahili bir sipariş tanımlayıcısıyla eşleştirir; merchant_data tam olarak bunun içindi.

PaymentDetails vs makbuz

PaymentDetails talepti; BIP70 içindeki makbuz ise satıcının sonradan döndürdüğü PaymentACK mesajıydı. Biri ne olması gerektiğini tanımlıyordu, diğeri satıcının bunun gerçekleştiğini gördüğünü doğruluyordu. İkisi de bir blok zinciri gerçeği değildi ve insanların küçümsediği sınır tam da buydu: bir satıcıdan alınan imzalı bir teyit, satıcının sunucusunun bir şey söylediğini kanıtlar, bir işlemin onaylandığını değil. Bir Bitcoin ödemesini kesinleştiren şey makbuzlar değil, onaylardır.