diff --git a/_posts/cs/newsletters/2026-04-03-newsletter.md b/_posts/cs/newsletters/2026-04-03-newsletter.md new file mode 100644 index 000000000..240d8acb2 --- /dev/null +++ b/_posts/cs/newsletters/2026-04-03-newsletter.md @@ -0,0 +1,248 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 399' +permalink: /cs/newsletters/2026/04/03/ +name: 2026-04-03-newsletter-cs +slug: 2026-04-03-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden popisuje, jak může identifikace peněženek narušovat +soukromí payjoinu, a shrnuje návrh na formát metadat záloh peněženek. +Též nechybí naše pravidelné rubriky se souhrnem návrhů a diskuzí +o změnách pravidel konsenzu, s oznámeními nových vydání a s popisem +významných změn v populárním bitcoinovém páteřním software. + +## Novinky + +- **Riziko identifikace peněženky použité pro payjoin**: Armin Sabouri + zaslal do fóra Delving Bitcoin [příspěvek][topic payjoin fingerprinting] + popisující, jak rozdíly mezi implementacemi payjoinu umožňují detekovat + [payjoinové][topic payjoin] transakce a mohou tak narušit jejich soukromí. + + Sabouri tvrdí, že i když by payjoinové transakce měly být nerozeznatelné od běžných + transakcí, mohou obsahovat stopy po spolupráci mezi více účastníky: + + - V rámci transakce + + - Řadí vstupy a výstupy dle vlastníka. + + - Rozdíly v kódování vstupů. + + - Velikost vstupů v bajtech. + + - Mezi transakcemi + + - Zpětně: Každý vstup byl vytvořen předchozí transakcí, která nese své vlastní charakteristiky. + + - Dopředně: Každý výstup může být utracen budoucí transakcí, která charakteristiky odhalí. + + Dále prozkoumal tři implementace payjoinu: Samourai, demo PDK a Cake Wallet + (posílající do Bull Bitcoin Mobile). V každém z těchto příkladů nalezl několik + odlišností, které umožňují odhalit použitou implementaci. Mezi těmito znaky + byly například: + + - Rozdíly v kódování podpisů vstupů. + + - SIGHASH_ALL bajt v jednom vstupu, ale ne v ostatních. + + - Volba výstupní hodnoty. + + Sabouri uzavírá tvrzením, že některé z těchto charakteristik peněženek je možné + snadno odstranit, jiné jsou svázané s designem peněženky. Vývojáři peněženek + by si měli být během přidávání podpory pro payjoin do svých peněženek těchto + vlastností vědomi. + +- **Návrh BIPu formátu metadat záloh peněženek**: Pythcoiner zaslal + do emailové skupiny Bitcoin-Dev [příspěvek][wallet bip ml] o novém návrhu + společných struktur pro metadata záloh peněženek. Návrh BIPu, dostupný + na [BIPs #2130][], specifikuje standardní způsob ukládání různých druhů + metadat, jako jsou deskriptory účtů, klíče, [štítky][topic wallet labels], + [PSBT][topic psbt] a další. Tím dosáhne kompatibility mezi různými + implementacemi peněženek a jednodušší migrace a obnovy. + Dle Pythcoinera postrádá současný ekosystém společnou specifikaci a + jeho návrh se snaží tuto mezeru zaplnit. + + Z technického hlediska se jedná o textový soubor v UTF-8 obsahující + jediný validní JSON objekt, který reprezentuje strukturu záloh. + BIP vyjmenovává všechna možná pole, která by tento JSON objekt mohl + obsahovat, a poznamenává, že implementace peněženek mohou kterákoliv + z nich ignorovat, pokud pro ně nejsou užitečná. + +## Diskuze o změnách konsenzu + +_Měsíční rubrika shrnující návrhy a diskuze o změnách pravidel +bitcoinového konsenzu._ + +- **Úsporné izogenní PQC může nahradit hierarchické peněženky, tweakování klíčů, tiché platby**: + Conduition zaslal do fóra Delving Bitcoin [příspěvek][c delving ibc hd] o svém + výzkumu udržitelnosti kryptografie založené na izogenii (Isogeny-Based Cryptography, + IBC) jako [postkvantového][topic quantum resistance] kryptografického systému + pro bitcoin. I když problém diskrétního logaritmu nad eliptickými křivkami + se může v postkvantovém světě stát nezabezpečeným, obecně není na matematice + eliptických křivek nic rozbitého. Ve stručnosti je izogenie funkcí z jedné + eliptické křivky na jinou. IBC předpokládá, že je obtížné vypočítat izogenii + mezi jednou eliptickou křivkou určitého druhu a jednou další. Vytvořit + izogenii a křivku, na kterou mapuje, je však snadné. Tajné klíče v IBC + jsou tak izogenie a veřejné klíče jsou křivky, na které mapuje. + + Je možné, stejně jako u ECDLP, spočítat nové soukromé a veřejné klíče nezávisle + ze stejné soli (např. [BIP32 derivací][topic bip32]) a řádně podepsat výsledným + soukromým klíčem pro výsledný veřejný klíč. Tato vlastnost, kterou Conduition + nazývá opakovanou randomizací (rerandomization), umožňuje [BIP32][], [BIP341][] + a [BIP352][] (pravděpodobně spolu s některými dalšími kryptografickými inovacemi). + + Zatím neexistují pro IBC žádné protokoly agregace podpisů, jako jsou [MuSig][topic musig] + či [FROST][topic threshold signature], proto conduition vyzývá bitcoinové vývojáře, + aby prozkoumali možnosti. + + Klíče a podpisy ve známých IBC systémech jsou zhruba dvakrát větší než klíče + v ECDLP systémech a mnohem menší než systémy založené na hašování nebo mřížkové + kryptografii. Ověřování je nákladné i na desktopových počítačích (v řádu + jedné milisekundy na jedno ověření), podobně jako u hašování nebo mřížkové + kryptografie. + +- **Rozpočet varops operací a tapscriptový list 0xc2 („skriptové obrození”) mají BIP 440 a 441**: + Rusty Russell zaslal do emailové skupiny Bitcoin-Dev [zprávu][rr ml gsr bips], + že byly odeslány k očíslování první dva BIPy velkého skriptového obrození (GSR, Great + Script Restoration či Grand Script Renaissance). Následně obdržely čísla 440 a 441. + [BIP440][news374 varops] obnovuje dříve deaktivované opkódy. Díky systému pro + hlídání nákladů každé varops operace (opkód, jehož náklady závisí na velikosti + vstupu) je zaručeno, že náklady na validaci skriptů v bloku + nepřekročí náklady na validaci bloku obsahujícího nejvyšší možný počet operací + s podpisy. [BIP441][news374 c2] popisuje validaci nové verze [tapscriptu][topic + tapscript], která obnovuje opkódy deaktivované Satoshim v roce 2010. + +- **SHRIMPS: postkvantový podpis s 2,5 kB napříč více zařízení se stavem**: + Jonas Nick zaslal do fóra Delving Bitcoin [příspěvek][jn delving shrimps] + o novém konstruktu podpisů pro postkvantový bitcoin založeném na hašování + a částečném stavu. SHRIMPS využívá skutečnosti, že velikost podpisů + [SPHINCS+][news383 sphincs] je úměrná maximálnímu počtu podpisů pro + daný klíč, které mohou být vytvořeny při zachování dané úrovně zabezpečení. + + Podobně jako [SHRINCS][news391 shrincs] se i SHRIMPS klíče sestávají ze dvou + klíčů zahašovaných dohromady. V tomto případě jsou oba klíče bezstavovými + SPHINCS+ klíči, avšak s různými parametry. První klíč je bezpečný pouze + pro malý počet podpisů a je proto určený pro první podpis (nebo pár prvních + podpisů) každého podpisového zařízení, které tento klíč používá. Druhý + klíč je bezpečný pro mnohem větší počet podpisů (v bitcoinu v podstatě + neomezený) a každé zařízení ho začne používat po určitém počtu (potenciálně + zvoleném uživatelem) podpisů z tohoto zařízení. V důsledku tak v běžném + případě, kde každý klíč (kterých může být z jednoho seedu generováno mnoho) + podepisuje pouze párkrát, mohou téměř všechny podpisy mít méně než 2,5 kB, + a přitom nemusí být jejich počet omezen ani v případě mnohonásobného + opakovaného použití za cenu velikosti kolem 7,5 kB. SHRIMPS má částečný + stav v tom smyslu, že sice není nutné udržovat globální stav, ale každé + podpisové zařízení musí ukládat pár bitů stavu pro každý klíč, se kterým + podepisuje (a jen jediný bit, pokud pouze první podpis každého klíče ze + zařízení využívá výhody malých podpisů). + +## 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 31.0rc2][] je kandidátem na vydání příští hlavní verze + této převládající implementace plného uzlu. Dostupný je [průvodce + testováním][bcc31 testing]. + +- [Core Lightning 26.04rc2][] je kandidátem na vydání příští hlavní verze této + populární implementace LN uzlu. Přináší další aktualizace splicingu a opravuje + chyby z předchozích kandidátů. + +- [BTCPay Server 2.3.7][] je menším vydáním tohoto platebního procesoru s možností + vlastního hostování. Migruje projekt na .NET 10, zlepšuje předplatné a + platby fakturami a přidává několik dalších vylepšení a oprav chyb. Vývojáři + rozšíření by měli následovat [průvodce migrace na .NET 10][btcpay net10]. + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #32297][] přidává do `bitcoin-cli` volbu `-ipcconnect`, aby + se mohl připojit a ovládat `bitcoin-node` instanci přes meziprocesovou + komunikaci (IPC) přes unixový soket namísto HTTP, pokud je Bitcoin Core + sestaven s příznakem `ENABLE_IPC` a uzel je spuštěn s `-ipcbind` (viz též + zpravodaje [č. 320][news320 ipc] a [č. 369][news369 ipc], _angl._). I když je + volba `-ipcconnect` vynechána, zkusí `bitcoin-cli` nejdřív použít IPC. Pokud + není dostupné, použije HTTP. Jedná se o součást projektu [oddělení do více + procesů][multiprocess]. + +- [Bitcoin Core #34379][] opravuje chybu způsobující selhání, pokud bylo RPC + `gethdkeys` (viz [zpravodaj č. 297][news297 rpc]) voláno s `private=true` + a pokud peněženka obsahovala nějaký [deskriptor][topic descriptors], pro který + měla jen některé, ale ne všechny soukromé klíče. Podobně jako oprava pro + `listdescriptors` ([zpravodaj č. 389][news389 descriptor]) i toto PR vrací + dostupné soukromé klíče. Volání `gethdkeys private=true` nad peněženkami + pouze pro čtení nadále selhává. + +- [Eclair #3269][] přidává automatické znovuzískání likvidity z nečinného kanálu. + Když `PeerScorer` zjistí, že celkový objem plateb kanálu spadne v obou směrech + pod 5 % jeho kapacity, postupně sníží jeho [poplatky za přeposílání][topic + inbound forwarding fees] směrem k nastavenému minimu. Pokud jsou poplatky + v minimu nejméně pět dní a objem nezačne růst, Eclair tento kanál zavře, + pokud je pro peer spojení nadbytečný. Kanály jsou zavřeny pouze, pokud uzel + drží alespoň 25 % prostředků a místní zůstatek převyšuje existující nastavení + `localBalanceClosingThreshold`. + +- [LDK #4486][] začleňuje `rbf_channel` do `splice_channel` jako jediného styčného + bodu pro vytváření nových [spliců][topic splicing] a pro navyšování poplatků pro + stávající. Pokud splice již probíhá, návratová hodnota `FundingTemplate` + ze `splice_channel` vrací `PriorContribution`, aby mohli uživatelé + [navýšit poplatek][topic rbf] splicu bez [výběru mincí][topic coin selection]. + Viz též [zpravodaj č. 397][news397 rbf] pro související chování RBF během splicingu. + +- [LDK #4428][] přidává podporu pro otevírání a přijímání kanálů s nulovou rezervou + pro důvěryhodná peer spojení pomocí nové metody `create_channel_to_trusted_peer_0reserve`. + Kanály s nulovou rezervou umožňují protistraně kompletně utratit zůstatek kanálu. + Je to umožněno pro kanály s [anchor výstupy][topic anchor outputs] i pro kanály + s commitmenty bez poplatků (viz [zpravodaj č. 371][news371 0fc], _angl._). + +- [LND #9982][], [#10650][lnd #10650] a [#10693][lnd #10693] zlepšují nakládání + s [MuSig2][topic musig] noncemi u [taprootových][topic taproot] kanálů: + do `ChannelReestablish` přidává pole `LocalNonces`, aby mohla spojení + koordinovat více noncí u aktualizací souvisejících se [splicingem][topic splicing]. + `lnwire` validuje veřejné MuSig2 nonce během dekódování TLV u zpráv, které + nonce přenášejí, a dekódování `LocalNoncesData` validuje každý vstup. + +- [LND #10063][] rozšiřuje kooperativní zavření kanálu s [RBF][topic rbf] na + [jednoduché taprootové kanály][topic simple taproot channels] použitím [MuSig2][topic musig]. + Zprávy přenášejí nonce a částečné podpisy specifické pro [taproot][topic taproot] + a stavový automat používá MuSig2 sezení s just-in-time noncemi + pro `shutdown`, `closing_complete` a `closing_sig` (viz též [zpravodaj č. 347][news347 + rbf coop], který popisuje pozadí kooperativního zavření s RBF). + +{% include snippets/recap-ad.md when="2026-04-07 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="2130,32297,34379,3269,4486,4428,9982,10650,10693,10063" %} + +[topic payjoin]: /en/topics/payjoin/ +[topic payjoin fingerprinting]: https://delvingbitcoin.org/t/how-wallet-fingerprints-damage-payjoin-privacy/2354 +[c delving ibc hd]: https://delvingbitcoin.org/t/compact-isogeny-pqc-can-replace-hd-wallets-key-tweaking-silent-payments/2324 +[rr ml gsr bips]: https://groups.google.com/g/bitcoindev/c/T8k47suwuOM +[news374 varops]: /en/newsletters/2025/10/03/#first-bip +[news374 c2]: /en/newsletters/2025/10/03/#second-bip +[jn delving shrimps]: https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355 +[news383 sphincs]: /en/newsletters/2025/12/05/#slh-dsa-sphincs-post-quantum-signature-optimizations +[news391 shrincs]: /cs/newsletters/2026/02/06/#shrincs-324bajtove-stavove-postkvantove-podpisy-se-statickymi-zalohami +[wallet bip ml]: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8 +[news297 rpc]: /cs/newsletters/2024/04/10/#bitcoin-core-29130 +[news320 ipc]: /cs/newsletters/2024/09/13/#bitcoin-core-30509 +[news347 rbf coop]: /cs/newsletters/2025/03/28/#lnd-8453 +[news369 ipc]: /en/newsletters/2025/08/29/#bitcoin-core-31802 +[news371 0fc]: /en/newsletters/2025/09/12/#ldk-4053 +[news389 descriptor]: /cs/newsletters/2026/01/23/#bitcoin-core-32471 +[news397 rbf]: /cs/newsletters/2026/03/20/#ldk-4427 +[multiprocess]: https://github.com/bitcoin/bitcoin/issues/28722 +[bitcoin core 31.0rc2]: https://bitcoincore.org/bin/bitcoin-core-31.0/test.rc2/ +[Core Lightning 26.04rc2]: https://github.com/ElementsProject/lightning/releases/tag/v26.04rc2 +[BTCPay Server 2.3.7]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.3.7 +[bcc31 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide +[btcpay net10]: https://blog.btcpayserver.org/migrating-to-net10/ diff --git a/_posts/cs/newsletters/2026-04-10-newsletter.md b/_posts/cs/newsletters/2026-04-10-newsletter.md new file mode 100644 index 000000000..7ec8bc78b --- /dev/null +++ b/_posts/cs/newsletters/2026-04-10-newsletter.md @@ -0,0 +1,139 @@ +--- +title: 'Zpravodaj „Bitcoin Optech” č. 400' +permalink: /cs/newsletters/2026/04/10/ +name: 2026-04-10-newsletter-cs +slug: 2026-04-10-newsletter-cs +type: newsletter +layout: newsletter +lang: cs +--- +Zpravodaj tento týden přináší pravidelné rubriky se souhrnem sezení Bitcoin Core +PR Review Clubu a s popisem významných změn v populárních bitcoinových páteřních +projektech. + +## Novinky + +*V našich [zdrojích][sources] jsme tento týden nenašli žádné významné novinky.* + +## Bitcoin Core PR Review Club + +*V této měsíční rubrice shrnujeme nedávné sezení [Bitcoin Core PR Review Club][] a +vyzdvihujeme některé z důležitých otázek a odpovědí. Klikněte na otázku a odpověď se vám odhalí.* + +[Testování kandidátů na vydání Bitcoin Core 31.0][review club +v31-rc-testing] bylo sezení review clubu, během kterého se účastníci nezabývali +konkrétním PR, ale prováděli skupinové testování. + +Důsledné testování členy komunity před každým [hlavním vydáním Bitcoin Core][major Bitcoin Core release] +je nezbytné. Z tohoto důvodu sepíše dobrovolník průvodce testování kandidáta na +vydání, aby mohlo co nejvíce lidí efektivně testovat, aniž by museli sami zjišťovat, +co je nového, co se změnilo a jaké kroky je potřeba podniknout k jejich otestování. + +Testování může být náročné, protože nemusí být v případě neočekávaného chování +jasné, zda se jedná o chybu programu či omyl v testování. Reportování chyb, +které nejsou skutečnými chybami, plýtvá časem vývojářů. Sezení review klubu +se zabývá konkrétním kandidátem na vydání, aby se předešlo podobným problémům. + +[Průvodce testováním kandidáta na vydání 31.0][31.0 testing] sepsal [svanstaa][gh svanstaa] +(viz [Podcast #397][pod397 v31rc1]), který též sezení review clubu předsedal. + +Účastníci byli vyzýváni, aby si pro hledání inspirace k testování přečetli [poznámky +k vydání 31.0][31.0 release notes]. + +Průvodce testování pokrývá [mempool clusterů][topic cluster mempool] včetně nových +RPC a omezení (viz [zpravodaj č. 382][news382 bc33629], _angl._), zveřejňování +transakcí se zachováním soukromí (viz [zpravodaj č. 388][news388 bc29415]), RPC `getblock` s novým polem +`coinbase_tx` (viz [zpravodaj č. 394][news394 bc34512]), nový `txospenderindex` sledující, +které transakce každý výstup utrácí (viz [zpravodaj č. 394][news394 bc24539]), +zvýšené výchozí velikosti `-dbcache` (viz [zpravodaj č. 396][news396 bc34692]), vestavěných +dat pro ASMap (viz [zpravodaj č. 394][news394 bc28792]) a nového REST API `blockpart` +(viz [zpravodaj č. 386][news386 bc33657]). + +## Významné změny kódu a dokumentace + +_Významné změny z tohoto týdne v [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition +repo] a [repozitáři BINANA][binana repo]._ + +- [Bitcoin Core #33908][] přidává do C API `libbitcoinkernel` (viz [zpravodaj + č. 380][news380 kernel], _angl._) rozhraní `btck_check_block_context_free` + pro validaci kandidátů na bloky s bezkontextovými kontrolami: velikost/váha + limitů bloku, pravidla mincetvorné transakce a kontroly transakcí, které + nezávisí na stavu, indexu bloků nebo množině UTXO. Volající mohou též volitelně + ověřovat proof of work a Merkleův kořen. + +- [Eclair #3283][] přidává do plných odpovědí na volání hledání cest `findroute`, + `findroutetonode` a `findroutebetweennodes` pole `fee` (v msat). Toto pole + poskytuje celkový [poplatek za přeposílání][topic inbound forwarding fees] + v celé trase. Není tak již nutné tuto hodnotu počítat ručně. + +- [LDK #4529][] umožňuje operátorům nastavit pro oznámené a [neoznámené][topic + unannounced channels] kanály různé limity jako procento kapacity kanálu + během konfigurace celkové hodnoty příchozích [HTLC][topic htlc]. Výchozí + hodnota pro oznámené kanály je 25 %, pro neoznámené 100 %. + +- [LDK #4494][] mění vnitřní logiku [RBF][topic rbf], aby byla v souladu s pravidly + nahrazování během nízkých poplatků, jak stanoví [BIP125][]. Namísto pouhé + aplikace koeficientu poplatku 25/24 dle [BOLT2][] použije LDK nově buď tento + koeficient, nebo dodatečných 25 sat/kwu, podle toho, která hodnota je vyšší. + Objasnění související specifikace se diskutuje v [BOLTs #1327][]. + +- [LND #10666][] přidává RPC volání `DeleteForwardingHistory` a příkaz `lncli + deletefwdhistory`, které provozovatelům umožňují selektivně smazat události + o přeposílání starší než daný práh. Pro ochranu před nezáměrným smazáním + čerstvých dat musí být tato hodnota vyšší než jedna hodina. Tato funkce + umožňuje uzlům provádějícím routování smazat historické záznamy o přeposílání + bez potřeby mazat databázi nebo vypnout uzel. + +- [BIPs #2099][] zveřejňuje [BIP393][], který specifikuje syntax volitelných + anotací [deskriptorů][topic descriptors] výstupních skriptů. Ty umožňují + peněženkám ukládat data pro obnovu, jako je výška vzniku, pro urychlení + skenování peněženky (včetně skenování [tichých plateb][topic silent payments]). + Viz též [zpravodaj č. 394][news394 bip393], který tento BIP popisoval. + +- [BIPs #2118][] zveřejňuje [BIP440][] a [BIP441][] jako návrhy v sérii návrhů + velkého skriptového obrození (GSR, Great Script Restoration či Grand Script + Renaissance; viz též [zpravodaj č. 399][news399 bips]). + [BIP440][] navrhuje varops rozpočet (náklady opkódů závisejících na velikosti vstupů) + pro běhová omezení skriptu (viz [zpravodaj č. 374][news374 varops], _angl._). + [BIP441][] popisuje novou verzi [tapscriptu][topic tapscript], která obnovuje + opkódy deaktivované v roce 2010 jako [OP_CAT][topic op_cat] (viz + [zpravodaj č. 374][news374 tapscript], _angl._) a omezuje náklady vyhodnocování + skriptů dle varops rozpočtu z BIP440. + +- [BIPs #2134][] přidává do [BIP352][] ([tiché platby][topic silent payments]) + varování vývojářům peněženek, aby pravidla filtrování (např. [prachu][topic + uneconomical outputs]) neovlivňovala rozhodnutí, zda má skenování po nalezení + platby pokračovat. V opačném případě hrozí předčasné ukončení skenování a peněženka + by mohla postrádat pozdější výstupy od stejného odesílatele. + +{% include snippets/recap-ad.md when="2026-04-14 16:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="33908,3283,4529,4494,10666,2099,2118,2134,1327" %} +[sources]: /en/internal/sources/ +[news380 kernel]: /en/newsletters/2025/11/14/#bitcoin-core-30595 +[news394 bip393]: /cs/newsletters/2026/02/27/#navrh-bipu-na-anotace-deskriptoru-vystupnich-skriptu +[news399 bips]: /cs/newsletters/2026/04/03/#rozpocet-varops-operaci-a-tapscriptovy-list-0xc2-skriptove-obrozeni-maji-bip-440-a-441 +[news374 varops]: /en/newsletters/2025/10/03/#first-bip +[news374 tapscript]: /en/newsletters/2025/10/03/#second-bip +[BIP393]: https://github.com/bitcoin/bips/blob/master/bip-0393.mediawiki +[BIP440]: https://github.com/bitcoin/bips/blob/master/bip-0440.mediawiki +[BIP441]: https://github.com/bitcoin/bips/blob/master/bip-0441.mediawiki +[review club v31-rc-testing]: https://bitcoincore.reviews/v31-rc-testing +[major bitcoin core release]: https://bitcoincore.org/en/lifecycle/#versioning +[31.0 release notes]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Notes-Draft +[31.0 testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Candidate-Testing-Guide +[gh svanstaa]: https://github.com/svanstaa +[pod397 v31rc1]: /en/podcast/2026/03/24/#bitcoin-core-31-0rc1-transcript +[news382 bc33629]: /en/newsletters/2025/11/28/#bitcoin-core-33629 +[news388 bc29415]: /cs/newsletters/2026/01/16/#bitcoin-core-29415 +[news394 bc34512]: /cs/newsletters/2026/02/27/#bitcoin-core-34512 +[news394 bc24539]: /cs/newsletters/2026/02/27/#bitcoin-core-24539 +[news396 bc34692]: /cs/newsletters/2026/03/13/#bitcoin-core-34692 +[news394 bc28792]: /cs/newsletters/2026/02/27/#bitcoin-core-28792 +[news386 bc33657]: /cs/newsletters/2026/01/02/#bitcoin-core-33657