Tento týden přinášíme odkaz na specifikaci navrhovaného opkódu OP_TXHASH. Nechybí též naše pravidelné rubriky se souhrnem sezení Bitcoin Core PR Review Club, oznámeními o nových vydáních a popisem významných změn v populárních páteřních bitcoinových projektech.

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í.

util: Typově bezpečné identifikátory transakcí je PR od Niklase Göggeho (dergoegge), které zvyšuje typovou bezpečnost zavedením odlišných typů pro txid (identifikátor transakce, který neobsahuje data segwitových witnessů) a wtxid (obsahující data segwitových witnessů). Dříve byly oba identifikátory reprezentovány typem uint256 (256bitové celé číslo, které může obsáhnout SHA256 hash). PR by nemělo mít žádný dopad na provoz, cílí na zabránění případných programátorských chyb, kvůli kterým by mohl být jeden druh identifikátoru nesprávně použit namísto druhého. Podobné chyby budou nově odhaleny v době kompilace.

Za účelem minimalizace zásahů a usnadnění revize budou tyto nové typy použity nejdříve v jediné části kódu (v „sirotčinci” transakcí), budoucí PR pak jejich použíti mohou rozšiřovat dále.

  • Co znamená, když je identifikátor transakce typově bezpečný? Proč je to důležité či užitečné? Přináší to nějaké nevýhody?

    Typová bezpečnost zaručuje, že identifikátor transakce, který může nabývat dvou různých významů (txid či wtxid), nemůže být použit s nesprávným významem. Tedy txid nemůže být použito, je-li očekáváno wtxid, a naopak. Tato vlastnost je vynucována kompilátorem během typové kontroly. ➚

  • Mělo být raději upřednostněno začlenění (obalení) typu uint256 uvnitř nových tříd Txid a Wtxid před děděním z uint256? Jak si tyto dva přístupy stojí v porovnání?

    Tyto třídy by mohly dědit, ale v důsledku by bylo potřeba pozměnit mnohem víc řádků zdrojového kódu. ➚

  • Proč je lepší vynucovat typy během kompilace než za běhu?

    Vývojáři nacházejí chyby rychleji během kódování a nemusí spoléhat na psaní rozsáhlých testů, který by je odhalily za běhu (tyto testy navíc nemusí všechny chyby najít). Avšak testování je i nadále užitečné, neboť typová bezpečnost nezabrání zvolení nesprávného typu identifikátoru. ➚

  • Kdy byste měli během psaní nového kódu odkazujícího na transakce použít txid a kdy wtxid? Můžete ukázat na nějaké příklady kódu, kdy by jejich záměna vedla k problémům?

    Obecně je používání wtxid preferováno, neboť obsahuje celou transakci. Důležitou výjimkou je prevout, který ve vstupech odkazuje na utrácený výstup (UTXO) a musí být txid. Zde je příklad, ve kterém je důležité použít jeden a nikoliv druhý typ (pro podrobnosti viz zpravodaj č. 104, angl.). ➚

  • Jakým způsobem by mohlo používání transaction_identifier namísto uint256 odhalit existující chybu či zabránit zanesení nové? Na druhou stranu, mohla by tato změna přinést nové chyby?

    Bez tohoto PR bychom mohli funkci, která vyžaduje argument typu uint256 (např. identifikátor bloku), předat txid. Po tomto PR to vyvolá chybu kompilace. ➚

  • Již existuje třída GenTxid. Jakým způsobem vynucuje typovou správnost a jak se odlišuje od přístupu z tohoto PR?

    Tato třída obsahuje hash a příznak určující, je-li hash wtxid či txid. Jedná se tedy o jediný typ a ne o dva odlišné. Typovou kontrolu umožňuje, ale musí být explicitně napsána v kódu a, co je důležitější, může být prováděna pouze za běhu. Řeší případy, ve kterých chceme předat kterýkoliv ze dvou druhů identifikátoru. Proto toto PR GenTxid neodstraňuje. V budoucnu může být vhodnější alternativou std::variant<Txid, Wtxid>. ➚

  • Jak je možné, že transaction_identifier rozšiřuje uint256, když jsou v C++ celá čísla typy a na třídami?

    Protože samo uint256 je třídou a ne vestavěným typem. (Největší vestavěný celočíselný typ má v C++ 64 bitů.) ➚

  • Chová se jinak uint256 stejně jako například uint64_t?

    Ne, aritmetické operace nejsou nad uint256 povoleny, protože nedávají pro hashe, které jsou hlavním použitím uint256, smysl. Jméno je zavádějící, jedna se opravdu jen o shluk 256 bitů. Existuje též arith_uint256, který aritmetické operace povoluje (používaný například pro PoW výpočty). ➚

  • Proč transaction_identifier rozšiřuje uint256 namísto vytvoření zcela nového typu?

    Umožňuje nám prozatím ponechat beze změn kód, který očekává identifikátor transakce ve formě uint256 , a použít explicitní i implicitní konverze. Kód může být ve vhodný čas refaktorován, aby používal striktnější typy Txid či Wtxid. ➚

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.

  • ● LDK 0.0.117 je kandidátem na vydání této knihovny pro budování LN aplikací. Přináší opravy bezpečnostních chyb související s anchor výstupy přidanými v předchozím vydání. Dále mimo jiné zlepšuje hledání cest, podporu strážní věže a umožňuje dávkové financování nových kanálů.

  • ● BDK 0.29.0 je kandidátem na vydání této knihovny pro budování peněženek. Aktualizuje závislosti a opravuje (pravděpodobně vzácnou) chybu objevující se v případech, kdy peněženka obdržela více než jeden výstup z coinbasových transakcí.

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 a Bitcoin Inquisition.

  • ● Bitcoin Core #27596 uzavírá první fázi projektu assumeutxo. Přináší všechny zbývající změny potřebné pro používání assumedvalid snapshot chainstate i pro plně validovanou synchronizaci na pozadí. UTXO snapshoty lze načíst voláním loadtxoutset. Dále přidává do chainparams parametr assumeutxo.

    I když celý soubor nových funkcí nebude ještě před samotnou aktivací na mainnetu přístupný, přináší tato změna vyvrcholení několikaleté práce. Projekt, který byl navržen v roce 2018 a formalizován v roce 2019, výrazně zpříjemní používání nových plných uzlů a jejich připojení do sítě. Související následné změny: Bitcoin Core #28590, #28562 a #28589.

  • ● Bitcoin Core #28331, #28588, #28577 a GUI #754 přidávají podporu šifrovaného P2P přenosu verze 2 dle specifikace v BIP324. Tato funkce je ve výchozím nastavení neaktivní, může být však zapnuta volbou -v2transport.

    Šifrovaný přenos pomáhá navýšit soukromí bitcoinových uživatelů tím, že zabraňuje pasivním pozorovatelům (jako jsou například poskytovatelé internetového připojení) přímo zjistit, jaké transakce uzly přeposílají svým spojením. Je též možné porovnáváním identifikátorů sezení zabránit aktivním man-in-the-middle odposloucháním. V budoucnu přidané další funkce mohou usnadnit lehkým klientům bezpečné připojení k důvěryhodným uzlům.

  • ● Bitcoin Core #27609 zpřístupňuje RPC volání submitpackage i na jiných sítích než regtest. Uživatelé mohou pomocí tohoto volání odesílat balíčky jediné transakce s jejími nepotvrzenými předky, pokud žádný z předků neutrácí výstup jiného předka. Potomek může být použit k provedení CPFP předků, jejichž jednotkový poplatek spadá pod dynamické minimum mempoolu uzlu. Jelikož však přeposílání balíčků není ještě podporováno, nemusí se tyto transakce dostat k ostatním uzlům v síti.

  • ● Bitcoin Core GUI #764 odstraňuje z GUI možnost vytvářet zastaralé typy peněženek. Všechny nově vytvořené peněženky v budoucích verzích Bitcoin Core budou založeny na deskriptorech.

  • ● Core Lightning #6676 přidává nové RPC volání addpsbtoutput, které přidá do PSBT výstup pro příjem onchain prostředků peněženkou uzlu.