/ home / newsletters /
Zpravodaj „Bitcoin Optech” č. 398
Zpravodaj tento týden přináší naše pravidelné rubriky s vybranými otázkami a odpověďmi z Bitcoin Stack Exchange, 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
V našich zdrojích jsme tento týden nenašli žádné významné novinky.
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ů.
-
● Co se myslí tím, že „bitcoin nepoužívá šifrování”? Pieter Wuille rozlišuje mezi šifrováním za účelem skrývání dat před neautorizovanými účastníky (což bitcoinové ECDSA neumí) a digitálními podpisy, které bitcoin používá pro autentizaci a ověřování.
-
● Kdy a proč se Bitcoin Script posunul ke strukturám odhalujícím podmínky utrácení? Uživatel bca-0353f40e vysvětluje přechod z původního přístupu, kdy uživatelé platili přímo na veřejné klíče, přes P2PKH a P2SH k segwitu a taprootu, kde jsou platební podmínky stanoveny ve výstupu a odhaleny jsou pouze během utrácení.
-
● Vyzrazuje P2TR-MS (taprootový multisig M-z-N) veřejné klíče? Murch potvrzuje, že taprootové vícenásobné podpisy v podobě taprootového skriptu s jedním listem odhalují při placení všechny patřičné veřejné klíče, neboť OP_CHECKSIG i OP_CHECKSIGADD vyžadují jejich přítomnost.
-
● Umožňuje OP_CHECKSIGFROMSTACK záměrně opakovaně používat podpisy napříč UTXO? Uživatel bca-0353f40e vysvětluje, že OP_CHECKSIGFROMSTACK (BIP348) záměrně nesvazuje podpisy s konkrétními vstupy, díky čemuž může být CSFS kombinováno s jinými kovenantovými opkódy. To přinese možnost svazovat podpisy s novými platebními podmínkami (rebindable signatures), což je potřebné pro LN-Symmetry.
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 28.4 je údržbovým vydáním předchozí hlavní řady této převládající implementace plného uzlu. Přináší hlavně opravy migrace peněženek a odstraňuje nespolehlivý DNS seed. Poznámky k vydání obsahují další podrobnosti.
-
● Core Lightning 26.04rc1 je kandidátem na vydání příští hlavní verze tohoto populárního LN uzlu. Přináší mnoho aktualizací splicingu a opravy chyb.
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 #33259 přidává do odpovědi na RPC volání
getblockchaininfopolebackgroundvalidation, pokud uzel používá assumeUTXO snapshoty. Nové pole obsahuje výšku snapshotu, aktuální výšku a haš bloku pro validaci na pozadí, průměr času, vykonanou práci řetězce a postup ověřování. Dříve odpověď pouze ukazovala, zda stahování bloků a ověřování bylo již dokončeno. -
● Bitcoin Core #33414 aktivuje u automaticky vytvořených onion služeb Tor s ochranou pomocí dokladů o provedené práci (proof of work defenses), pokud ji připojený démon podporuje. Má-li démon přístupný port pro ovládání a je-li nastavení
listenonionv Bitcoin Core zapnuté (což je výchozí stav), je skrytá onion služba vytvořena automaticky. Tato funkce se netýká ručně vytvořených onion služeb, ale doporučuje se, aby uživatel ochranu aktivoval přidánímHiddenServicePoWDefensesEnabled 1do konfigurace. -
● Bitcoin Core #34846 přidává do C API
libbitcoinkernel(viz zpravodaj č. 380, angl.) funkcebtck_transaction_get_locktimeabtck_transaction_input_get_sequence, které umožní přístup k polím časových zámků:nLockTimetransakcí anSequencevstupů. Díky tomu je možné zkontrolovat pravidla dle BIP54 (pročištění konsenzu), jako jsou omezenínLockTimev mincetvorných transakcích, bez nutnosti ručního dekódování celé transakce (jiná pravidla BIP54, jako jsou sigops limity, stále vyžadují zvláštní zpracování). -
● Core Lightning #8450 rozšiřuje splicingový skriptovací engine v CLN o zpracování splicingu napříč kanály a splicingu s více než třemi kanály a o dynamický výpočet poplatků. Hlavním problémem, který tato změna řeší, je cyklická závislost v odhadování poplatků: přidání vstupů navyšuje váhu transakce a tedy i potřebný poplatek, což může vyžadovat dodatečné vstupy. Jedná se o potřebný krok pro vytvoření nových RPC příkazů
spliceinaspliceout. -
● Core Lightning #8856 a #8857 přidávají RPC příkazy
spliceinaspliceoutpro přidání prostředků z interní peněženky do kanálu a pro vyjmutí prostředků z kanálu do interní peněženky, na bitcoinovou adresu nebo do jiného kanálu (tedy tzv. cross-splice). Nové příkazy po provozovatelích nepožadují ruční vytváření splicingových transakcí pomocí experimentálního RPCdev-splice. -
● Eclair #3247 přidává volitelný systém pro ohodnocování peer spojení, který v čase sleduje příjmy za přeposílání a objem plateb. Je-li systém aktivní, pravidelně hodnotí peer spojení dle výdělečnosti a může automaticky přidat prostředky do nejvíce profitabilních kanálů, automaticky zavřít neproduktivní kanály či automaticky upravit poplatky za přeposílání na základě objemu plateb. Vše je možné konfigurací omezit. Před zapnutím automatizace mohou provozovatelé výsledky systému pozorovat.
-
● LDK #4472 opravuje teoretický scénář vedoucí ke ztrátě prostředků během otevírání kanálu a splicingu, ve kterém mohly být
tx_signaturesodeslány ještě před tím, než byl podpis commitmentu protistrany natrvalo uložen. Pokud by se tato transakce potvrdila a uzel by spadl, nebyl by schopen vynucovat stav svého kanálu. Oprava odkládá odeslánítx_signaturesdo doby, kdy je možné zprávu bezpečně odeslat. -
● LND #10602 přidává do experimentálního subsystému
switchrpc(viz zpravodaj č. 386) RPC voláníDeleteAttempts. Tento příkaz umožňuje volajícímu z úložiště LND smazat dokončené (úspěšně či neúspěšně) záznamy o pokusech o urovnání HTLC. -
● LND #10481 přidává do testovacího rámce LND podporu pro těžbu pomocí
bitcoind. Dřívelntestvyžadoval těžící backend založený nabtcd, i když pro operace s řetězcem používalbitcoind. Tato změna umožňuje testovat chování, které závisí na mempoolu a těžbě Bitcoin Core, včetně přeposílání transakcí verze 3 a přeposílání balíčků. -
● BOLTs #1160 zveřejňuje protokol splicingu v rámci lightningové specifikace. Nahrazuje tím návrh z BOLTs #863 a přidává aktualizované toky operací a testovací data pro mezní případy, které za přepisem specifikace stály (zpravodaj č. 246 popisuje diskuzi během práce na návrhu). Splicing umožňuje peer spojením přidat nebo odebrat prostředky bez nutnosti zavřít kanál. Vyjednávání o splicingu začíná navázáním protokolu chvíle ticha (quiescence, viz BOLTs #869 a zpravodaj č. 309). Text, který byl přidán do BOLT2, pokrývá interaktivní konstrukci splicingové transakce, provozování kanálu během čekání na její potvrzení, navyšování jejího poplatku pomocí RBF, proces opakovaného navázání spojení a uzamykání po dosažení dostatečné hloubky (
splice_locked). Dále aktualizuje oznamování kanálů.
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 31. 3. v 16:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.