Zpravodaj tento týden popisuje návrh na rozšíření LN o podporu poplatků předem a za držení založených na spalitelných výstupech, shrnuje diskuzi o testnetech 3 a 4 (včetně návrhu na hard fork) a oznamuje záměr začít přeposílat určité transakce s taprootovými přílohami. Též nechybí naše pravidelné rubriky se souhrnem vybraných otázek a odpovědí z Bitcoin Stack Exchange, oznámeními nových vydání a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

• ● Poplatky předem a za držení v LN použitím spalitelných výstupů: John Law zaslal do fóra Delving Bitcoin příspěvek se souhrnem svého článku o protokolu, který mohou uzly použít pro vyžadování dvou nových druhů poplatků za přeposílání plateb. Konečný odesílatel by platil poplatek předem (upfront fee) jako odměnu přeposílajícím uzlům za dočasné využívání HTLC slotu (tedy jednoho z omezeného počtu souběžných alokací dostupných v kanálu pro vynucování HTLC). Uzel, který pozdrží urovnání HTLC, by platil poplatek za držení (hold fee), jehož výše by byla úměrná délce držení až do dosažení maximální částky v okamžiku expirace HTLC. Jeho příspěvek i článek citují několik předchozích diskuzí o těchto poplatcích, včetně těch shrnutých ve zpravodajích č. 86, č. 119, č. 120, č. 122, č. 136 (vše angl.) a č. 263.

  Navržený protokol staví na myšlenkách Lawova protokolu offchain vyrovnávání plateb (offchain payment resolution, OPR, viz zpravodaj č. 329), dle kterého každý ze spoluvlastníků kanálu alokuje 100 % dotyčných prostředků (tedy 200 % dohromady) na spalitelný výstup, který může být kterýmkoliv z nich jednostranně zničen. Dotyčnými prostředky jsou v tomto případě poplatky předem plus maximální poplatky za držení. Pokud jsou později obě strany spokojené s postupem protokolu, např. pokud jsou všechny poplatky řádně zaplacené, odstraní spalitelný výstup z budoucích verzí svých offchain transakcí. Je-li některá ze stran nespokojená, zavře kanál a zničí spalitelné prostředky. I když v tomto případě nespokojená strana též tratí, stejně tak je tomu u druhé strany, žádná strana tedy na porušení protokolu nevydělá.

  Law popisuje tento protokol jako řešení útoků zahlcením kanálu, zranitelnosti poprvé popsané před téměř deseti lety, která útočníkovi umožňuje téměř bez nákladů bránit druhé straně ve využívání jeho prostředků. Jedna odpověď poznamenala, že díky přidání poplatků za držení jsou pozdržené faktury pro síť udržitelnější.

• ● Diskuze o testnetech 3 a 4: Sjors Provoost zaslal do emailové skupiny Bitcoin-Dev příspěvek s dotazem, zda šest měsíců po aktivaci testnet4 (viz zpravodaj č. 315) stále někdo používá testnet3. Andres Schildbach ve své odpovědi popisuje záměr pokračovat nejméně další rok v používání testnet3 v testovací verzi jeho populární peněženky. Olaoluwa Osuntokun poznamenal, že testnet3 je poslední dobou mnohem stabilnější než testnet4, což ilustroval na přiloženém screenshotu webové stránky Fork.Observer obsahující strom bloků z obou testnetů. Níže přikládáme náš vlastní screenshot ukazující stav testnet4 v době psaní:

  

  Po Osuntokunově příspěvku začal Antoine Poinsot nové vlákno soustřeďující se na problémy s testnet4. Dle jeho názoru jsou problémy s testnet4 důsledkem pravidla resetování složitosti. Toto pravidlo (týkající se pouze testnetů) umožňuje, aby byl blok validní i s minimální složitostí, pokud je časové razítko v jeho hlavičce 20 minut po předchozím bloku. Provoost v popisu problémů zachází ještě hlouběji. Poinsot navrhuje, aby hard fork testnet4 toto pravidlo odstranil. Mark Erhardt navrhuje jako jeho datum 8. ledna 2026.

