/ home / newsletters /
Zpravodaj „Bitcoin Optech” č. 325
Zpravodaj tento týden nahlíží na některá témata diskutovaná během nedávného setkání vývojářů LN. Též nechybí naše pravidelné rubriky s popisem změn v oblíbených klientech a službách, oznámeními nových vydání a souhrnem významných změn v populárním bitcoinovém páteřním software.
Novinky
-
● Poznámky z LN summitu 2024: Olaoluwa Osuntokun zaslal do fóra Delving Bitcoin příspěvek se souhrnem svých poznámek (a dodatečným komentářem) z nedávné konference vývojářů LN. Mezi diskutovaná témata patřilo:
-
● Commitment transakce verze 3: vývojáři diskutovali, jak používat nové možnosti v P2P včetně TRUC transakcí a P2A výstupů pro navýšení bezpečnosti LN commitment transakcí, které mohou být použity pro jednostranné uzavření kanálu. Diskuze se soustředila na rozličné kompromisy během navrhování.
-
● PTLC: jsou dlouho navrhované jako způsob pro navýšení soukromí v LN i pro další možné účely jako například stuckless transactions. Byl diskutován nedávný průzkum kompromisů ohledně možných implementací PTLC (viz zpravodaj č. 268). Zvláštní důraz byl kladen na konstrukci signature adaptorů (např. pomocí skriptového multisigu v kontrastu s bezskriptovým MuSig2) a jejich dopadu na protokol commitmentů (viz další bod).
-
● Protokol aktualizování stavu: byl diskutován návrh na změnu současného protokolu aktualizace stavu kanálů. Nyní je možné, aby kterákoliv strana navrhla aktualizaci stavu; nově by to měla být v danou chvíli jen jedna strana (viz též zpravodaje č. 120, angl., a č. 261). Je-li oběma stranám umožněno navrhnout aktualizaci, můžou návrh podat obě strany najednou. Takové situace by byly náročné na řešení a mohly by vést k nezamýšlenému zavření kanálu. Alternativou je, aby v daný okamžik mohla navrhnout aktualizaci jen jedna ze stran. Např. zprvu je pouze Alici umožněno navrhnout aktualizaci stavu. Pokud žádný návrh nepodá, může připustit k navrhování Boba. Když Bob ukončí své návrhy, může předat kontrolu zpět Alici. Takový protokol je snadnější na uchopení, odstraňuje problémy vzniklé souběžnými návrhy a usnadňuje protistraně nechtěné návrhy odmítnout. Podobný protokol by byl navíc lépe v souladu se signature adaptory založenými na MuSig2.
-
● SuperScalar: vývojář návrhu jednoho konstruktu továren kanálů přednesl svůj návrh a obdržel zpětnou vazbu. Optech v budoucím čísle představí SuperScalar podrobněji.
-
● Upgrade gossip protokolu: vývojáři diskutovali aktualizace gossip protokolu pro LN. Převážně jsou potřebné pro podporu nových typů zakládajících transakcí (např. jednoduché taprootové kanály), ale mohou být užitečné též pro přidání jiných schopností. Jedna z nich, o které se také diskutovalo, bylo přidání SPV dokladu (nebo jeho závazku) do zpráv oznamujících kanály. Díky tomu by mohly lehké klienty ověřit, že byla financující (nebo sponzorující) transakce začleněna do nějakého bloku.
-
● Výzkum fundamentálních limitů: byl představen výzkum o platebních tocích, které kvůli limitům v síti (např. kanály s nedostatečnou kapacitou) nemohou skončit úspěšně (viz též zpravodaj č. 309). V případě nerealizovatelné LN platby mohou účastníci vždy přistoupit k onchain platbě. Avšak počet onchain plateb je omezen maximální vahou bloku, je tedy možné vypočítat maximální propustnost (počet plateb za sekundu) bitcoinu a LN dohromady vydělením maximálního počtu onchain plateb počtem neproveditelných LN plateb. Z tohoto hrubého vztahu vychází, že pro dosažení maximální propustnosti kolem 47 000 plateb za sekundu musí být poměr neproveditelnosti pod 0,29 %. Byly diskutovány dvě techniky redukce poměru neproveditelnosti: za prvé virtuální či skutečné kanály s více než dvěma účastníky, neboť více stran znamená více prostředků pro přeposílání a tedy vyšší míru proveditelnosti. Za druhé kanály s kreditem, kde důvěryhodné strany mohou mezi sebou přeposílat platby, aniž by je mohly vynutit onchain (ostatní jim stále důvěřovat nemusí).
Osuntokun vyzval ostatní účastníky o korekce a rozšíření.
-
Změny ve službách a klientech
V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.
-
● Coinbase podporuje posílání na taproot: Směnárna Coinbase nově podporuje výběry na taprootové bech32m adresy.
-
● Vydána peněženka Dana: Peněženka Dana je peněženkou pro tiché platby, která se zaměřuje na darování. Vývojáři doporučují používat na signetu a též provozují signetový faucet.
-
● Vydán lehký klient pro BIP157/158 Kyoto: Kyoto je rustový lehký klient pro vývojáře peněženek používající kompaktní filtry bloků.
-
● DLC Markets spuštěn na mainnetu: Tato platforma založená na DLC oznámila mainnetovou dostupnost svých nekustodiálních služeb pro obchodování.
-
● Ohlášena peněženka Ashigaru: Ashigaru je forkem projektu Samourai Wallet, oznámení zmiňuje vylepšení dávkového posílání, podpory RBF a odhadu poplatků.
-
● Ohlášen protokol DATUM: Těžební protokol DATUM umožňuje těžařům sestavovat kandidáty bloků jako součást sdílené těžby, vykazuje podobnosti s protokolem Stratum v2.
-
● Ohlášena implementace Arku Bark: Tým Second ohlásil Bark, implementaci protokolu Ark, a ukázal živé arkové transakce na mainnetu.
-
● Vydány Phoenix v2.4.0 a phoenixd v0.4.0: Vydání Phoenix v2.4.0 a phoenixd v0.4.0 přidávají podporu pro financování za běhu dle návrhu BLIP36 a další možnosti pro práci s likviditou (viz podcast č. 323).
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.
- ● BDK 1.0.0-beta.5 je kandidátem na vydání této knihovny pro budování
peněženek a jiných aplikací s podporou bitcoinu. Tento kandidát „aktivuje
ve výchozím nastavení RBF a klient bdk_esplora se bude po selhání opakovaně
zkoušet znovu připojit. Balíček
bdk_electrum
také nově nabízí konfigurační příznakuse-openssl
.”
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 #30955 přidává do rozhraní
Mining
(viz zpravodaj č. 310) dvě nové metody vyžadované pro podporu Stratum V2. MetodasubmitSolution()
umožňuje těžařům odeslat řešení bloku efektivněji: namísto celého bloku se odesílají pouze nonce, časové razítko, pole s verzemi a coinbasová transakce. Druhou metodou jegetCoinbaseMerklePath()
, která vrátí cestu Merkleovým stromem požadovanou zprávouNewTemplate
. PR dále do kódu vracíBlockMerkleBranch
odstraněnou v Bitcoin Core #13191. -
● Eclair #2927 přidává vynucování doporučených jednotkových poplatků (viz zpravodaj č. 323) při financování za běhu (viz zpravodaj č. 323) tím, že bude odmítat zprávy
open_channel2
asplice_init
, pokud používají jednotkový poplatek nižší. -
● Eclair #2922 odstraňuje podporu pro splicing bez předem iniciované chvíle ticha (quiescence, viz zpravodaj č. 309). Bude tak odpovídat poslední verzi protokolu z BOLTs #1160, která po každém uzlu požaduje během splicingu používat chvíli ticha.
-
● LDK #3235 přidává do události
ChannelForceClosed
polelast_local_balance_msats
, které obsahuje místní zůstatek uzlu těsně před vynuceným zavřením kanálu. Uživatel tak bude moci zjistit ztrátu milisatoshi způsobenou zaokrouhlováním. -
● LND #8183 přidává do struktury
chanbackup.Single
volitelné poleCloseTxInputs
, které umožní přidat do souboru se statickou zálohou kanálu vstupy potřebné pro vygenerování transakce vynuceného zavření. Díky tomu budou moci uživatelé manuálně obdržet od offline spojení prostředky pomocí příkazuchantools scbforceclose
jako poslední možnost. Uživatelé by měli být obzvláště opatrní, neboť by tato akce mohla vést ke ztrátě prostředků v případě, pokud od poslední zálohy nastala změna. PR dále přidává metoduManualUpdate
, která aktualizuje zálohu kanálů během ukončování LND. -
● Rust Bitcoin #3450 přidává v3 jako novou variantu verze transakce. Bitcoin Core nově považuje tyto transakce, označované též jako transakce do potvrzení topologicky omezené (TRUC), za standardní. Viz též zpravodaj č. 307.