Zpravodaj tento týden shrnuje diskuzi a obnoveném úsilí na soft fork pročišťující konsenzus a oznamuje plán na výběr nových editorů BIPů před koncem tohoto týdne. Též nechybí naše pravidelné rubriky s oznámeními o nových verzích a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

• ● Návrat k tématu pročištění konsenzu: Antoine Poinsot zaslal do fóra Delving Bitcoin příspěvek, ve kterém připomíná návrh Matta Coralla z roku 2019 na pročištění konsenzu (viz zpravodaj č. 36, angl.). Na začátek se pokouší kvantifikovat nejhorší scénáře několika problémů, které by návrh odstranil, včetně možnosti vytvořit blok, jehož ověření by na moderním laptopu zabralo přes tři minuty a na Raspberry Pi 4 kolem 1,5 hodiny, schopnosti těžařů pomocí útoku ohýbáním času („time warp attack”) ukrást odměny a snížit bezpečnost LN po zhruba jednoměsíční přípravě či schopnosti klamem přinutit lehké klienty k přijetí falešných transakcí (CVE-2017-12842) a plné uzly k odmítání validních bloků (viz zpravodaj č. 37, angl.).

  Nad rámec Corallova původního návrhu doporučuje Poinsot vypořádat se se zbývajícím problémem duplikovaných transakcí, který začne postihovat plné uzly při výšce 1 983 702 (a již postihuje uzly na testnetu).

  Všechny zmíněné problémy mají technicky jednoduchá řešení, která mohou být nasazena soft forkem. Dříve nevržené řešení problému s pomalým ověřováním bloků bylo mírně kontroverzní, jelikož by mohlo zneplatnit skripty, které by teoreticky mohly být použity v předem podepsaných transakcích. Tím by mohlo dojít k porušení pravidla na zabraňování nechtěných konfiskací (viz zpravodaj č. 37, angl.). Nejsme si vědomi žádného použití takového skriptu, ať již v desetileté historii bitcoinu před původním návrhem či během pěti let po něm. Některá použití by však byla nedetekovatelná, dokud by nebyla předem podepsaná transakce zveřejněna.

  Pro odstranění této námitky Poinsot navrhl, aby byla upravená pravidla konsenzu aplikována pouze na výstupy vytvořené po určité výšce bloku. Výstupy vytvořené dříve by byly utratitelné dle starých pravidel.

• ● Výběr nových editorů BIPů: Mark „Murch” Erhardt ve vlákně o přidání nových editorů BIPů navrhl, aby všichni „do konce pátku (5. dubna) uvedli své důvody pro a proti jakémukoliv z kandidátů z vlákna. Pokud by někteří z kandidátů obdrželi širokou podporu, mohli by být přidáni jako noví editoři následující pondělí (8. dubna).”

  V době psaní zpravodaje diskuze stále probíhala. Učiníme, co je v našich silách, abychom o výsledcích informovali v příštím vydání zpravodaje.

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 26.1 je údržbovým vydáním této převládající implementace plného uzlu. Jeho poznámky k vydání popisují opravy několika chyb.

• ● Bitcoin Core 27.0rc1 je kandidátem na vydání příští hlavní verze této převládající implementace plného uzlu. Testeři jsou vyzýváni k revizi navrhovaných témat pro testování.

• ● HWI 3.0.0-rc1 je kandidátem na vydání příští hlavní verze tohoto balíčku poskytujícího jednotné rozhraní k několika různým hardwarovým podpisovým zařízením.

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.

Poznámka: commity do Bitcoin Core uvedené níže se vztahují na jeho vývojovou, master větev. Nebudou tedy pravděpodobně vydány před uplynutím zhruba šesti měsíců po vydání nadcházející verze 27.

• ● Bitcoin Core #27307 přináší sledování transakcí v mempoolu, které kolidují s transakcemi patřícími peněžence vestavěné v Bitcoin Core, včetně transakcí v mempoolu, které jsou v konfliktu s předky transakcí této peněženky. Je-li kolidující transakce potvrzena, nemůže být transakce peněženky začleněna do blockchainu, je tedy užitečné o konfliktech vědět. Kolidující transakce z mempoolu jsou nyní obsaženy v novém poli mempoolconflict ve výsledku volání gettransaction na nějakou transakci peněženky. Vstupy transakce s kolizí v mempoolu mohou být znovu utraceny bez ručního zahození kolidující transakce v mempoolu a jsou zahrnuty v zůstatku peněženky.

• ● Bitcoin Core #29242 představuje pomocné funkce k porovnání dvou diagramů jednotkových poplatků a k vyhodnocení souladu ekonomických podnětů nahrazení clusterů až dvěma transakcemi. Tyto funkce poskytnou základ nahrazování balíčků poplatkem (RBF) clustery o maximální velikosti dva včetně transakcí do potvrzení topologicky omezenených (TRUC, „Topologically Restricted Until Confirmation”), známých též jako transakce verze 3.

• ● Core Lightning #7094 odstraňuje několik funkcí, které byly předtím označeny za zastaralé použitím nového způsobu zastarávání v Core Lightning (viz zpravodaj č. 288).

• ● BDK #1351 mění interpretaci parametru stop_gap, který nastavuje chování gap limitu. Jednou konkrétní změnou se přibližuje chování jiných peněženek: stop_gap s hodnotou 10 znamená, že BDK bude generovat nové adresy pro skenování transakcí tak dlouho, dokud nenalezne deset po sobě jdoucích adres bez jakékoliv transakce.