Zpravodaj tento týden shrnuje výzkum odhadování pravděpodobnosti proveditelnosti LN plateb. Též nechybí naše pravidelné rubriky s popisem populární otázek a odpovědí z Bitcoin Stack Exchange, oznámeními o nových vydáních a souhrnem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Odhad pravděpodobnosti úspěšného provedení LN platby: René Pickhardt zaslal do fóra Delving Bitcoin příspěvek o odhadování pravděpodobnosti, zda je LN platba proveditelná. Pro odhad je použita pouze veřejná znalost maximální kapacity kanálů, nikoliv aktuální distribuce zůstatků. Například má-li Alice kanál s Bobem a Bob má kanál s Carol, zná Alice kapacitu kanálu Bob–Carol, avšak neví, jaká část této kapacity je na Bobově straně a jaká část je pod kontrolou Carol.

    Pickhardt poznamenává, že některá rozložení zůstatku nejsou v síti možná. Například Carol nemůže kanálem od Boba obdržet více peněz, než kolik je celá kapacita kanálu. Pokud vyloučíme všechna nemožná rozložení, může být užitečné považovat všechna ostatní rozložení za shodně pravděpodobná. Díky tomu je možné vytvořit metriku pravděpodobnosti, že platba je proveditelná.

    Mějme příklad, ve kterém chce Alice poslat 1 BTC Carol a jediné možné kanály jsou Alice–Bob a Bob–Carol. Můžeme se potom podívat, jaká procenta distribuce prostředků v kanálech Alice–Bob a Bob–Carol by mohla vést k úspěšnému provedení této platby. Má-li kanál Alice–Bob kapacitu několika BTC, většina možných rozdělení by umožnila úspěšnou platbou. Má-li kanál Bob–Carol kapacitu jen málo přes 1 BTC, většina možných rozdělení prostředků by platbě zabránila. To může být použito k výpočtu celkové pravděpodobnosti proveditelnosti platby 1 BTC mezi Alicí a Carol.

    Pravděpodobnost provedení platby ukazuje, že mnoho LN plateb, které se na první pohled zdají možné, ve skutečnosti neuspěje. Dále poskytuje užitečný základ pro další porovnání. Ve své odpovědi popisuje Pickhardt, jak by metrika pravděpodobnosti mohla být použita peněženkami a business software k provádění některých automatických rozhodnutí za uživatele.

Vybrané otázky a odpovědi z Bitcoin Stack Exchange

Bitcoin Stack Exchange je jedním z prvních míst, kde hledají přispěvatelé Optechu odpovědi na své otázky a kde – najdou-li volnou chvíli – pomáhají zvědavým či zmateným uživatelům. V této měsíční rubrice nabízíme některé z otázek a odpovědí, které obdržely vysoký počet hlasů.

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.

  • ● LND v0.18.1-beta je menší vydání s opravou „problému, který se objevuje během vypořádání se s chybou způsobenou pokusem o zveřejnění transakce s btcd backendem starší verze (před v0.24.2).”

  • ● Bitcoin Core 26.2rc1 je kandidátem na vydání údržbové verze série starších vydání Bitcoin Core.

