Ödeme sırrı

Lightning'in ödeme sırrı, fatura başına bir parola gibi çalışır ve alıcı düğüm parayı kabul etmeden önce ödeme yapan bunu geri yansıtır. BOLT 11 ona s etiket harfini verir, uzunluğunu 52 bech32 karakteri olarak sabitler ve okuyucuya, onsuz gelen her faturayı başarısız kılmasını söyler. Sizin için bu, ödeme hash'inizi gören bir yönlendirme düğümünün ödemenin cüzdanınızda sona erdiğini anlayamamasının nedenidir.

Nasıl çalışır

Ödeme sırrı, ödeme yapan tarafından değil, her zaman alıcı cüzdan tarafından üretilir ve ödeme son sıçramasına ulaşana kadar onion içinde kapalı kalır.

BOLT 11 onu, s harfiyle ve 52 sabit data_length değeriyle yazılan, 16 etiketli alan türü olarak tanımlar. O 52 bech32 karakteri 260 bit taşır: 32 baytlık bir değer artı dolgu, ve fatura yazan tam olarak bir tane eklemek zorundadır. Okuyucu, sabit uzunluklu bir alanın uzunluğu yanlışsa ödemeyi başarısız kılmak zorundadır ve geçerli bir s alanı yoksa yine aynı şeyi yapmak zorundadır.

Ödeme yapan, değeri son düğüm için onion yüküne kopyalar; BOLT 4 buna TLV kayıt türü 8, payment_data der ve içinde 32 baytlık sır ile bir total_msat tutarı bulunur. O katmanı yalnızca hedef soyabilir, dolayısıyla ara sıçramalar bunu hiçbir zaman görmez; hepsinin HTLC'lerini kilitlediği ödeme hash'inden farklı olarak.

Uçtaki kontrol bilinçli olarak bilgi vermez. O ödeme hash'i için beklenenle eşleşmeyen ya da zorunlu olup bulunmayan bir sır, HTLC'yi incorrect_or_unknown_payment_details ile, yani PERM|15 hatasıyla başarısız kılar; bu, bilinmeyen bir ödeme hash'inin aldığı yanıtın aynısıdır. BOLT 4 birleştirmeyi açıklar: eski çift, PERM|16 incorrect_payment_amount ve 17 final_expiry_too_soon, yönlendiren bir düğümün aynı hash ile çok daha düşük tutarlarda ödemeleri yeniden göndermesine ve yanıtı okuyarak hedefi bulduğunu doğrulamasına izin veriyordu.

Destek artık müzakere edilmez. BOLT 9, 14 ve 15 özellik bitlerini, payment_secret olarak, ASSUMED biçiminde listeler ve 16 ile 17 bitleri, basic_mpp, buna bağlıdır.

Nerede görürsünüz

Modern bir lnbc dizisinde ödeme sırrını, sp5 ile başlayıp 52 bech32 karakteri boyunca süren bölüm olarak tanıyabilirsiniz.

BOLT 11 test vektörlerinde bu bölüm, on iki kez yinelenen zyg3 ve ardından zygs'tir; 32 baytının her biri 0x11 olan bir sırrı kodlar. Ödeme sırrını hiçbir zaman siz yazmazsınız: değeri yalnızca fatura yazan ve ödeme yapan cüzdan ele alır.

Alanın değerini kanıtladığı yer çok parçalı ödemelerdir. Tek bir rotada yeterli likidite yoksa ve fatura basic_mpp sunuyorsa, BOLT 4 bir cüzdanın tutarı aynı ödeme hash'ini paylaşan birkaç HTLC'ye bölmesine izin verir ve her parça sırrı taşımak zorundadır, total_msat üzerinde de anlaşmalıdır. Alıcı, toplam gelene kadar hiçbir şeyi kapatmaz ve ilk HTLC'den sonra en az 60 saniye bekleyip kümeyi bir mpp_timeout ile başarısız kılmalıdır. Dolayısıyla Strike gibi Lightning öncelikli bir uygulamadan yapılan daha büyük bir Lightning çekiminin bir dakika askıda kalıp sonra geri dönmesi, kaybedilen para değil, süresi dolan eksik bir HTLC kümesi olabilir. Bu parçaları Phoenix gibi telefonunda gerçek bir Lightning düğümü çalıştırarak kendi cüzdanınız mı bir araya getiriyor, yoksa kontrol etmediğiniz bir sunucuda bir saklayıcı mı, sır onları tek bir ödeme olarak işaretler.

Ödeme sırrı vs ödeme hash'i

Ödeme hash'i ve ödeme sırrı, tek bir BOLT 11 faturasında ikisi de 256 bitlik alanlardır ve fark, onları kimin görebildiğindedir. Her sıçrama hash'i öğrenir, çünkü her biri ilettiği HTLC'yi ona kilitler; sırrı ise son düğümden başka kimse öğrenmez, o da en içteki onion katmanında yol alır. Hash, ödemenin kapanıp kapanmadığını yanıtlar ve onu açan preimage makbuzdur. Sır ise, ödeme yapanın sizin yazdığınız faturadan hareket edip etmediğini yanıtlar; hash bunu yapamaz, çünkü rotadaki herkes onu görebilir. Kodlamada ikiz gibi görünürler: p etiketi ve s etiketi, ikisi de 52 karakter, ikisi de başka her uzunlukta reddedilir.