/ home / newsletters /
Zpravodaj „Bitcoin Optech” č. 281
Tento týden přinášíme souhrn diskuze o záškodnických inzerátech likvidity a připojujeme naše pravidelné rubriky s popisem změn ve službách a klientském software, souhrnem oblíbených otázek a odpovědí z Bitcoin Stack Exchange, oznámeními o nových softwarových vydáních a přehledem nedávných změn v populárním bitcoinovém páteřním software.
Novinky
-
● Diskuze o záškodnických inzerátech likvidity: Bastien Teinturier zaslal do emailové skupiny Lightning-Dev příspěvek s popisem možného problému s časovými zámky kanálů s oboustranným vkladem („dual-funded channels”) vytvořených z inzerátů likvidity („liquidity ads”). Problém byl již dříve zmíněn v rekapitulaci č. 279. Příklad: Alice inzeruje, že je za poplatek ochotna poskytnout svých 10 000 satoshi nějakému kanálu na 28 dní. Tento 28denní časový zámek zaručuje, že Alice nebude moci po obdržení platby jen tak zavřít kanál a použít své prostředky k jiným účelům.
Dále v tomto příkladu Bob otevře kanál s dodatečným přispěním svých prostředků ve výši 100 000 000 satoshi (1 BTC). Tímto kanálem potom pošle téměř všechny své prostředky. Na Alicině straně však nyní není 10 000 satoshi, za které obdržela poplatek, ale téměř 10 000× více. Má-li Bob zlé úmysly, nedovolí Alici až do vypršení 28denního časového zámku její prostředky použít.
Opatření navržené Teinturierem a diskutované spolu s ostatními spočívá v aplikaci časového zámku pouze na příspěvek pocházející z likvidity (čili v našem případě 10 000 satoshi). To navyšuje složitost a neefektivitu, ale může to problém vyřešit. Jiným Teinturierovým návrhem bylo jednoduše časový zámek zavrhnout (nebo ho učinit volitelným) a nechat na příjemci likvidity riziko, že poskytovatel může krátce po obdržení poplatku za likviditu kanál zavřít. Pokud by v typickém případě kanály otevřené pomocí inzerátů likvidity generovaly významný příjem na poplatcích, bylo by v zájmu provozovatelů je nechat otevř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.
-
● Spuštěn těžební pool se Stratum v2: DEMAND je těžební pool postavený na referenční implementaci protokolu Stratum v2. Zpočátku povoluje sólo těžbu, těžba v poolu je plánována do budoucna.
-
● Oznámen simulační nástroj bitcoinové sítě warnet: Software warnet umožňuje specifikovat topologie uzlů, spouštět nad sítí naskriptované scénáře, monitorovat a analyzovat chování.
-
● Vydán klient Payjoinu pro Bitcoin Core: Rustový projekt payjoin-cli přidává pomocí konzolového nástroje payjoin do Bitcoin Core možnost odesílání a přijímání payjoinu.
-
● Žádost o poskytnutí času přijetí bloků: Přispěvatel do repozitáře projektu Bitcoin Block Arrival Time Dataset vyzývá provozovatele uzlů o poskytnutí časových razítek přijetí bloků svými uzly. Pro sběr dat o starých blocích („stale blocks”) existuje podobný repozitář.
-
● Envoy 1.4 released: Vydádní 1.4 bitcoinové peněženky Envoy přidává mimo jiné výběr mincí a štítkování peněženky (podpora pro BIP329 přijde brzy).
-
● Ohlášeno kódovací schéma BBQr: Schéma umí efektivně kódovat větší soubory, například PSBT, do animované série QR kódů pro používání peněženkami nemajícími připojení k počítači.
-
● Vydán Zeus v0.8.0: Vydání v0.8.0 obsahuje mimo jiné vestavěný LND uzel, dodatečnou podporu pro zero conf kanály a podporu pro jednoduché taprootové kanály.
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ů.
-
● Jak se počítá, kolik transakcí se má nahradit pomocí RBF? Murch a Pieter Wuille procházejí několika příklady RBF nahrazení v kontextu pravidla číslo 5 z BIP125: „Počet původních transakcí, které budou nahrazeny, a jejich potomků, kteří budou vyhozeni z mempoolu, nesmí dohromady překročit sto transakcí.” Čtenáře může dále zajímat sezení PR Review Clubu Přidej test BIP-125 pravidla číslo 5 s výchozím mempoolem.
-
● Jaké existují typy RBF a které z nich Bitcoin Core podporuje a používá? Murch vysvětluje historii nahrazování transakcí v Bitcoin Core a v související otázce poskytuje souhrn pravidel nahrazení dle RBF. Dále odkazuje na dokumentaci Bitcoin Core Mempool Replacements a na nápad na zlepšení RBF.
-
● V čem spočívá problém bloku 1 983 702? Antoine Poinsot poskytuje přehled problémů, které vedly k BIP30 omezujícímu duplikovaná txid a BIP34 požadujícímu začlenění čísla bloku v coinbase. Dále poznamenává, že existuje řada bloků, jejichž coinbase obsahuje náhodná data, která vypadají jako výška pozdějšího bloku. Blok 1 983 702 byl prvním, který v praxi mohl opakovat coinbase transakci nějakého předchozího bloku. V související otázce se touto možností Murch a Antoine Poinsot zabývají hlouběji. Viz též zpravodaj č. 182 (angl.).
-
● K čemu se v bitcoinu používají hashovací funkce? Pieter Wuille vypisuje přes třicet různých případů v pravidlech konsenzu, peer to peer protokolu, peněžence a implementaci uzlu, které dohromady používají nejméně deset různých hashovacích funkcí.
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 0.17.3-beta je vydání obsahující opravy několika chyb včetně redukce použité paměti během používání Bitcoin Core backendu.
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 a Bitcoin Inquisition.
-
● LDK #2685 přidává možnost získávání blockchainových dat ze serverů fungujících podobně jako Electrum.
-
● Libsecp256k1 #1446 odstraňuje z projektu část assembly kódu pro x86_64 a přechází na používání stávajícího jazyka C, který byl vždy používán na ostatních platformách. Assembly kód byl před několika lety ručně optimalizován za účelem zvýšení výkonnosti knihovny, avšak kompilátory se od té doby zlepšily a nové verze GCC i LLVM (clang) nyní produkují ještě efektivnější kód.
-
● BTCPay Server #5389 přidává podporu pro bezpečné vytváření multisig peněženek dle BIP129 (viz zpravodaj č. 136, angl.). To umožňuje BTCPay serveru spolupracovat během jednoduchého nastavení multisigu s několika softwarovými peněženkami a hardwarovými podpisovými zařízeními.
-
● BTCPay Server #5490 začíná ve výchozím nastavení používat mempool.space pro odhad poplatků s místním Bitcoin Core uzlem jako jeho zálohou. Vývojáři pod PR poznamenávají, že mají pocit, že odhad poplatků poskytovaný Bitcoin Core nereaguje dostatečně rychle na změny v místním mempoolu. Viz Bitcoin Core #27995 pro související diskuzi o obtížích vylepšování přesnosti odhadu poplatků.
Krásné svátky!
Toto číslo je letošním posledním pravidelným vydáním. Ve středu 20. prosince vydáme náš šestý roční přehled. Pravidelné vydávání zpravodaje bude pokračovat ve středu 3. ledna.