Významné změny kódu a dokumentace

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, Bitcoin Inquisition a repozitáři BINANA.

  • ● Bitcoin Core #29575 zjednodušuje systém hodnocení špatného chování spojení tím, že používá pouze dva inkrementy: 100 bodů (znamenající okamžité odpojení a odrazování) a 0 bodů (chování akceptováno). Většině druhů špatného chování se lze vyhnout a bylo jim přiřazeno skóre 100. Dva typy chování, které mohou za určitých okolností vykazovat čestné a správně fungující uzly, byly sníženy na 0 bodů. Toto PR dále odstraňuje heuristiku, která pokládala pouze P2P zprávy headers s nejvýše osmi hlavičkami bloků za možná oznámení nových bloků dle BIP130. Bitcoin Core bude nově pokládat všechny zprávy headers, které nepřipojují ke známému stromu bloků, jako potenciální oznámení o nových blocích a žádosti o chybějící bloky.

  • ● Bitcoin Core #28984 přidává podporu omezené verze nahrazování poplatkem (RBF) pro balíčky velikost clusteru dva (jeden rodič, jeden potomek) včetně TRUC transakcí (do potvrzení topologicky omezených, známé též jako v3 transakce). Tyto clustery mohou nahradit pouze existující clustery stejné nebo menší velikost. Zpravodaj č. 296 obsahuje další informace.

  • ● Core Lightning #7388 odstraňuje schopnost vytvářet anchorové kanály s nenulovým poplatkem. Tím dosáhne souladu se změnami v BOLT specifikaci představenými v roce 2021 (viz zpravodaj č. 165, angl.). Podpora pro existující kanály zůstává zachována. Core Lightning byl jedinou implementací, která podporu přidala (a to pouze v experimentálním režimu) před tím, než bylo zjištěno, že se nejedná o bezpečné schéma (viz zpravodaj č. 115, angl.), a než bylo nahrazeno anchory s nulovými poplatky. Mezi dalšími změnami je odmítání encrypted_recipient_data obsahující zároveň scid i node, zpracovávání LaTeXového formátu přidaného do onion specifikace a další změny zmíněné ve zpravodajích č. 259 a č. 305.

  • ● LND #8734 vylepšuje nakládání s uživatelem přerušeným procesem odhadu poplatku za cestu (lncli estimateroutefee). Dříve server i po přerušení tohoto příkazu pokračoval ve zbytečném sondování. Zpravodaj č. 293 též zmiňuje tento RPC příkaz.

  • ● LDK #3127 implementuje nestriktní přeposílání dle specifikace v BOLT4, které by mělo vylepšit spolehlivost plateb tím, že umožní přeposílat HTLC i přes kanály, které nejsou v onion zprávě specifikovány jako short_channel_id. Vybrány jsou vhodné kanály s nejnižší odchozí likviditou, aby byla maximalizována pravděpodobnost úspěchu budoucích HLTC.

  • ● Rust Bitcoin #2794 implementuje vynucování limitu velikosti redeem skriptu 520 bajtů u P2SH a limitu velikosti witness skriptu 10 000 bajtů u P2WSH. Konstruktory pro ScriptHash a WScriptHash tak mohou nově vrátit chybu.

  • ● BDK #1395 odstraňuje závislost na rand a nahrazuje ji rand-core. Tím se zjednodušil strom závislostí, odstranila se složitost thread_rng a getrandom a uživatelům byla umožněna větší flexibilita možností poskytnout vlastní generátor náhodných čísel.

  • ● BIPs #1620 a BIPs #1622 přidávají změny do specifikace BIP352 tichých plateb. První změnou je ošetření nevalidních součtů soukromých i veřejných klíčů pro posílání a skenování: pokud je soukromý klíč nulový nebo veřejný klíč je bodem v nekonečnu. #1622 mění provádění kalkulace input_hash po agregaci klíčů (dříve byla prováděna před agregací), čímž se proces zjednoduší.

  • ● BOLTs #869 přidává do BOLT2 nový protokol quiescence („chvíle ticha“), díky kterému budou upgradování protokolu a změny platebních kanálů bezpečnější a efektivnější. Protokol představuje novou zprávu stfu (SomeThing Fundamental is Underway čili „něco velkého se děje”; též zkratka vulgární žádosti o ticho), která může být poslána, pokud je přítomna volba option_quiesce. Po odeslání stfu nebude odesílatel posílat žádné další aktualizace. Příjemce by rovněž měl pozastavit posílání všech aktualizací stavu a odpovědět stfu, pokud možno. Kanál by tak měl být zcela tichý. Viz též zpravodaje č. 152 (angl.) a č. 262.