Sözlük / Lightning ve katman 2
Ödeme hash'i
- Ödeme hash'i nedir?
- Ödeme hash'i, alıcının oluşturduğu 32 baytlık bir sırrın SHA-256 özetidir ve hem bir Lightning ödemesinin kilidi hem de herkesin ona verdiği addır.
Lightning rotasındaki her sıçrama aynı ödeme hash'ini görür, ödemeyi her birine tanıtan da budur. BOLT 11, her faturada bunlardan tam olarak bir tane olmasını şart koşar ve bu, 256 bit taşıyan 52 bech32 karakteri olarak yazılır. Eşleşen sırrı göstermek, parayı talep etmenin tek yoludur ve o sırrı sonrasında elinizde tutmak makbuzunuzdur.
Nasıl çalışır
Bir ödeme hash'i hayatına tersi olarak başlar: alıcı, ödeme ön görüntüsü (preimage) adı verilen 32 rastgele bayt seçer ve bunların yalnızca SHA-256 değerini yayımlar.
Bu değer, faturaya p etiketi altında girer; BOLT 11 bu etiketi data_length olarak 52 değerine sabitler ve tam olarak bir kez bulunmasını şart koşar. Oradan rotanın aşağısına update_add_htlc içinde ilerler; mesaj tipi 128 olan bu mesajın alanları kanal kimliği, 64 bitlik bir sayaç, milisatoshi cinsinden tutar, payment_hash değerinin kendisi, bir CLTV son kullanma süresi ve 1366 baytlık bir soğan paketidir. Bu mesajda iki iş yapar: soğan yapısına ilişkili veri olarak da verilir, böylece her sıçramadaki HMAC'ler ona bağlanır. Bu nedenle eski bir soğan paketini farklı bir ödeme hash'iyle yeniden oynatmak, kontrol eden ilk düğümde başarısız olur.
Mutabakat hash'i geriye doğru yürütür. Alıcı ön görüntüyü update_fulfill_htlc içinde, mesaj tipi 130 ile, düz bir 32 baytlık değer olarak döndürür ve yukarı yöndeki her düğüm onu aynı kanallar üzerinden geri iletir. SHA-256 uygulandığında elindeki hash'i vermeyen bir ön görüntü kendisine verilen düğüm bunu öylece yok saymaz: BOLT 2, bir uyarı gönderip bağlantıyı kapatması ya da bir hata gönderip kanalı başarısız kılması gerektiğini söyler, çünkü bunun masum bir açıklaması yoktur.
Zincir üstünde hash kırpılır. HTLC çıktı betiği 32 baytlık değeri hiç içermez; RIPEMD160(payment_hash) değerine karşı bir OP_HASH160 karşılaştırması yapar, ki bu 20 baytlık bir taahhüttür, ve harcayan kişi ön görüntüyü tanıkta sunar. Aynı yuvarlanmış tutara ve aynı ödeme hash'ine sahip iki sunulan HTLC, son kullanma süreleri farklı olsa bile bayt bayt aynı çıktıları üretir, bu yüzden BOLT 3 bunlar için bir sıralama kuralı belirtmek zorundadır.
Bir gereklilik, arkasındaki saldırıyı görmeden tuhaf görünür. Bir düğüm, aynı ödeme hash'ini taşıyan birkaç HTLC'yi kabul etmelidir ve BOLT 2 bunun nedenini verir: kopyalar reddedilseydi, bir saldırgan bilinen bir hash ile yoklama yaparak o düğümün bu ödemeyi hâlihazırda elinde tutup tutmadığını öğrenebilirdi. Ayrı 64 bitlik kimlik, kopyaları birbirinden ayırt etmek için vardır.
Bitcoin satın alırken bu neden önemli
Bu sitede incelenen 63 borsadan ikisi, ücret notlarında bir Lightning ödemesini belgeliyor: para çekme notunda cüzdan çekimlerinin Lightning ve zincir üstü olarak desteklendiği yazan Strike ve ücret tablosu Lightning gönderimini gönderilen tutarın %0,2'si olarak fiyatlandıran Coinbase.
Bu ödemelerden biri takıldığında, bakılacak bir işlem kimliği yoktur, çünkü hiçbir şey blok zincirine ulaşmamıştır. Ödeme hash'i, hem cüzdanınızın günlüğünün hem de borsanın arka ofisinin elinde tuttuğu tek dizedir, bu yüzden ödeme ayrıntı ekranını kapatmadan önce oradan kopyalayın. Bir Lightning çekiminin “işlem kimliğini” isteyen bir destek masası bu değeri istiyordur.
Aldığınız hata size fazla bir şey söylemez ve bu bilerek böyledir. BOLT 4 beş ayrı sorunu tek bir başarısızlık kodunda, PERM|15 olarak numaralandırılan incorrect_or_unknown_payment_details içinde birleştirir: hash son düğüm için bilinmiyordur, ödeme sırrı onunla eşleşmiyordur, o hash için tutar çok düşüktür, son kullanma süresi mevcut blok yüksekliğine çok yakındır ya da gerekli ödeme üst verisi eksiktir. Spesifikasyon bu birleştirmeyi açıklar. Eski ayrı kodlar, bir yönlendirme düğümünün aynı hash'i çok daha düşük bir değerle ileri gönderip yanıtı okuyarak bir ödemenin nereye gittiğini tahmin etmesine izin veriyordu. Cüzdanınız nedeni sizden saklamıyor, ona hiç söylenmemiştir, bu yüzden faturayı yeniden oluşturup tekrar ödemek pratik yanıttır.
Aynı değer, çok parçalı bir ödemenin her parçası dahil, düğümünüzden alıcının düğümüne kadar aynı kalır; BOLT 4 bu parçaların tek bir ödeme hash'ini paylaşmasını şart koşar. Onu iki kez gören herkes tek bir ödemeye baktığını bilir. Phoenix incelememiz ACINQ şirketinin kendi SSS'sinden, cüzdan üzerinden yapılan ödemelerin nihai hedefini ve tutarını bildiğini kabul ettiğini aktarır; bu, aynı maruz kalmanın, bu sitenin çıkarsadığı değil satıcının belirttiği açık sözlü hâlidir.
İlgili bir nedenle bir faturayı yeniden kullanmak işe yaramaz olmaktan da kötüdür. BOLT 4, ödenmiş bir hash verilen son düğümü onu bilinmeyen saymakta ya da parayı kabul etmekte serbest bırakır, bu yüzden yeniden yayımlanan bir QR kodun sonucu, alıcının hangi uygulamayı çalıştırdığına bağlıdır.
BOLT 11 bağış test vektöründeki ödeme hash'ini çözme
BOLT 11 spesifikasyonu çözümlü bir bağış faturası sunar ve içindeki ödeme hash'i, hiçbir cüzdanın asla üretmemesi gereken sabit bir test değeridir.
Örneğin başlığı "Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102" şeklindedir ve dizi lnbc1pvjluez ile başlar. lnbc öneki ve bech32 ayırıcısından sonra pvjluez zaman damgasıdır, 1970 yılının başından itibaren 1496314658 saniye. Sırada ödeme sırrı alanı gelir, ardından p etiketi, sonra uzunluk olan p5 gelir: bech32'de p 1 ve 5 20 olduğundan alanın uzunluğu 1 * 32 + 20 = 52 karakterdir. Bu karakterler, yani qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq, o başlıkta aktarılan hash'e çözülür.
Bunun hiçbir yanı özel değildir. Spesifikasyon, örneklerinin imzalandığı özel anahtarı, e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734, yayımlar ve o bölümdeki her faturanın, aksi belirtilmedikçe, 1111111111111111111111111111111111111111111111111111111111111111 ödeme sırrını taşıdığını söyler, bu yüzden bu dizeler ödeme talebi değil ayrıştırıcı test verileridir. Bir cüzdan ya da tanılama aracı size bu hash'i bir test paketinin dışında gösterirse, bir şey ödemenizi bildirmek yerine spesifikasyonu tekrarlıyordur.
Ödeme hash'i vs işlem kimliği
Bir ödeme hash'i bir Lightning ödemesini adlandırır; bir işlem kimliği Bitcoin blok zincirinde var olan bir işlemi adlandırır. Her ikisi de 32 bayttır ve her ikisi de 64 onaltılık karakter olarak yazdırılır, birbirlerinin destek formlarına bu şekilde düşerler. İşlem kimliği, işlemin kendi baytlarından sonradan hesaplanır ve herhangi bir blok gezginine yapıştırılabilir. Ödeme hash'i ise ödeme var olmadan önce alıcı tarafından seçilir, ödeme normal şekilde mutabakata bağlandığında hiçbir blokta görünmez ve bir gezginde hiçbir sonuç döndürmez. Boş bir arama sonucu genellikle doğru değere ve yanlış araca sahip olduğunuz anlamına gelir.
Ödeme hash'i vs ödeme sırrı
Bir ödeme hash'i ile bir ödeme sırrı, aynı faturadaki iki farklı 256 bitlik değerdir, p ve s etiketlerinde taşınır ve her biri 52 bech32 karakteri olarak kodlanır. Hash zorunlu olarak kamusaldır: her sıçrama HTLC'sini kurmak için onu görmek zorundadır. Sır yalnızca son düğüme, soğanın içinde teslim edilir ve BOLT 11 işini tek satırda belirtir: "prevents forwarding nodes from probing the payment recipient" (yönlendiren düğümlerin ödeme alıcısını yoklamasını engeller). s alanı bulamayan bir okuyucu ödemeyi doğrudan başarısız kılmalıdır. Hash kilittir; sır ise ödeme yapan kişinin faturayı onu düzenleyen kişiden aldığının kanıtıdır.