• ● Plán na přeposílání některých taprootových příloh: Peter Todd v emailové skupině Bitcoin-Dev oznámil, že plánuje v Libre Relay, svém uzlu založeném na Bitcoin Core, přeposílat transakce obsahující taprootové přílohy (annex), pokud jsou splněna tato dvě pravidla:

  • Prefix 0x00: „Všechny neprázdné přílohy začínají bajtem 0x00, aby byly odlišeny od budoucích příloh týkajících se konsenzu.”

  • Žádné nebo všechny: „Všechny vstupy obsahují přílohu. To zajistí, aby byly přílohy volitelné, což v protokolech s více stranami zabrání pinningu transakcí.”

  Plán je založen na pull requestu z roku 2023 od Joosta Jagera, který je dále založen na předchozí diskuzi započaté Jagerem (viz zpravodaj č. 255). V Jagerových slovech měl předchozí pull request také „omezení maximální velikosti nestrukturovaných dat v příloze na 256 bajtů, […] což má účastníky chránit v transakci s více stranami, která používá tuto přílohu proti nafukování příloh.” Toddova verze toto pravidlo neobsahuje, protože věří, že „požadavek na volitelnost příloh by měl být dostatečný.” Pokud by nebyl, učinil by v přeposílání další změny.

  V době psaní zpravodaje ve vlákně nikdo nepopsal, jak by příloh využil.

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ů.

• ● Proč je commitment witnessu volitelný? Pieter Wuille a Antoine Poinsot vysvětlují BIP30 „duplikované transakce”, BIP34 „blok v2 a výšku v coinbase” a souvislost pročištění konsenzu s problémem bloku 1 983 702 a jak by povinný commitment witnessu tento problém řešil.

• ● Mohou být všechny platné 64bajtové transakce pozměněny třetí stranou ke zvýšení velikosti? Sjors Provoost zkoumá myšlenku poddajnosti libovolné 64bajtové transakce, která by byla konsenzuálně nevalidní, pokud by byl aktivován soft fork pročištění konsenzu. Antoine Poinsot dodává, že takovým transakcím je možné přidat více vstupů nebo výstupů a zvýšit jejich velikost.

• ● Jak dlouho trvá transakci propagace celou sítí? Sr_gi poznamenává, že jediný uzel není schopen čas propagace celou sítí měřit a že by pro měření a odhad bylo potřeba mít přístup k více uzlům. Dodává, že webová stránka, kterou provozuje Decentralized Systems and Network Services Research Group při KIT, měří mimo jiné čas propagace transakcí: „transakci trvá kolem sedmi sekund dosáhnout 50 % sítě a potřebuje kolem 17 sekund na 90 %.”

• ● Použitelnost dlouhodobých odhadů poplatků Abubakar Sadiq Ismail hledá pro svou práci na odhadování poplatků zpětnou vazbu od projektů, protokolů nebo uživatelů, kteří na dlouhodobé odhady spoléhají.

• ● Proč jsou v LN používány dva anchor výstupy? Instagibbs nabízí historický kontext anchor výstupů používaných v současnosti v LN a dodává, že se změnami pravidel Bitcoin Core v 28.0 se plánuje update na v3 commitmenty.

• ● Proč nejsou v 2xx rozsahu žádné BIPy? Michael Folkson poznamenává, že BIP čísla 200–299 byla v jednu chvíli rezervována pro Lightning Network.

• ● Proč není v Bech32 používáno písmeno „b”? Bordalix v odpovědi poznamenává, že kvůli podobnosti s „8” není „B” ve formátech bech32 a bech32m povoleno. Dále poskytuje další informace o bech32.

• ● Referenční implementace detekce a korekce chyb z Bech32 Pieter Wuille poznamenává, že bech32 umí v adrese detekovat až čtyři chyby a opravit dvě.

