Tento týden přinášíme popis návrhu na započetí testování HTLC atestací, předáváme žádost o poskytnutí zpětné vazby k návrhu specifikace poskytovatelů lightningových služeb (LSP), probíráme těžkosti s otevíráním zero-conf kanálů spolu s dvojím financováním, díváme se na návrh pokročilých aplikací payjoin protokolu a odkazujeme na souhrn nedávného osobního setkání vývojářů Bitcoin Core. Dále začleňujeme první část nové série o pravidlech přeposílání transakcí a začleňování do mempoolu. Též nechybí naše pravidelné rubriky s oznámeními o nových vydáních (včetně bezpečnostního vydání libsecp256k1) a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Testování HTLC atestací: před několika týdny zaslaly Carla Kirk-Cohen a Clara Shikhelman příspěvek do emailové skupiny Lightning-Dev o krocích, které ony spolu s dalšími lidmi plánují podniknout ve snaze otestovat myšlenku HTLC atestací (viz zpravodaj č. 239) jako součást souboru opatření pro zamezení útoku zahlcením kanálu. Mimo jiné poskytly návrh specifikace, která by mohla být nasazena s použitím experimentálního příznaku, což by umožnilo bez potíží komunikovat s uzly, které tuto specifikaci neimplementují.

  Po nasazení v rámci experimentálního provozu by mělo být jednodušší odpovědět na jednu z konstruktivních kritik této myšlenky: kolika přeposílaným platbám by toto schéma ve skutečnosti pomohlo. Pokud si uživatelé LN často navzájem posílají platby přes množinu tras a pokud systém reputací funguje správně, měla by síť tvořená těmito uživateli být schopná ustát útok zahlcením kanálu. Avšak pokud většina odesílatelů posílá platby jen zřídka (nebo zřídka posílají nejkritičtější typ plateb jako jsou platby s vysokou hodnotou), potom nebudou mít dostatečné množství interakcí k vybudování reputace, nebo budou reputační data příliš zpožděna (což by dokonce mohlo umožnit zneužívání).

• ● Žádost o poskytnutí zpětné vazby k návrhu specifikace LSP: Severin Bühler zaslal do emailové skupiny Lightning-Dev příspěvek s žádostí o poskytnutí zpětné vazby ke dvěma specifikacím interoperability mezi poskytovateli lightningových služeb (LSP) a jejich klienty (obvykle LN uzly, které nepřeposílají platby). První specifikace popisuje API, které umožní uživatelům zakoupit od LSP kanál. Druhá popisuje API pro nastavení a správu JIT (Just-In-Time) kanálů, což jsou kanály, které jsou vytvořeny jako virtuální platební kanály a teprve po první platbě na tento kanál uveřejní LSP transakci, která tak po potvrzení ukotví kanál v blockchainu a učiní jej běžným kanálem.

  V odpovědi vyjádřil vývojář ZmnSCPxj souhlas s otevřenou specifikací pro LSP. Poznamenal, že díky tomu se mohou klienti připojit k více poskytovatelům a tím se vyhnout závislosti na jednom poskytovateli.

• ● Potíže s zero-conf kanály a dvojím financováním: Bastien Teinturier zaslal do emailové skupiny Lightning-Dev příspěvek o výzvách, které přináší vzájemné používání zero-conf kanálů a protokolu dvojího financování. Zero-conf kanály mohou být používány ještě před potvrzením otevírací transakce, což v některých případech nevyžaduje důvěru. Kanály s dvojím financováním jsou takové, jejichž otevírací transakce obsahuje vstupy obou účastníků (a jsou tedy financované oběma).

  Zero-conf nevyžaduje důvěru pouze v případě, kdy jeden z účastníků kontroluje všechny vstupy otevírací transakce. Příklad: Alice vytvoří otevírací transakci, poskytne Bobovi nějaké prostředky v kanálu a nato zkusí Bob poslat tyto prostředky Carol přes Alici. Alice může platbu bezpečně přeposlat, neboť ví, že konfirmace otevírací transakce je pod její kontrolou. Pokud však mám Bob také vstup v otevírací transakci, může nechat potvrdit konfliktní transakci, která nedovolí potvrzení otevírací transakce. To zabrání Alici vymáhat kompenzaci za peníze poslané Carol.

  Bylo probráno několik nápadů, jak umožnit otevírání zero-conf kanálů s dvojím financováním. V době psaní zpravodaje se žádný z těchto nápadů nejeví dostatečně uspokojující.

