Zpravodaj tento týden shrnuje příspěvek o možnosti plných uzlů ignorovat transakce, které nejsou dopředu vyžádané. Též nechybí naše pravidelné rubriky s oblíbenými otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními nových vydání a významnými změnami v populárním bitcoinovém páteřním software.

Novinky

• ● Ignorování nevyžádaných transakcí: Antoine Riard zaslal do emailové skupiny Bitcoin-Dev příspěvek s návrhem dvou BIPů, které by uzlům umožnily signalizovat, že již nebudou přijímat zprávy tx, které předtím nevyžádaly zprávou inv, nazývané nevyžádané transakce (unsolicited transactions). Riard podobnou myšlenku navrhl již v roce 2021 (viz zpravodaj č. 136, angl.). První navržený BIP přidává mechanismus, kterým by uzly signalizovaly své schopnosti a preference přeposílání transakcí. Druhý BIP by pomocí tohoto mechanismu umožnil uzlům určit, že uzel bude nevyžádané transakce ignorovat.

  Návrh přináší několik drobných výhod, jak bylo diskutováno v pull requestu do Bitcoin Core, ale je v rozporu s designem některých starších lehkých klientů a mohl by uživatelům tohoto software zabránit ve zveřejňování vlastních transakcí. Nasazení by tedy muselo být provedeno opatrně. Ačkoliv Riard zmíněný pull request nejprve otevřel, později jej zavřel a naznačil, že plánuje pracovat na implementaci vlastního plného uzlu postaveného na libbitcoinkernel. Též uvedl, že návrh by mohl pomoci v obraně proti některým útokům, které nedávno odhalil (zpravodaj č. 332).

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é je zdůvodnění aktuální implementace RPC loadtxsoutset? Pieter Wuille vysvětluje, proč je hodnota reprezentující množinu UTXO pro assumeUTXO napevno nastavená ve zdrojovém kódu na konkrétní výšku bloku, jaké jsou budoucí způsoby distribuce snapshotů assumeUTXO a jaké výhody nabízí assumeUTXO oproti prostému kopírování interních datových souborů Bitcoin Core.

• ● Existují kategorie pinningových útoků, které RBF pravidlo č. 3 znemožňuje? Murch vysvětluje, že RBF pravidlo č. 3 nemá zabraňovat pinningovým útokům, a dotýká se pravidel nahrazování v Bitcoin Core.

• ● Nečekané hodnoty časového zámku Uživatel polespinasa vyjmenovává důvody, proč Bitcoin Core nastavuje určité hodnoty nLockTime: na výšku bloku pro zabránění fee snipingu, v 10 % případů na náhodnou hodnotu nižší než výška bloku pro zvýšení soukromí nebo na 0, pokud blockchain není aktuální.

• ● Proč je v platbě skriptem nutné odhalit bit a ověřit, že odpovídá paritě y-ové souřadnice klíče Q? Pieter Wuille objasňuje odůvodnění v BIP341 kontroly parity y-ové souřadnice v taprootové platbě skriptem: umožní potenciální budoucí přidání dávkové validace.

• ● Proč Bitcoin Core používá checkpoint a ne assumevalid blok? Pieter Wuille vysvětluje historii checkpointů v Bitcoin Core a jejich účel a odkazuje na PR a diskuzi o odstranění checkpointů.

• ● Jak Bitcoin Core řeší dlouhé reogranizace řetězce? Pieter Wuille nastiňuje způsob, kterým Bitcoin Core řeší reorganizace blockchainu, a dodává, že jednou odlišností dlouhých reorganizací je, že „neprovádí opětovné přidání transakcí zpět do mempoolu.”

• ● Jaká je definice discard feerate? Murch definuje discard feerate jako maximální jednotkový poplatek pro vzdání se drobných po platbě a shrnuje kód počítající discard feerate jako „jednotkový poplatek cílený na tisíc bloků ořezaný na 3–10 ṩ/vB, pokud je mimo tento rozsah.”

• ● Kompilátor pravidel na miniscript Brunoerg poznamenává, že peněženka Liana používá jazyk pravidel a odkazuje na knihovny sipa/miniscript a rust-miniscript jako příkladů kompilátorů pravidel.

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.

• ● Core Lightning 25.02rc3 je kandidátem na vydání příští hlavní verze tohoto oblíbeného 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.

• ● Core Lightning #8116 mění způsob nakládání s přerušeným vyjednáváním o zavření kanálu. Nově bude proces opakovat, i když to nebude potřeba. Změna opravuje problém, kdy se kvůli chybějící zprávě closing_signed uzel pokusí o opakované připojení, obdrží chybu a zveřejní jednostrannou zavírací transakci. Mezitím však je protistrana již ve stavu CLOSINGD_COMPLETE, a proto zveřejní transakci pro vzájemné uzavření kanálu, což může vést k soupeření mezi těmito dvěma transakcemi. Díky opravě může vyjednávání pokračovat až do potvrzení transakce vzájemného uzavření kanálu.

• ● Core Lightning #8095 přidává do příkazu setconfig (viz též zpravodaj č. 257) příznak transient, díky kterému může být nastavení aplikováno pouze dočasně, bez změny konfiguračního souboru. Takové změny konfigurace nejsou tedy po restartu znovu aplikovány.

• ● Core Lightning #7772 přidává do pluginu chanbackup aktualizaci záložního souboru emergency.recover (viz též zpravodaj č. 324) při každé revokaci commitmentu (když uzel obdrží nový tajný kód pro revokaci). Díky tomu mohou uživatelé zamést (sweep) prostředky v rámci trestající transakce poté, co protistrana zveřejnila neplatný, revokovaný stav. Tato změna rozšiřuje formát statických záloh kanálu a umožňuje pluginu chanbackup serializovat do starého i nového formátu.

• ● Core Lightning #8094 přidává do pluginu xpay (viz zpravodaj č. 330) konfigurační volbu xpay-slow-mode, která na vrácení výsledku počká až do vyřešení všech částí platby s více cestami (multipath payments, MPP). Bez tohoto nastavení mohla být vrácena chybová hláška, i když některá HTLC stále čekala na vyřízení. Pokud se uživatel úspěšně znovu pokusil o platbu z jiného uzlu, mohlo dojít k přeplacení, pokud se zároveň urovnala čekající HTLC.

• ● Eclair #2993 umožňuje příjemci zaplatit poplatky asociované se zaslepenou částí cesty, zatímco odesílatel pokryje poplatky nezaslepené části. Dříve odesílatel platil všechny poplatky, což mu mohlo pomoci odhalit zaslepenou cestu.

• ● LND #9491 přidává do příkazu lncli closechannel podporu pro kooperativní zavření kanálu, i když má stále aktivní HTLC. V případě zavolání pozastaví LND kanál, aby zabránil tvorbě nových HTLC, a počká na vyřízení všech existujících HTLC. Poté započne vyjednávání. Uživatelé musí pro aktivaci tohoto chování nastavit příznak no_wait; v opačném případě obdrží chybovou hlášku. PR dále zajistí, že nastavení max_fee_rate je během kooperativního zavření kanálu vynuceno pro obě strany (dříve bylo jen pro druhou stranu).

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 4. 3. v 15:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.