İçeriğe geçin
buybitcoinsmart

Sözlük / Lightning ve katman 2

Keysend

Keysend nedir?
Keysend, fatura olmadan bir Lightning ödemesi gönderir: ödeyen taraf 32 baytlık ön görüntüyü (preimage) üretir, bunu ödeme hash'ine dönüştürür ve sırrı onion paketinin içinde taşır.

Keysend, alıcının bir sır seçip hash'ini bir faturada yayımladığı normal Lightning akışını tersine çevirir. Gönderenin sırrı, çift sayı olan 5482373484 özel TLV kaydında taşınır ve BOLT 1, keysend'i bilmeyen bir düğümün bu kaydı yok sayması yerine reddetmesini sağlar. Hiçbir gidiş dönüş olmadan çıplak bir düğüm genel anahtarına ödeme yapabilirsiniz ve bir faturanın bırakacağı kriptografik makbuzdan vazgeçersiniz.

Nasıl çalışır

Keysend, bir BOLT 1 kuralının daha katı yarısına dayanır: bir okuyucu tek tipli bilinmeyen bir TLV kaydını atar ve devam eder, ama bilinmeyen çift tipli bir kayıtta tüm akışı başarısız kılmak zorundadır.

2^16 altındaki tip tanımlayıcıları BOLT'lar için ayrılmıştır ve 2^16 ve üzerindeki her şey özel kayıtlar için serbesttir; BOLT 1, sıradan düğümlerin veriyi yok sayması gerektiğinde tek sayı, reddetmesi gerektiğinde çift sayı seçilmesini söyler. bLIP-3, 5482373484 sayısının özgün lnd uygulaması tarafından rastgele seçildiğini kaydeder ve bu sayı dörtle bittiği için keysend reddeden tarafta kalmıştır. Bu yüzden bir özellik bitine ihtiyaç duyar: istekli düğümler 54/55 bitlerini duyurur, bunlara keysend adı verilir, bu da var_onion_optin özelliğine bağlıdır ve bLIP-3, gönderenlerin körlemesine gönderip ödemenin başarısız olmasını izlemek yerine bu biti aramaları gerektiğini söyler.

bLIP-3 içinde anlatılan gönderenin işi kısadır. Kriptografik olarak güvenli, rastgele bir 32 baytlık değer üretin, bunu o kayda koyun ve update_add_htlc içindeki payment_hash alanını bunun SHA-256 değerine ayarlayın. Bir ön görüntüyü asla yeniden kullanmayın ve daha önce ödediğiniz bir faturanın ön görüntüsünü asla yeniden kullanmayın. Paket her sıçramada gizlenir, böylece bir sıçrama yalnızca bir sonrakinin adresini elde eder ve aradaki hiç kimse kaydı görmez. Son düğüm bulduğu değeri hash'ler, kendisinden kabul etmesi istenen hash ile karşılaştırır ve ödemeyi sonuçlandırır.

Reddetme kasıtlı olarak sessizdir. BOLT 4, bir düğümün anlamadığı bir yük için kelimesi kelimesine bir yanıt içerir, PERM|22 invalid_onion_payload, bu yanıt sorunlu TLV tipini bile adlandırabilir. bLIP-3, alıcılardan bunun yerine PERM|15 incorrect_or_unknown_payment_details döndürmelerini ister, böylece reddedilen bir keysend, düğümün hiç üretmediği bir ödeme hash'inden ayırt edilemez.

Nerede görülür

Keysend, podcast boost'larının altındaki altyapıdır.

bLIP-10, başlangıçta Breez tarafından seçilen 7629169 tipi ikinci bir kaydı tanımlar; bu kayıt, keysend ödemesine eklenen düz bir JSON nesnesi taşır: podcast başlığı, bölüm, saniye cinsinden oynatma konumu için ts, boost veya stream değerine ayarlanan action ve bir boostagram oluşturan isteğe bağlı message. Dakika başına akış seconds_back alanını 60 değerine ayarlar. Bu kaydın tipi tek sayıdır, bu yüzden bLIP-10 geriye dönük uyumluluğu bir kenara bırakır: üst veriyi yok sayan bir sunucu yine de sats'ları elinde tutar. Bu kayıt, tek başına bir keysend'in alıcıya hiçbir şey söylememesi yüzünden vardır, bu nedenle bir uygulamanın programın adını kendisi belirtmesi gerekir.