• ● Pokročilé aplikace payjoinu: Dan Gould zaslal do emailové skupiny Bitcoin-Dev příspěvek s několika návrhy na pokročilejší používání protokolu payjoin, než je jen prosté odesílání a přijímaní plateb. Dva z těchto návrhů, které nás nejvíce zaujaly, byly verze prořezání transakcí („transaction cut-through”), staré myšlenky na zvýšení soukromí a škálovatelnosti a snížení nákladů:

  • ● Přeposílání plateb: namísto platby přímo Bobovi může Alice zaplatit Bobovýmu prodejci (Carol) a tím snížit dluh, který Bob u ní má, nebo si předplatit budoucí útratu.

  • ● Dávkové přeposílání plateb: namísto platby přímo Bobovi může Alice zaplatit několika lidem, kterým Bob dluží peníze (nebo si u nich chce založit úvěr). Gouldův příklad uvažuje o směnárnách, které mají stálý tok vkladů a výběrů; payjoin umožňuje, aby výběry byly placeny novými vklady.

  Obě tyto techniky umožňují snížit počet transakcí z minimálně dvou na jednu jedinou, což ušetří významné množství prostoru. S použitím dávkování může být ušetřeného prostoru ještě více. Z pohledu původního příjemce (např. Bob) je navíc výhodné, že původní odesílatel (např. Alice) může platit všechny nebo část poplatků. Odstraňování transakcí z blockchainu a kombinování operací jako příjímání a utrácení též výrazně ztěžuje špehování finančních toků.

  V době psaní neobdržel příspěvek v emailové skupině žádné reakce.

• ● Souhrn osobních setkání vývojářů Bitcoin Core: někteří vývojáři pracující na Bitcoin Core se nedávno sešli, aby prodiskutovali některé aspekty projektu. Byly publikovány poznámky z několika diskuzí uskutečněných během setkání. Mezi tématy nechybělo fuzz testování, assumeUTXO, ASMap, tiché platby, libbitcoinkernel, refaktorování (či ne) a přeposílání balíčků. Dále byla diskutována dvě další témata, které si podle nás zaslouží zvláštní pozornost:

  • ● Mempool clustering shrnuje návrh na významný redesign ukládání transakcí a jejich metadat v mempoolu Bitcoin Core. Poznámky popisují množství problémů se současným designem, poskytují přehled nového designu a ukazují na některé potíže a kompromisy. Později byl uveřejněn popis designu a kopie slajdů prezentace.

  • ● Meta-diskuze o projektu shrnuje pestrou diskuzi o cílech projektu a jak jich docílit navzdory mnoha překážkám vnitřním i vnějším. Některé z debat vedly již k pokusným změnám ve správě projektu, jako je více projektově orientovaný přístup pro budoucí vydání následující verzi 25.

Čekání na potvrzení 1: k čemu je mempool?

První část krátké týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji.

Množství uzlů v bitcoinové síti ukládá nepotvrzené transakce v memory poolu (tj. v předem alokovaném znovupoužitelném bloku paměti); odtud „mempool.” Tato mezipaměť je důležitým zdrojem každého uzlu, který umožňuje peer-to-peer přeposílání transakcí.

Uzly, které se přeposílání transakcí účastní, stahují a validují bloky postupně. Uzly bez mempoolu zaznamenávají každých zhruba deset minut špičku v datovém přenosu následovanou výpočetně náročnou validací každé transakce. Na druhou stranu uzly s mempoolem již mají pravděpodobně v mempoolu všechny transakce z bloku uložené. Díky přeposílání kompaktních bloků mohou tyto uzly stáhnout pouze hlavičku bloku spolu se zkrácenými identifikátory a následně blok rekonstruovat z transakcí v mempoolu.

Množství přenášených dat je v případě používání kompaktních bloků v porovnání s velikostí celého bloku minimální. Validace transakcí probíhá rychleji, neboť uzel již ověřil a uchoval elektronické podpisy a skripty, spočítal požadavky časových zámků a načetl z disku související UTXO. Tento uzel může také okamžitě přeposlat blok svým spojením a tím dramaticky zvýšit rychlost propagace bloku. Rychlost rozšiřování bloku po síti snižuje riziko objevení zastaralých bloků.

Mempooly mohou též sloužit k nezávislému odhadování poplatků. Trh s prostorem pro bloky je aukcí založenou na poplatcích, mempool tak dává uživatelům lepší přehled o nabídkách ostatních účastníků a poskytuje historii nabídek.

Neexistuje však žádný globální, sdílený mempool; každý uzel může přijímat jiné transakce. Zaslání transakce jednomu uzlu neznamená, že se nakonec dostane k těžařům. Někteří uživatelé považují tuto nejistotu za frustrující a táží se, proč nelze transakce zasílat přímo těžařům.

Představme si bitcoinovou síť, ve které jsou všechny transakce posílány od uživatelů přímo těžařům. Bylo by snadné donutit několik malých subjektů k logování IP adres odpovídajících jednotlivým transakcím a tím cenzurovat transakce a sledovat finanční toky. Takový bitcoin by se možná používal pohodlněji, ale postrádal by některé z nejdůležitějších vlastností.

