Zpravodaj tento týden oznamuje opravenou zranitelnost postihující LDK, shrnuje diskuzi o gossipu s nulovou znalostí pro oznamování LN kanálů, popisuje objevení starších studií, které mohou být použité pro hledání optimální linearizace clusterů, poskytuje aktualizaci vývoje protokolu Erlay, který má snížit síťové nároky přeposílání transakcí, nahlíží na kompromisy mezi různými skripty pro implementaci LN dočasných anchorů, sdílí návrh na emulaci opkódu OP_RAND způsobem zachovávajícím soukromí a bez nutnosti změn konsenzu a poukazuje na obnovenou diskuzi o snížení minimálního transakčního poplatku.

Novinky

  • ● Zranitelnost LDK během vynuceného zavření kanálu: Matt Morehouse zaslal do fóra Delving Bitcoin příspěvek s ohlášením zranitelnosti postihující LDK, kterou zodpovědně nahlásil a která byla opravena v LDK verzi 0.1.1. Podobně jako v případě jiné nedávno zveřejněné zranitelnosti LDK (viz zpravodaj č. 339), i zde smyčka v kódu LDK skončila, jakmile vyřešila první neobvyklý případ, aniž by pokračovala řešením dalších případů stejného druhu. V tomto případě to mohlo vést k neúspěšnému urovnání čekajících HTLC v otevřených kanálech, načež byla poctivá protistrana donucena zavřít kanály a urovnat tak HTLC onchain.

    Zřejmě to k přímé krádeži vést nemohlo, ale oběť musela platit poplatky za zavření kanálů, za otevření nových kanálů a nemohla vydělávat na poplatcích za přeposílání.

    Morehouseův kvalitní příspěvek zabíhá do dalších podrobností a navrhuje, jak by bylo možné v budoucnosti podobným chybám předejít.

  • ● Gossip s nulovou znalostí pro oznamování LN kanálů: Johan Halseth zaslal do fóra Delving Bitcoin příspěvek s popisem rozšíření navrhovaného protokolu oznamování kanálů 1.75, který by ostatním uzlům umožnil ověřit, že za kanálem stojí skutečná otevírací transakce (čímž je možné zabránit několika laciným druhům DoS), avšak bez nutnosti odhalit, které UTXO otevírací transakci tvoří, což pozitivně dopadá na soukromí. Halsethovo rozšíření staví na jeho předchozím výzkumu (viz zpravodaj č. 321), který používá utreexo a systém dokladů s nulovou znalostí (zero-knowledge proof system, ZK). Byl by použit s jednoduchými taprootovými kanály založenými na MuSig2.

    Diskuze se soustředila na kompromisy mezi Halsethovou myšlenkou, pokračujícím používáním veřejného gossipu a jinými metodami generování ZK dokladů. Mezi vyjádřené obavy patří zajištění, aby mohly všechny LN uzly doklady rychle ověřovat, a složitost systému dokladů a ověřování, neboť bude muset být implementován všemi LN uzly.

    Diskuze v době psaní nadále probíhala.

  • ● Objevení staršího článku užitečného pro hledání optimální linearizace clusterů: Stefan Richter zaslal do fóra Delving Bitcoin příspěvek, ve kterém odkazuje na vědecký článek z roku 1989, který nalezl. Článek obsahuje algoritmus (a důkaz), který může být použit k efektivnímu nalezení podmnožiny s nejvyšším jednotkovým poplatkem ve skupině transakcí, která zůstane topologicky validní, bude-li tato podmnožina začleněna do bloku. Též nalezl implementaci v C++ několika algoritmů řešících podobné problémy, které „by měly být v praxi ještě rychlejší.”

    Předchozí práce na mempoolu clusterů se soustředila na zjednodušování a zrychlování porovnávání různých linearizací, aby mohla být použita ta nejlepší. Díky tomu by mohl být používán rychlý algoritmus k okamžité linearizaci clusteru a pomalejší – avšak optimálnější – algoritmus by mohl běžet v okamžiku, kdy by procesor nebyl využit naplno. Pokud by však tento algoritmus z roku 1989 (nebo jiný) řešící problém uzávěru s maximálním poměrem vah (maximum-ratio closure problem) běžel dostatečně rychle, mohl by být používán ve všech případech. I kdyby byl mírně pomalejší, mohl by být používán jako algoritmus, který běží v období s dostupnými procesorovými cykly.

    Pieter Wuille odpověděl s nadšením a několika dalšími otázkami. Dále popsal nový algoritmus linearizace clusterů, který pracovní skupina zabývající se mempoolem clusterů vyvíjí. Tento nový algoritmus vychází z diskuze z Bitcoin Research Week, jejímiž účastníky byli Dongning Guo a Aviv Zohar. Převádí tento problém na jiný, který lze řešit lineárním programováním a který se jeví být rychlým a snadno implementovatelným a navíc vrací optimální linearizaci – pokud je konečný. Chybí však ještě dokázat, že algoritmus konečný je a že skončí v rozumném čase.

    I když se to přímo bitcoinu netýká, přišel nám zajímavý Richterův popis, jak pomocí LLM od DeepSeek článek z roku 1989 nalezl.

    V době psaní zpravodaje diskuze stále probíhala a byly zkoumány další články o této doméně. Richter napsal: „zdá se, že náš problém, nebo spíše jeho obecné řešení, které se nazývá parametrický minimální řez s monotónními kapacitami mezi zdrojem a stokem (source-sink-monotone parametric min-cut), má použití v agregaci polygonů při zjednodušování map a v počítačovém vidění.”

  • ● Novinky u Erlay: Sergi Delgado popsal v několika příspěvcích do fóra Delving Bitcoin výsledek roční práce implementování Erlay v Bitcoin Core. Začíná přehledem, jak funguje současné přeposílání transakcí (tzv. fanout, přibližně „rozvíření” či „rozvětvení”) a jaké jeho změny Erlay navrhuje. Poznamenává, že nějaký fanout zůstane i v síti, kde každý uzel Erlay podporuje, neboť „fanout je účinnější a výrazně rychlejší než synchronizace množin (set reconciliation), pokud přijímající uzel oznamovanou transakci nezná.“

    Používání kombinace fanoutu a synchronizace vyžaduje vybrat, kdy použít kterou metodu a se kterými spojeními. Jeho výzkum se tedy soustředí na hledání optimálního výběru:

    • ● Filtrování na základě znalosti transakce zkoumá, zda by měl uzel mezi spojení pro fanout zahrnout i taková, která transakci již určitě mají. Například: náš uzel má deset spojení a tři z nich nám již oznámila nějakou transakci. Pokud chceme náhodně zvolit tři další spojení pro fanout této transakce, měli bychom vybírat ze všech deseti spojení nebo jen těch sedmi, která nám tuto transakci neoznámila? Simulace překvapivě odhalily, že „mezi těmito volbami není výrazný rozdíl.” Delgado tento překvapivý výsledek zkoumal a usoudil, že by měla být zvažována všechna spojení (čili žádné filtrování).

    • ● Kdy vybírat kandidáty pro fanout zkoumá, kdy by měl uzel vybírat spojení pro fanout transakce (zbytek použije synchronizaci pomocí Erlay). Uvažuje se nad dvěma možnostmi: krátce po validaci nové transakce a přidání do fronty pro přeposlání nebo když nastane čas pro přeposlání transakce (uzly neodesílají transakce okamžitě; pro ztížení odhadování topologie sítě a pro ochranu soukromí původce transakce čekají náhodou dobu). Výsledky simulace opět ukázaly, že „neexistuje významný rozdíl,” i když „rozdíly mohou nastat v síti s částečnou podporou Erlay.”

    • ● Kolik spojení by mělo obdržet fanout zkoumá míru fanoutu. Vyšší míra urychluje propagaci transakcí, ale snižuje úsporu přenosového pásma. Kromě míry fanoutu testoval Delgado též zvyšování počtu odchozích spojení, což je jeden z cílů nasazení Erlay. Simulace ukazuje, že aktuální přístup v Erlay snižuje využití přenosového pásma zhruba o 35 % při současném počtu odchozích spojení (osm) a 45 % při 12 odchozích spojeních. Latence se však zvyšuje zhruba o 240 %. Příspěvek na grafech zobrazuje další konfigurace a jejich kompromisy. Výsledky simulace budou užitečné nejen pro výběr parametrů, ale podle Delgada též pro hodnocení alternativních algoritmů pro fanout, které mohou nabídnout příznivější kompromisy.

    • ● Míra fanoutu dle způsobu obdržení transakce zkoumá, zda by měla být míra fanoutu upravena podle toho, jestli byla transakce obdržena přes fanout nebo synchronizaci. A pokud by upravena být měla, jakým způsobem? Fanout je rychlejší a účinnější během počátku života přeposílané transakce, ale plýtvá přenosovým pásmem, když už transakce dosáhne většinu uzlů. Neexistuje možnost, jak by mohl uzel přímo určit, kolik jiných uzlů transakci již vidělo. Avšak pokud spojení, které mu transakci poslalo jako první, použilo fanout a nečekalo na další kolo synchronizace, jedná se zřejmě o transakci v rané fázi propagace. Tato data mohou být použita k mírnému navýšení vlastní míry fanoutu pro tuto konkrétní transakci a tím jí pomoci k rychlejší propagaci. Delgado tuto myšlenku simuloval a našel upravený poměr fanoutu, který snižuje čas propagace o 18 %, ale zvyšuje využití přenosového pásma pouze o 6,5 % oproti kontrolní simulaci, ve které použil stejnou míru fanoutu pro všechny transakce.

  • ● Kompromisy dočasných anchor skriptů v LN: Bastien Teinturier zaslal do fóra Delving Bitcoin příspěvek s žádostí o názory, které dočasné anchor skripty by měly nahradit existující anchor výstupy jako jeden z výstupů LN commitment transakcí založených na TRUC. Použitý skript určuje, kdo a za jakých podmínek může commitment transakci zaplatit navýšení poplatku pomocí CPFP. Představil čtyři možnosti:

    • Pay-to-anchor (P2A) skript: ten zanechává onchain minimální stopu, avšak kvůli němu zřejmě skončí veškerý přebytek hodnoty ořezaných HTLC u těžařů (jako je tomu dnes).

    • Anchor s klíčem jednoho účastníka: umožní získat část hodnoty ořezaných HTLC účastníkovi, který je ochoten čekat několik desítek bloků, než bude moci peníze ze zavřeného kanálu použít. Každý, kdo vynuceně uzavírá kanál, musí čekat v jakémkoliv případě. Avšak ani jedna strana kanálu nemůže platbu poplatku delegovat na třetí stranu, aniž by jí nedaly možnost ukrást všechny prostředky kanálu. Pokud s protistranou soupeříte o získání přebytku, pravděpodobně stejně skončí u těžaře.

    • Anchor se sdíleným klíčem: též umožňuje získat přebytek hodnoty HTLC a umožňuje delegovat, ale ten, na kterého delegujete, může s vámi a s vaší protistranou soupeřit o nárokování přebytku hodnoty. V případě soupeření zřejmě opět připadne přebytek hodnoty těžařovi.

    • Anchor s duálním klíčem: každý účastník má možnost nárokovat přebytek hodnoty ořezaných HTLC bez čekání. Avšak delegování není možné. Obě strany kanálu spolu stále mohou soupeřit.

    V odpovědích Gregory Sanders poznamenal, že v různých případech lze používat různá schémata. Například P2A by mohlo být použito, když nejsou žádná ořezaná HTLC. V ostatních případech lze použít některý s anchorů s klíčem. Pokud by byla ořezaná hodnota nad hodnotou prachu, mohla by být namísto anchor výstupu přidána do commitment transakce. Dále varoval, že by to mohlo vytvořit „podivnou situaci, kdy by se protistrana mohla pokusit nakopnout ořezanou částku a sama si ji vzít.“ David Harding v pozdějším příspěvku toto téma rozšířil.

    Antoine Riard varoval proti používání P2A kvůli riziku, že těžaři budou provádět pinning transakcí (viz zpravodaj č. 339).

    V době psaní diskuze nadále probíhala.

  • ● Emulace OP_RAND: Oleksandr Kurbatov zaslal do fóra Delving Bitcoin příspěvek o interaktivním protokolu, který dvěma stranám umožňuje vytvořit kontrakt platící způsobem, který ani jedna ze stran nemůže předvídat. V důsledku se tak jedná o náhodný způsob. Dřívější práce na bitcoinových pravděpodobnostních platbách používala pokročilé skripty, avšak Kurbatovův přístup využívá speciálně konstruované veřejné klíče, které vítězovi umožní utratit prostředky v kontraktu. Tento způsob nabízí větší soukromí a flexibilitu.

    Optech nebyl schopen protokol analyzovat, ale žádných zřejmých problémů jsme si nevšimli. Doufáme, že se myšlence dostane další diskuze, neboť pravděpodobnostní platby mají několik aplikací, například mohou uživatelům umožnit poslat onchain částky, které by jinak byly neekonomické, jako např. u ořezaných HTLC.

  • ● Diskuze o snížení minimálního poplatku pro přeposílání transakcí: Greg Tonoski zaslal do emailové skupiny Bitcoin-Dev příspěvek o snížení výchozího minimálního jednotkového poplatku pro přeposílání transakcí. Toto téma se opakovaně diskutuje (a Optech o něm přináší souhrny) od roku 2018, naposledy v roce 2022 (viz zpravodaj č. 212, angl.). Za zmínku stojí, že nedávno zveřejněná zranitelnost (viz zpravodaj č. 324) odhalila možný problém, který mohl postihnout uživatele a těžaře, kteří v minulosti toto nastavení snížili. Optech bude o případném pokračování diskuze informovat.

