BOLT12 teklifi

Bir offer, ödendikten sonra da geçerli kalan bir ödeme talebidir; böylece tek bir basılı kod her müşteriye hizmet eder. Offer'larda imza da sağlama toplamı da yoktur ve bu offer'ların alanları 2 ile 22 arasındaki TLV tiplerini kaplar; bu tipler, düşük segment bir telefonun kamerasına yetecek kadar kısa tutulmuştur. Bitcoin ödemesi alıyorsanız, fark bir kez bastığınız kod ile bu kodun ürettiği ve 7200 saniye sonra süresi dolan fatura arasındaki farktır.

Nasıl çalışır

BOLT12 offer, insan tarafından okunabilir lno ön eki, bir ayırıcı 1 ve ardından bu kayıtları sırayla taşıyan bech32 tarzı karakterlerle yazılmış bir tip-uzunluk-değer kayıtları dizisidir.

Sonunda altı karakterlik bir sağlama toplamı yoktur. Şartname bunu, QR kodların kendi sağlama toplamlarını taşıdığı ve bozulmuş bir offer'ın kayıp bir ödeme yerine ayrıştırılamayan bir dize ürettiği gerekçesiyle kaldırır. Uzun offer'lar, artı işareti ve isteğe bağlı olarak onu izleyen boşlukla bölünebilir; böylece karakter sınırı olan bir metin alanına yapıştırıldığında bozulmaz ve okuyucu, ayrıştırmadan önce artı işaretini ve boşluğu kaldırmalıdır. Yazan taraf ya tamamen küçük harf ya da tamamen büyük harf kullanmalıdır ve QR kodlar için büyük harf seçmelidir.

Alanların kendileri numaralıdır. offer_chains 2, offer_metadata 4, offer_currency 6, offer_amount 8, offer_description 10, offer_features 12, offer_absolute_expiry 14, offer_paths 16, offer_issuer 18, offer_quantity_max 20 ve offer_issuer_id 22 numarasını taşır. Yazan taraf 1 ile 79 arasındaki tiplerin içinde kalmalıdır; 1000000000 ile 1999999999 arasındaki ikinci aralık deneylere ayrılmıştır. Bu listenin hiçbirinde imza yoktur ve bu bilinçlidir: imzalamak, hiçbir fayda sağlamadan dizeyi uzatırdı, çünkü imza olmayan her alan kendisini izleyen isteğe kopyalanır; dolayısıyla kurcalanmış bir offer basitçe hiçbir fatura üretmez.

Ödeme yapmak bu noktadan sonra iki mesaj daha gerektirir. Cüzdanınız, onion mesajı üzerinden lnr ön ekli bir invoice_request gönderir; anlamadığı alanlar dahil offer'ın her alanını kopyalar ve sonucu bir Merkle kökü üzerinden BIP340 imzasıyla imzalar. Düzenleyen taraf imzalı bir faturayla yanıt verir. Merkle yapısı, her alanın yaprağını bir nonce yaprağıyla eşler ve bu, ödeme yapanın daha sonra tartışmalı bir faturanın tek bir alanını komşularını açığa çıkarmadan gösterebilmesini sağlar; tüm dizeyi kapsayan bir BOLT11 imzası bunu yapamaz.

Bu üç mesajdan ikisi, iadeler ve ATM'ler için ters yönde çalışır. Bir satıcı, göndermek istediği bir tutarı belirten bir invoice_request yayımlar, siz bir faturayla yanıt verirsiniz ve satıcı ödeme yapmadan önce invoice_node_id alanını doğrular.

Bitcoin satın alırken bu neden önemli

Bir offer, ödeme almanın bir yolunu nasıl yayımladığınızı değiştirir ve ödeme almanın size maliyeti konusunda hiçbir şeyi değiştirmez.

Bu sitedeki Phoenix incelemesini ele alın. ACINQ, ücretleri keşfetmenizi beklemek yerine bir ücret tablosu yayımlar: Lightning üzerinden gönderim %0,4 artı 4 satoshi tutar, gelen likiditeniz varsa ödeme almak ücretsizdir ve yer açmak için cüzdanın zincire çıkması gerektiğinde ödeme almak, madencilik ücretleri artı %1 tutar ve 1.000 satoshilik yeni bir kanal açılır. Fatura yerine bir offer dağıtmak bu rakamların hiçbirine dokunmaz. Her ödeyici için yeni bir kod ürettiğiniz adımı ortadan kaldırır, likidite için birinin ödeme yaptığı adımı değil.

Gizlilik kazancı gerçektir ama sınırlıdır. Lightning adresi, fatura için gelen her isteği birinin alan adındaki bir web sunucusu üzerinden yönlendirir ve bu işleten, tutarları ve zamanlamayı görür. Offer, isteği Lightning üzerinden onion mesajı olarak yönlendirir ve offer_paths, kanallarının tümü özel olan bir düğümün hiçbir düğüm kimliği yayımlamadan erişilebilir kalmasını sağlar. Bunun size kazandırmadığı şey, kendi sağlayıcınızdan gizliliktir: Phoenix incelememiz, ACINQ tarafından yayımlanan SSS bölümünden ödemelerin nihai varış yerini ve tutarını bildiğini açıkça söyleyen ifadeyi aktarır.

