Zpravodaj tento týden popisuje návrh protokolu pro používání tichých plateb lehkými klienty, shrnuje návrhy dvou deskriptorů pro taproot a odkazuje na diskuzi o tom, zda by měly být soft forkem přidávány opkódy s překrývajícími se schopnostmi. Též nechybí naše pravidelné rubriky s populárními otázkami a odpověďmi z Bitcoin Stack Exchange, oznámeními nových vydání a souhrnem významných změn v populárním bitcoinovém páteřním software.

Novinky

• ● Protokol pro tiché platby v lehkých klientech: Setor Blagogee zaslal do fóra Delving Bitcoin příspěvek s popisem návrhu specifikace protokolu, který by umožnil lehkým klientům přijímat tiché platby (SP). Přidání několika kryptografických primitiv postačuje k rozšíření možností peněženek o odesílání SP, ale kromě těchto primitiv vyžaduje přijímání SP přístup k informacím o každé onchain transakci kompatibilní s SP. Pro plné uzly jako Bitcoin Core je to snadný úkol, neboť již zpracovávají každou onchain transakci, avšak na lehké klienty, které se snaží minimalizovat množství vyžadovaných dat, to klade nové požadavky.

  V základním protokolu generuje nějaký poskytovatel služby pro každý blok index veřejných klíčů, které mohou být použity s tichými platbami. Klient tento index stáhne spolu s kompaktními filtry bloků stejného bloku. Klient pro každý z klíčů (nebo sadu klíčů) spočítá svůj tweak a určí, zda filtr bloků obsahuje platbu na korespondující tweaknutý klíč. Pokud ano, klient stáhne dodatečná data, která mu umožní určit výši přijaté částky a později tuto platbu utratit.

• ● Nezpracované taprootové deskriptory: Oghenovo Usiwoma zaslal do fóra Delving Bitcoin příspěvek s návrhem dvou nových deskriptorů pro konstruování taprootových platebních podmínek:

  • rawnode(<hash>) obsahuje haš uzlu Merkleova stromu, ať již vnitřního uzlu či listu. To umožní peněžence či jinému skenovacímu programu nalézt konkrétní výstupní skripty bez nutnosti přesně znát, jaké tapscripty obsahují. Ve většině případů se nejedná o bezpečný způsob přijímání peněz (neznámý skript může být neutratitelný nebo může umožnit třetí straně prostředky utratit), avšak mohou existovat protokoly, kde je takové použití bezpečné.

    Anthony Towns poskytl příklad, ve kterém Alice chce, aby mohl Bob zdědit její peníze. Za své učiněné platby poskytne Alice Bobovi pouze nezpracované haše uzlů. Pro Bobovo dědictví poskytne Alice Bobovi šablonu deskriptoru (obsahující například časový zámek, aby nemohl Bob prostředky utratit před vypršením nějaké doby). Tento způsob je pro Boba bezpečný, neboť peníze nejsou jeho, a je výhodný pro Alicino soukromí, neboť nemusí Bobovi dopředu odhalit žádnou ze svých platebních podmínek (ačkoliv se o nich může Bob dozvědět z Aliciných onchain transakcí).

  • rawleaf(<script>,[version]) je podobný existujícímu deskriptoru raw pro začlenění skriptů, které nemohou být vyjádřeny šablonou deskriptoru. Hlavním rozdílem je, že obsahuje možnost určit odlišnou verzi taprootového listu, než která je v BIP342 specifikována jako výchozí verze pro tapscript.

  Usiwomaův příspěvek poskytuje příklad a odkazuje na předchozí diskuzi a svou referenční implementaci.

• ● Měly by se překrývající se návrhy na soft forky vzájemně vylučovat? Pierre Rochard se ptá, zda by navrhované soft forky, které by poskytovaly podobné funkce s podobnými náklady, měly být považovány za vzájemně se vylučující, nebo zda by mělo smysl aktivovat více návrhů a nechat vývojáře, ať si vyberou své preferované alternativy.

  Anthony Towns reagoval na několik bodů. Mimo jiné se domnívá, že překrývající se funkce nejsou samy o sobě problematické, avšak problémy mohou přinést funkce, které nejsou vůbec používané, protože každý preferuje nějakou jinou alternativu. Navrhuje, aby kdokoliv, kdo upřednostňuje nějaký konkrétní návrh, otestoval jeho funkce v předprodukčním software, ať se s ním náležitě seznámí, obzvláště v porovnání s alternativami nabízejícími podobné funkce.

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 nejmenší možná coinbasová transakce / velikost bloku? Antoine Poinsot objasňuje minima kolem coinbasové transakce a uzavírá tvrzením, že nejmenší možný validní bitcoinový blok v současných výškách má 145 bajtů.

• ● Jak rozumět kódování čísel Scriptu a CScriptNum? Antoine Poinsot popisuje, jakým způsobem CScriptNum reprezentuje celá čísla v bitcoinovém Scriptu, poskytuje příklady kódování a odkazuje na dvě implementace serializace.

• ● Je možné zveřejnit adresu BTC peněženky, ale neodhalit, kolik BTC obsahuje? Vojtěch Strnad vysvětluje, že opakovaně použitelné adresy tichých plateb umožňují publikování platebního identifikátoru bez možnosti určit, které transakce na něj posílají prostředky.