Aynı boşluk keysend'i satın alma yolunun dışında tutar. Bir borsadan para çekme işlemi ya size bir fatura verir ya da sizden bir fatura ister, çünkü platform ödemeyi hesabınıza bağlamak zorundadır ve bu kelime bu sitedeki 63 borsa kaydının hiçbirinde ve 41 cüzdan incelemesinin hiçbirinde geçmez. bLIP-3 bu dengeyi dürüstçe ortaya koyar: keysend'in daha iyi tasarlanmış bir kendiliğinden ödeme biçimine, offers ve AMP'ye yol vermesini bekler ve bu arada nelerden vazgeçtiğinizi listeler, ödeme kanıtı ve alacaklının nihai CLTV sona ermesi üzerindeki her türlü söz hakkı.

Keysend vs Lightning adresi

Keysend ve bir Lightning adresi, ikisi de size hiç fatura vermemiş birine ödeme yapmanızı sağlar ve bunlardan yalnızca biri faturayı gerçekten atlar. user@example.com yazmak, cüzdanınızı yeni bir BOLT11 fatura döndüren bir HTTPS sorgusuna gönderir, böylece ön görüntüyü yine alıcı seçmiş olur ve elinizde onların imzasıyla desteklenen bir makbuz kalır. Keysend hiçbir web isteği ve hiçbir sunucu gerektirmez, yalnızca 33 baytlık düğüm genel anahtarını ve ona giden bir rotayı gerektirir ve sonrasında size kanıtlayacak hiçbir şey bırakmaz, çünkü sır baştan beri sizindi. Ödediğinizi bir gün göstermeniz gerekebilirse faturayı tercih edin.

Karıştırılmaması gerekenler

Sık sorulan sorular

Keysend, Lightning spesifikasyonunun bir parçası mı?

Hayır, keysend, uygulamaların hâlihazırda yayımladıklarını belgelemek için 8 Aralık 2021 tarihinde oluşturulmuş bir Lightning iyileştirme önerisi olan bLIP-3 içinde yer alır. BOLT'larda hiçbir değişiklik gerektirmedi, çünkü 2^16 ve üzerindeki TLV tip tanımlayıcıları özel kayıtlar için serbesttir, ancak keysend'in 5482373484 tipi çifttir, bu yüzden BOLT 1, keysend'i desteklemeyen bir düğümün yükü yok sayması yerine reddetmesini sağlar.

Bir keysend ödemesi ödediğimi kanıtlar mı?

Hayır, çünkü ön görüntüyü alıcı değil siz ürettiniz ve ödemeyi alıcıya bağlayan bir fatura imzası yoktur. bLIP-3, kaybedilen ödeme kanıtını keysend'in başlıca sakıncalarından biri olarak listeler, bu yüzden makbuz önemliyse her zaman bir fatura kullanın.

Keysend ödemem neden başarısız oldu?

Çoğu zaman bunun nedeni hedefin keysend kabul etmemesidir ve bunu hata mesajından anlayamazsınız. Kendiliğinden ödemeleri reddeden bir düğüm PERM|15 incorrect_or_unknown_payment_details döndürür; bu, yanlış bir ön görüntü veya düğümün hiç üretmediği bir ödeme hash'i ile aynı hatadır, bu yüzden bLIP-3 yalnızca keysend özellik bitini duyuran düğümlere gönderilmesini söyler; bu bit bLIP-2 içinde 54/55 olarak kayıtlıdır.

Sıradaki okuma

İlgili terimler

Daha fazlası: Lightning ve katman 2

Bu sayfayı İngilizce okuyun