Pratik uyarı yapıştırmayla ilgilidir. Bir borsadaki para çekme kutusu bir Lightning faturası ister ve lno1 dizesi bir fatura değildir. Bu sitedeki 63 borsa kaydından biri olan Strike, Lightning tabanlıdır ve 100 ülkeden fazlasına yapılan transferlerde kendi ücretini eklemez; iki biçimin karıştırıldığı akış tam olarak bu türdendir. Bu sitedeki 41 cüzdan incelemesi ve 63 borsa kaydı şu anda offer desteğini bir özellik olarak belgelemez; bu nedenle bunu varsaymak yerine kendi cüzdanınızın sürüm notlarında doğrulanacak bir şey olarak görün.

Bir şapka tezgahının offer'ı ve dönüştüğü fatura

Şapkaları 25 dolara satan bir tezgah, offer_currency alanı USD ve offer_amount alanı 2500 olacak şekilde bir offer yazar.

Bu, şartnamenin Bitcoin dışındaki bir para birimine ilişkin kuralıdır: üç harfli bir ISO 4217 kodu ve ISO 4217 üssüyle düzeltilmiş para birimi biriminde bir tutar; dolarda bu, sent anlamına gelir. offer_amount alanını herhangi bir şekilde ayarlamak, offer_description alanını zorunlu kılar, çünkü belirli bir şey için ücretlendirilen ödeme yapan kişi bunun ne olduğunu bilmelidir. Üç şapka kaldıysa offer_quantity_max 3 olur ve tezgahın sabit bir sınırı yoksa 0 olur. Göründüğü kadar tuhaf olsa da 1 değeri açıkça izin verilen bir değerdir; böylece bir stok sistemi son ürün için hiçbir zaman özel bir duruma ihtiyaç duymaz. Şartname önce bir alan adı, ardından bir boşluk ve herhangi bir dostane metin istediği için offer_issuer hats@example.com Hat Stall şeklinde olabilir.

Cüzdanınız bunu okur, size 25 dolar teklif eder ve iki şapka için invreq_quantity alanı 2 olan, bir invreq_payer_id ve isteğe bağlı bir invreq_payer_note taşıyan bir invoice_request gönderir. Geri dönen fatura bir ödeme hash'i, bir oluşturma zaman damgası, en az bir körlenmiş yol ve her yol için taban ücreti, oransal ücreti, CLTV deltasını ve taşıyacağı en küçük ve en büyük HTLC'yi kapsayan bir ücret teklifi içerir. Burada sizi iki kural korur. Cüzdanınız, 0 ile 159 arasındaki aralıklarda yer alan herhangi bir alan gönderdiğiyle eşleşmezse faturayı reddetmelidir ve milisatoshi tutarı offer'ın verdiği dolar tahmininden önemli ölçüde farklıysa sizi uyarmalıdır. Düzenleyen taraf invoice_relative_expiry alanını ayarlamadıkça fatura, oluşturulmasından 7200 saniye sonra reddedilmelidir.

BOLT12 offer vs BOLT11 fatura

BOLT12 offer, bir ödeme talebine yönelik taleptir; BOLT11 fatura ise ödeme talebinin kendisidir.

BOLT12 metni, selefinden yakınan sekiz şikayetle açılır ve bir ödeyenin hissettikleri şunlardır. BOLT11 fatura bir bütün olarak imzalanır; dolayısıyla bir alanı kanıtlamak hepsini açığa çıkarmak demektir. Şartnamenin değerlendirmesine göre insan tarafından okunabilir tutarları sorunlu çıkmıştır: p çarpanı sık sık yanlış işlenmiştir ve pikobitcoin ile saymak satoshiden daha zordur. payment_secret alanı yalnızca fatura ödeyen ile ödeme alan arasında özel kaldığı sürece yoklamayı durdururdu; yayımlanmış bir fatura böyle değildir. Ve şartnamenin kendi ifadesiyle, faturalar kullanıcı başına verilmelidir ve aynı kullanıcı için iki ödeme denemesi yapılırsa doğrudan tehlikelidir. Bir offer, hiç fatura olmadığı için dördüne de yanıt verir.

BOLT12 offer vs Lightning adresi

BOLT12 offer kendi kendine yeten bir dizedir; Lightning adresi birinin sunucusunun sizin için çözümlediği bir addır.

İkisi de yeniden kullanılabilir ve karıştırılmalarının nedeni budur. Adres bir alan adına, bir sertifikaya ve hizmeti çalışır durumda tutan bir işletmeciye bağlıdır ve bu üçünden herhangi biri devre dışı kaldığı gün çalışmayı bırakır. Offer ise iki düğümün de onion mesajı konuşmasına bağlıdır, başka hiçbir şeye değil; bu daha küçük bir arıza yüzeyidir, ancak kendi cüzdanınızın bunu desteklediğini varsaymak yerine doğrulamanız gerekir. Adres, yüksek sesle söylenebilme konusunda öndedir. Uzun bir lno1 dizesi bir QR kodudur, mikrofona okunan bir şey değil.