Diskuze o změnách konsenzu

Měsíční rubrika shrnující návrhy a diskuze o změnách pravidel bitcoinového konsenzu.

  • ● Aktualizace návrhu na soft fork pročištění konsenzu: Antoine Poinsot zaslal do vlákna ve fóru Delving Bitcoin o soft forku na pročištění konsenzu několik příspěvků, ve kterých navrhl změnu parametrů:

    • ● Nový limit na sigops u zastaralých vstupů: v soukromém vlákně se Poinsot a několik dalších přispěvatelů pokusilo vytvořit regtestový blok, jehož validace by trvala co nejdelší možnou dobu za použití známých problémů validace zastaralých (předsegwitových) transakcí. Poté zjistil, že by mohl „tento nejhorší blok přizpůsobit tak, aby byl validní i navzdory obraně původně navržené v roce 2019” (viz zpravodaj č. 36, angl.). To ho vedlo k návrhu na jiný způsob ochrany: omezení maximálního počtu operací nad podpisy (sigop) v zastaralých transakcích na 2 500. Každé vykonání opkódu OP_CHECKSIG se počítá jako jeden sigop a každé vykonání OP_CHECKMULTISIG se počítá až jako 20 sigops (dle počtu použitých veřejných klíčů). Jeho analýza ukazuje, že by to snížilo čas validace nejhoršího případu o 97,5 %.

      Stejně jako v případě jakékoliv změny tohoto druhu i zde existuje riziko neúmyslných konfiskací, protože kvůli novému pravidlu by byly dříve podepsané transakce neplatné. Pokud znáte někoho, kdy potřebuje u zastaralých transakcí více než 2 500 sigops nebo více než 2 125 v případě vícenásobných podpisů1, prosíme upozorněte Poinsota nebo další vývojáře protokolu.

    • ● Prodloužení přechodného období ohýbání času na 2 hodiny: dříve tento návrh na pročištění zakazoval prvnímu bloku nové periody složitosti mít v hlavičce časové razítko více než 600 sekund před časovým razítkem předchozího bloku. Díky tomu by konstantní množství hashrate nemohlo zneužít zranitelnosti s ohýbáním času k produkci více než jednoho bloku za 10 minut.

      Poinsot nyní akceptuje použití 7 200 sekund (2 hodiny), jak původně navrhl Sjors Provoost, jako hodnotu, se kterou je mnohem méně pravděpodobné, že by vedla k neúmyslně vytvořenému nevalidnímu bloku. Na druhou stranu umožňuje velmi trpělivému útočníkovi s kontrolou více než 50 % celkového hashrate pomocí ohýbání času snížit během měsíců složitost, i kdyby hashrate zůstával konstantní nebo se zvyšoval. To by byl veřejně patrný útok a síť by měla měsíce na reakci. Ve svém příspěvku Poinsot shrnuje předešlé argumenty (viz zpravodaj č. 335 pro náš méně detailní souhrn) a uzavírá slovy: „navzdory dosti chabým argumentům ve prospěch prodloužení přechodného období nám nebrání náklady na jeho učinění chybovat na bezpečné straně.”

      Ve vlákně věnovaném diskuzi o prodloužení období hovořili vývojáři Zawy a Pieter Wuille, jak je 600 sekund, o kterých by se mohlo zdát, že umožňují pomalé snižování složitosti na její minimum, ve skutečnosti dostatečná hodnota bránící více než jednomu drobnému snížení složitosti. Konkrétně sledovali dopad chyby v úpravě složitosti („o jedničku mimo“) a asymetrii Erlangova rozložení na přesně se měnící složitost. Zawy následně uzavřel slovy: „Nejde o to, že by opravy Erlanga a ‚2015kové díry’ nebyly potřeba, ale že 600 sekund před předchozím blokem není 600sekundová lež, je to 1200sekundová lež, protože jsme předpokládali časové razítko 600 sekund po něm.”

    • ● Oprava duplikovaných transakcí: na základě žádosti o zpětnou vazbu od těžařů (viz zpravodaj č. 332) o možných negativních dopadech řešení problému duplikovaných transakcí vybral Poinsot konkrétní řešení, které bude součástí návrhu na pročištění: požadavek, aby byla výška předchozího bloku obsažena v poli nLockTime všech mincetvorných (coinbasových) transakcí. Tento návrh přináší dvě výhody: umožňuje extrahovat výšku bloku bez nutnosti parsovat skript a umožňuje vytvářet kompaktní doklad o výšce bloku založený na SHA256 (v nejhorším případě kolem 700 bajtů, mnohem méně než 1MB doklad, který by byl potřeba dnes bez pokročilého systému dokladů).

      Tato změna nebude mít dopad na běžného uživatele, ale bude nakonec vyžadovat, aby těžaři aktualizovali software, který používají pro generování mincetvorných transakcí. Pokud kterýkoliv z těžařů vidí tento návrh jako problémový, prosíme kontaktujte Poinsota nebo jiného vývojáře.

    Poinsot dále zaslal do emailové skupiny Bitcoin-Dev příspěvek s novinkami o své práci a aktuálním stavem návrhu.

  • ● Žádost o návrh kovenantu pro Braidpool: Bob McElrath zaslal do fóra Delving Bitcoin příspěvek, ve kterém žádá vývojáře navrhující kovenanty, aby zvážili, jak by mohly jejich oblíbené nebo nové návrhy pomoci při vytváření efektivního decentralizovaného těžebního poolu. Návrh současného prototypu pro Braidpool používá federaci podepisujících entit, které pomocí prahových podpisů obdrží podíly dle svých příspěvků do celkového hashrate poolu. To umožňuje většinovému podílu těžařů či skupiny těžařů krást výplaty menším těžařům. McElrath by raději používal kovenant, který by zajistil, že by každý těžař mohl z poolu vyvést pouze prostředky poměrné ke svým příspěvkům. V textu poskytl seznam konkrétních požadavků a též je vítán důkaz o nemožnosti.

    V době psaní zpravodaje byl příspěvek bez reakcí.

  • ● Deterministický výběr transakcí a závazek k mempoolu: vlákno z dubna 2024 získalo minulý měsíc novou pozornost. Již dříve zaslal Bob McElrath příspěvek o tom, jak by se těžaři museli zavazovat k transakcím ve svém mempoolu a pouze tehdy by mohli do svých bloků zařadit transakce, které byly deterministicky vybrané z předchozích závazků. McElrath vidí dvě možnosti použití:

    • Globálně pro všechny těžaře: to by odstranilo „riziko a odpovědnost za výběr transakcí“ ve světě, kde jsou těžaři často velké korporace, které se musí podrobovat zákonům, regulacím a radám risk managerů.

    • Lokálně pro jeden pool: nabízí většinu výhod globálně deterministického algoritmu, ale k implementaci nevyžaduje žádné změny konsenzu. Navíc může ušetřit velké množství síťového provozu mezi účastníky decentralizovaného těžebního poolu, jako je Braidpool, jelikož tento algoritmus určuje, které transakce musí kandidát na blok obsahovat, proto jakýkoliv share vytvořený z tohoto bloku nemusí explicitně poskytovat žádná data transakcí ostatním účastníkům poolu.

    Anthony Towns popsal několik potenciálních problémů s globální možností se změnou konsenzu: jakákoliv změna výběru transakcí by vyžadovala změnu konsenzu (a možná i hard fork) a žádná nestandardní transakce by neměla možnost vytěžení ani ve spolupráci s těžařem. Mezi změny pravidel z posledních několika let, které by vyžadovaly změnu konsenzu, patří: TRUC, upravená RBF pravidla a dočasné anchory. Towns odkázal na známý případ, ve kterém byly neúmyslně zaseknuty milióny dolarů v nestandardním skriptu a které pomohl vysekat kooperující těžař.

    Zbytek diskuze se soustředil na lokální přístup, tak jak byl koncipován pro Braidpool. Neobjevily se žádné námitky a dodatečná diskuze k tématu algoritmu úpravy složitosti (viz následující položku v této rubrice) ukázala, jak by mohl být obzvláště užitečný pro pool, který vytváří bloky s mnohem větší kadencí než bitcoin a kde by determinismus výběru transakcí výrazně snížil síťové nároky, latenci a náklady na validaci.

  • ● Rychlý algoritmus úpravy složitosti u DAG blockchainů: vývojář Zawy zaslal do fóra Delving Bitcoin příspěvek o algoritmu úpravy složitosti (difficulty adjustment algorithm, DAA) pro blockchain v podobě orientovaného acyklického grafu (directed acyclic graph, DAG). Algoritmus byl navržen pro použití v místním konsenzu mezi účastníky Braidpoolu (a ne pro globální bitcoinový konsenzus), avšak diskuze se opakovaně dotýkala i aspektů globálního konsenzu.

    V bitcoinovém blockchainu zavazuje každý blok právě jednomu rodiči. Několik potomků může zavazovat stejnému rodiči, ale uzly budou za validní v nejlepším řetězci považovat pouze jeden z nich. V DAG blockchainu může každý blok zavázat jednomu nebo více rodičům a může mít nula nebo více potomků, které mu zavazují. V DAG blockchainu lze mít ve stejné generaci několik validních bloků v nejlepším blockchainu.

    Illustration of a DAG blockchain

    Navržený DAA se zaměřuje na průměrný počet rodičů v naposledy spatřených 100 validních blocích. Pokud se průměrný počet rodičů zvýší, algoritmus zvýší složitost; pokud je méně rodičů, složitost klesá. Dle Zawyho cíl dvou rodičů v průměru poskytuje nejrychlejší konsenzus. Na rozdíl od bitcoinového DAA nepotřebuje mít tento navrhovaný DAA pojem o čase, avšak vyžaduje, aby účastníci poolu ignorovali bloky, které obdrží mnohem později než ostatní bloky stejné generace; jelikož by jinak nebylo možné dosáhnout konsenzu, byly by nakonec DAG s více proof of work upřednostňovány před těmi s méně proof of work. Bob McElrath, author tohoto DAA, problém a možné řešení analyzoval.

    Pieter Wuille napsal, že tento návrh se podobá nápadu z roku 2012 od Andrew Millera. Zawy souhlasil a McElrath přidá do svého článku citaci. Sjors Provoost diskutoval složitost práce s DAG řetězci v současné architektuře Bitcoin Core, ale poznamenal, že libbitcoin by ji mohl zjednodušit a utreexo zefektivnit. Zawy podrobil protokol rozsáhlé simulaci a naznačil, že pracuje na simulacích dalších variant protokolu, aby nalezl nejlepší kompromis.

    Poslední příspěvek ve vlákně se objevil zhruba měsíc před sepsáním tohoto shrnutí, očekáváme však, že Zawy a vývojáři Braidpoolu v analýze a implementaci protokolu pokračují.

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 Wallet 1.1.0 je vydáním této knihovny pro budování aplikací s podporou bitcoinu. Ve výchozím nastavení používá transakce verze 2 (čímž zlepšuje soukromí, neboť BDK transakce splynou s transakcemi jiných peněženek, které musí používat v2 transakce za účelem podpory relativních časových zámků, viz zpravodaj č. 337). Dále přidává podporu kompaktních filtrů bloků (viz zpravodaj č. 339), opravuje chyby a přináší další vylepšení.

  • ● LND v0.18.5-beta.rc1 je kandidátem na menší vydání této populární implementace LN uzlu.

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 #21590 implementuje algoritmus modulární inverze založený na safegcd určený pro MuHash3072 (viz zpravodaje č. 131 a č. 136, oba angl.). Kód je převzatý z libsecp256k1, navíc sjednocuje kód pro 32- a 64bitovou architekturu. Výsledky výkonnostního testu ukazují zhruba 100násobné zlepšení na x86_64, díky čemuž došlo ke snížení výpočtu MuHash z 5,8 ms na 57 μs.

  • ● Eclair #2983 mění synchronizaci routovací tabulky během opakovaného připojení. Nově synchronizuje oznámení kanálů pouze se spojeními s nejvyšší sdílenou kapacitou kanálu. Výsledkem je redukce síťového provozu. Dále bylo upraveno výchozí chování whitelistu synchronizace (viz zpravodaj č. 62, angl.): pokud chce uživatel deaktivovat synchronizaci se spojeními mimo whitelist, musí nastavit router.sync.peer-limit na 0 (výchozí hodnota je 5).

  • ● Eclair #2968 přidává podporu splicingu ve veřejných kanálech. Jakmile se splicingová transakce potvrdí a uzamkne na obou stranách, uzly si vymění podpisy a zveřejní do sítě channel_announcement. Eclair nedávno přidal sledování nevlastních splicingů (viz zpravodaj č. 337). Toto PR dále znemožňuje používání short_channel_id pro routování v soukromých kanálech; namísto toho používá scid_alias, aby neodhalil UTXO kanálu.

  • ● LDK #3556 vyvolá selhání HTLC ve zpětném sledu, pokud se příliš přiblíží času expirace. Dříve uzel čekal další tři bloky navíc, aby měla nárokovací transakce čas na potvrzení. Avšak tato prodleva zvyšovala riziko vynuceného zavření tohoto kanálu. Dále bylo odstraněno pole historical_inbound_htlc_fulfills a přidán SentHTLCId.

  • ● LND #9456 přidává varování o zastarání do SendToRoute, SendToRouteSync, SendPayment a SendPaymentSync v přípravě na jejich odstranění v přespříštím vydání (0.21). Uživatelé by měli používat nové v2 metody SendToRouteV2, SendPaymentV2 a TrackPaymentV2.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 11. 2. v 15:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.

Poznámky

  1. Co se týče P2SH a navrhovaného počítání sigops vstupů, OP_CHECKMULTISIG s více než 16 veřejnými klíči se počítá jako 20 sigops; pokud někdo použije 125× OP_CHECKMULTISIG, pokaždé se 17 klíči, budou počítány jako 2 500 sigops. ↩