• ● Jak bezpečně utratit/propálit prach? Murch vyjmenovává, co je třeba uvážit během pokusu o odeslání prachu z existující peněženky.

• ● Jak je konstruována refundovací transakce v asymetrických revokovatelných commitmentech? Biel Castellarnau prochází příklady commitment transakcí z knihy Mastering Bitcoin.

• ● Které aplikace používají ZMQ s Bitcoin Core? Sjors Provoost hledá uživatele ZMQ služeb poskytovaných Bitcoin Core v rámci zjišťování, zda by IPC mohlo jeho používání nahradit.

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.

• ● Bitcoin Core 29.0rc2 je kandidátem na vydání příští hlavní verze převládající implementaci plného uzlu. Viz též průvodce testováním verze 29.

• ● LND 0.19.0-beta.rc1 je kandidátem na vydání tohoto oblíbeného LN uzlu. Jedním významným vylepšením, které by si zasloužilo důkladné testování, je nové schéma RBF navyšování poplatků během kooperativního zavření kanálu popsané níže ve významných změnách.

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

• ● Bitcoin Core #31603 bude odmítat veřejné klíče začínající nebo končící mezerou během parsování v ParsePubkeyInner. Tím bude mít stejné chování jako rust-miniscript. Přidávat nahodile mezery by nemělo být díky ochraně kontrolním součtem možné. RPC příkazy getdescriptorinfo a importdescriptors budou nově hlásiti chybu, pokud veřejný klíč v deskriptoru bude obsahovat mezeru.

• ● Eclair #3044 navyšuje minimální počet konfirmací pro založení kanálu z šesti na osm z důvodu zabezpečení. Dále odstraňuje změny této hodnoty v přímé úměře k částce, protože kapacita kanálu se může během splicingu výrazně měnit a uzel by tak mohl přijmout nízký počet konfirmací i pro vysoké částky.

• ● Eclair #3026 přidává podporu pro peněženky Bitcoin Core používající Pay-to-Taproot (P2TR) adresy včetně peněženek pouze pro sledování spravované Eclairem. Jedná se o základ pro implementaci jednoduchých taprootových kanálů. Pro některá kooperativní zavření kanálu jsou stále vyžadované P2WPKH skripty i s P2TR peněženkami.

• ● LDK #3649 přidává podporu pro placení poskytovatelům lightningových služeb (LSP) BOLT12 nabídkami. Dříve to bylo možné pouze pomocí BOLT11 a onchain plateb. Viz též návrh v BLIPs #59.

• ● LDK #3665 navyšuje maximální přípustnou velikost BOLT11 faktury z 1 023 bajtů na 7 089 bajtů, což odpovídá limitu v LND. Tato hodnota je založena na maximálním množství bajtů, které se mohou vměstnat do QR kódu. Autor PR se domnívá, že QR kódy kompatibilní s kódováním v BOLT11 fakturách jsou ve skutečnosti omezené na 4 296 znaků, ale hodnota 7 089 byla zvolena, protože „široký soulad je asi důležitější.”

• ● LND #8453, #9559, #9575, #9568 a LND #9610 přináší kooperativní zavření s RBF dle BOLTs #1205 (viz zpravodaj č. 342), které umožní kterékoliv straně navýšit poplatek použitím svých vlastních prostředků v kanálu. Dříve musela někdy jedna ze stran přesvědčit druhou, aby zaplatila za navýšení poplatku, což často vyústilo v selhání. Pro použití musí být aktivní konfigurační příznak protocol.rbf-coop-close.

• ● BIPs #1792 přináší změny do BIP119, který specifikuje OP_CHECKTEMPLATEVERIFY. Objasňuje text, odstraňuje logiku aktivace, mění zmínky o Eltoo na LN-Symmetry a nově zmiňuje nové návrhy kovenantů a projektů jako Ark, které OP_CTV používají.

• ● BIPs #1782 zvyšuje čitelnost a zřetelnost specifikace BIP94, který vypisuje pravidla konsenzu v testnet4.