• ● Testování vysokých poplatků na regtestu Ava Chow doporučuje pro testování v simulovaném prostředí s vysokými poplatky na regtestu používat testovací framework Bitcoin Core a nastavit -maxmempool na nízkou hodnotu a -datacarriersize na vysokou hodnotu.

• ● Proč je můj P2P V2 peer připojen přes v1? Pieter Wuille se domnívá, že za případem, kdy byl peer podporující šifrovaný transport dle BIP324 připojen přes v1 nešifrované spojení, stály zastaralé informace o adrese.

• ● Posílá P2PKH transakce na haš komprimovaného nebo nekomprimovaného klíče? Pieter Wuille poznamenává, že použity mohou být komprimované i nekomprimované veřejné klíče s rozdílnými výslednými P2PKH adresami, a dodává, že P2WPKH dle pravidel povolují pouze komprimované veřejné klíče a P2TR používá x-only veřejné klíče.

• ● Jaké existují způsoby zveřejnění bloku v bitcoinové síti? Pieter Wuille vypisuje čtyři způsoby oznamování bloků v P2P síti: pomocí BIP130, pomocí BIP152, posláním nevyžádané zprávy block a starší kombinací zpráv inv / getdata / block.

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.

• ● LND v0.18.0-beta je nejnovějším hlavním vydáním této populární implementace LN uzlu. Dle poznámek k vydání byla přidána experimentální podpora pro příchozí poplatky za přeposlání (viz zpravodaj č. 297), bylo zpřístupněno hledání tras pro zaslepené cesty, strážní věže nově podporují jednoduché taprootové kanály, bylo zjednodušeno sdílení zašifrovaných informací pro ladění (viz zpravodaj č. 285) a přidáno bylo mnoho dalších nových funkcí. Vydání též přináší mnoho oprav chyb.

• ● Core Lightning 24.05rc2 je kandidátem na vydání příští hlavní verze této populární implementace 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, Bitcoin Inquisition a repozitáři BINANA.

• ● Bitcoin Core #29612 upravuje formát exportované serializované sady UTXO vytvořené pomocí RPC volání dumptxoutset. Výsledkem je o 17,4 % nižší použitý prostor. RPC volání loadtxoutset nyní během načítání ze souboru očekává tento nový formát, starý formát již není podporován. Zpravodaje č. 178 a č. 72 (oba angl.) též odkazují na dumptxoutset.

• ● Bitcoin Core #27064 mění na Windows u čerstvých instalací výchozí složku pro data z C:\Users\Username\AppData\Roaming\Bitcoin na C:\Users\Username\AppData\Local\Bitcoin.

• ● Bitcoin Core #29873 přináší váhový limit o hodnotě 10 kvB na transakce do potvrzení topologicky omezené (Topologically Restricted Until Confirmation, TRUC; též „v3 transakce”). Tento limit snižuje potenciální náklady na obranu před pinningem transakcí, navyšuje efektivitu konstrukce šablon bloků a vynucuje přísnější limity na některé datové struktury. V3 transakce jsou podmnožinou standardních transakcí s dodatečnými pravidly navrženými tak, aby umožnily nahrazování transakcí a zároveň minimalizovaly náklady na překonání pinningových útoků. Více informací o v3 transakcích lze nalézt ve zpravodajích č. 289 a č. 296.

• ● Bitcoin Core #30062 přidává do RPC volání getrawaddrman dvě nová pole mapped_as a source_mapped_as. Tento příkaz vrací informace o síťových adresách uzlů spojení. Nová pole vrátí Autonomous System Number (ASN) namapované na spojení a jeho zdroj a tím poskytnou přibližné informace o tom, která ISP kontrolují které IP adresy. To navýší odolnost Bitcoin Core vůči útokům zastíněním. Viz též zpravodaje č. 52, č. 83, č. 101 (vše angl.) a č. 290.

• ● Bitcoin Core #26606 přináší BerkeleyRODatabase, nezávislou implementaci parseru souborů Berkeley Database (BDB), která přináší podporu pro čtení BDB souborů. Data zastaralých peněženek tak mohou být extrahována bez závislosti na těžkotonážní BDB knihovně, čímž se usnadní migrace na deskriptorové peněženky. Příkaz dump nástroje wallettool byl změněn, aby používal BerkeleyRODatabase.

• ● BOLTs #1092 pročišťuje specifikace Lightning Network odstraněním nepoužívaných či dlouho nepodporovaných schopností initial_routing_sync a option_anchor_outputs. Předpokládá se, že tři schopnosti jsou podporovány každým uzlem: var_onion_optin pro onion zprávy s proměnlivou velikostí pro posílání libovolných dat konkrétním uzlům, option_data_loss_protect, aby mohly uzly během opakovaného připojení poslat informace o posledním stavu kanálu, a option_static_remotekey umožňující uzlu požadovat, aby se každá aktualizace kanálu zavázala poslat ne-HTLC prostředky uzlu na stejnou adresu. Schopnost gossip_queries byla pozměněna tak, aby uzel bez její podpory nebyl na konkrétní gossip požadavky dotazován jinými uzly. Viz též zpravodaj č. 259.