Soukromí a odolnost vůči cenzuře jsou vlastnosti vycházející z peer-to-peer sítě. Aby mohly uzly transakce přeposílat, mohou se připojit k anonymní množině uzlů, z nichž každý by mohl být těžař nebo někdo k těžařovi připojený. Tento způsob pomáhá zmást stopy k uzlu, od kterého transakce pochází a který ji potvrdil. Cenzor by mohl cílit na některé těžaře, populární směnárny či jiné centralizované služby, ale bylo by náročné blokovat zcela všechno.

Přístup k nepotvrzeným transakcím dále pomáhá minimalizovat vstupní náklady zahájení produkce bloků: kdokoliv nespokojený s výběrem transakcí (nebo jejich vylučováním) se může okamžitě stát dalším těžařem. Považovaní všech uzlů za rovnocenné při zveřejňování transakcí odpírá těžařům výsadní přístup k transakcím a jejím poplatkům.

Mempool je mimořádně užitečná mezipaměť, která umožňuje uzlům rozložit v čase náklady na stahování a validaci bloků a která dává uživatelům přístup k lepšímu odhadování poplatků. Na úrovni sítě podporují mempooly distribuci transakcí a bloků. Všechny tyto výhody jsou nejvýraznější v případě, kdy každý vidí všechny transakce před tím, než je těžaři začlení do bloků. Jako kterákoliv jiná mezipaměť, i mempool je nejužitečnější, když je často používaný. Musí být také omezen na velikosti, aby mohl být obsažen v paměti. Příští týden se podíváme na slučitelnost pobídek jako metriku držení nejužitečnějších transakcí v mempoolech.

Vydání nových verzí

Vydání nových verzí oblíbených páteřních bitcoinových projektů. Prosíme, zvažte upgrade či pomoc s testováním.

• ● Libsecp256k1 0.3.2 je bezpečnostním vydáním pro aplikace, které používají libsecp pro ECDH a které mohou být kompilovány GCC verzí 13 a vyšší. Jak bylo autory popsáno, nová verze GCC se snaží optimalizovat kód libsecp, který byl navržen tak, aby běžel v pevném množství času. Kvůli optimalizaci je možné za určitých podmínek spustit útok postranními kanály. Patří se poznamenat, že Bitcoin Core ECDH nepoužívá. Vývojáři pracují na mechanismu detekce podobných problémů v budoucnosti.

• ● Core Lightning 23.05rc2 je kandidátem na vydání příští verze této implementace LN.

• ● Bitcoin Core 23.2rc1 je kandidátem na údržbové vydání předešlé hlavní verze Bitcoin Core.

• ● Bitcoin Core 24.1rc3 je kandidátem na údržbové vydání současné verze Bitcoin Core.

• ● Bitcoin Core 25.0rc2 je kandidátem na vydání příští hlavní verze Bitcoin Core.

Významné změny v kódu a dokumentaci

Významné změny z tohoto týdne v Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs a Bitcoin Inquisition.

• ● Bitcoin Core #26076 aktualizuje RPC metody, které zobrazují derivační cesty veřejných klíčů: pro indikaci hardened derivace se namísto jednoduché uvozovky ' bude používat h. Tato změna má vliv na kontrolní součet deskriptoru. Při nakládání s deskriptory obsahující privátní klíče je použit shodný symbol s deskriptory, které byly vygenerovány nebo importovány. Pro zastaralé peněženky zůstávají pole hdkeypath v getaddressinfo a serializační formát nezměněny.

• ● Bitcoin Core #27608 bude pokračovat v pokusech o stažení bloku od spojení, i když jiné spojení tento blok již poskytlo. Bitcoin Core bude pokračovat ve stahování, dokud není jeden z obdržených bloků zapsán na disk.

• ● LDK #2286 umožňuje vytváření a podepisování PSBT pro výstupy kontrolované lokální peněženkou.

• ● LDK #1794 přináší počátek podpory dvojího financování. Prvně byly přidány metody potřebné pro interaktivní protokol financování.

• ● Rust Bitcoin #1844 určuje, že schéma v BIP21 adresách bude malými písmeny, tedy bitcoin:. I když specifikace URI (RFC3986) říká, že schéma nerozlišuje malá a velká písmena, testy ukazují, že některé platformy neotevírají aplikace přiřazené k URI bitcoin:, je-li použito schéma s velkými písmeny BITCOIN:. Bylo by výhodnější použít velká písmena, neboť to umožňuje efektivnější vytváření QR kódů (viz zpravodaj č. 46, angl.).

• ● Rust Bitcoin #1837 přidává funkci pro generování nového privátního klíče. Oproti předchozí implementaci došlo ke zjednodušení tvorby privátních klíčů.

• ● BOLTs #1075 upravuje specifikaci tak, aby se uzly již neodpojovaly po obdržení varovné zprávy od spojení.