Tento týden přinášíme popis návrhu na nahrazování transakcí verze 3 pomocí RBF pravidel k usnadnění přechodu na cluster mempool a souhrn polemiky proti OP_CHECKTEMPLATEVERIFY na základě jeho potřeby exogenních poplatků. Též nechybí naše pravidelné rubriky se souhrnem zajímavých otázek a odpovědí z Bitcoin Stack Exchange, oznámeními o nových vydáních a popisem významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Příbuzenské nahrazování poplatkem: Gloria Zhao zaslala do fóra Delving Bitcoin příspěvek o nahrazování transakcí příbuznými transakcemi i bez existence konfliktu mezi nimi. Dvě transakce jsou v konfliktu, pokud nemohou obě dvě zároveň existovat ve validním blockchainu. Obvyklým důvodem je utracení stejného UTXO, což porušuje pravidlo proti dvojímu utracení. Pravidla RBF porovnávají transakci v mempoolu oproti nově obdržené transakci, která je s ní v konfliktu. Zhao navrhuje idealizovaný způsob, jak nakládat s konflikty: má-li přeposílající uzel dvě transakce, z nichž akceptována může být pouze jedna, měl by vybrat ne první, ale tu, která nejlépe vyhovuje provozovatelovým cílům (např. maximalizace příjmů z těžby a omezení přeposílání zdarma). Pravidla RBF aplikují toto pravidlo na konflikty, Zhao ve svém příspěvku tuto myšlenku rozšiřuje i na příbuzné transakce.

    Bitcoin Core aplikuje pravidla omezující počet a velikost příbuzných transakcí, které mohou být zároveň v mempoolu. To zabraňuje několika druhům DoS útoků, ale také kvůli tomu může mempool odmítnout transakci B proto, že předtím obdržel transakci A a tím bylo dosaženo limitu. Toto je v rozporu s výše popsaným principem: namísto toho by měl Bitcoin Core akceptovat A či B v souladu se svými cíli.

    Navrhovaná pravidla pro přeposílání transakcí verze 3 povolují, aby měl nepotvrzený v3 rodič v mempoolu pouze jediného potomka. Jelikož žádná z těchto transakcí nemůže mít žádné další předky v mempoolu, aplikace existujících pravidel RBF na nahrazení tohoto potomka je snadná a Zhao ji již naimplementovala. Pokud by existující LN commitment transakce s anchor výstupy automaticky přijaly pravidla v3, jak popisuje minulé číslo zpravodaje, byla by každá ze stran vždy schopna navýšit poplatek commitment transakce:

    • Alice může poslat commitment transakci s potomkem pro placení poplatků.

    • Alice může poté navýšit poplatek potomka pomocí RBF.

    • Bob může použít příbuzenského nahrazení k vyhození Alicina potomka zasláním svého vlastního potomka, který platí vyšší poplatky.

    • Alice může poté použít příbuzenského nahrazení na Bobova potomka zasláním svého potomka s ještě vyšším poplatkem (Bobův potomek by tak byl vyhozen).

    Přidání tohoto pravidla a jeho automatická aplikace na existující LN anchory umožní odstranit pravidlo CPFP carve-out. Toto odstranění je nutné pro implementaci cluster mempoolu, který by měl v budoucnu umožnit nejrůznější druhy nahrazení v souladu s ekonomickými záměry těžařů.

    V době psaní zpravodaje nenadnesl ve fóru nikdo proti této myšlence žádné námitky. Jeden přispěvatel se tázal, zda by se tímto staly dočasné anchory nepotřebnými. Autor tohoto návrhu Gregory Sanders odpověděl: „Neplánuju přestat pracovat na dočasných anchorech. Nulové výstupy mají několik důležitých použití i mimo LN.”

  • ● Opozice vůči CTV kvůli vyžadování exogenních poplatků: Peter Todd zaslal do emailové skupiny Bitcoin-Dev příspěvek se svými argumenty proti exogenním poplatkům (viz zpravodaj č. 284) aplikovanými na navrhovaný OP_CHECKTEMPLATEVERIFY. Poznamenává, že „v mnoha (ne-li ve všech) případech, kdy je CTV použito k umožnění sdílení jednoho UTXO mezi několika stranami, je náročné až nemožné zajistit, aby všechny varianty CTV pokryly všechny možné jednotkové poplatky. Očekává se, že CTV budou obvykle používané spolu s anchor výstupy, které budou platit poplatky, […] nebo snad i pomocí soft forku sponzorovaných transakcí. […] Požadavek, aby měl každý uživatel k dispozici UTXO na placení poplatků, je v rozporu s nabízenou efektivitou schémat sdílení UTXO použitím CTV. […] Jedinou realistickou alternativou je zaplatit za UTXO pomocí třetí strany (např. LN platbou), ale to už by bylo výhodnější zaplatit poplatek mimo blockchain. To je pochopitelně velice nežádoucí z pohledu centralizace těžby.” (Odkazy přidal Optech.) Doporučuje vzdát se CTV a namísto toho pracovat na schématech kovenantů, která jsou kompatibilní s RBF.

    John Law odpověděl, že díky časovým zámkům závislým na poplatku (viz zpravodaj č. 283) by mohlo být CTV s endogenními poplatky bezpečné v případech, kdy je potřebné dosáhnout potvrzení transakce před vypršením nějaké lhůty. Na druhou stranu by časové zámky závislé na poplatcích mohly na velmi dlouho pozdržet některá vyrovnání kontraktů.

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

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.

  • ● HWI 2.4.0 je vydáním další verze tohoto balíčku poskytujícího společné rozhraní několika různým hardwarovým podpisovým zařízením. Nové vydání přidává podporu pro Trezor Safe 3 a obsahuje několik drobných vylepšení.

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 #29291 přidává test, který selže, pokud má transakce spouštějící opkód OP_CHECKSEQUENCEVERIFY záporné číslo verze. Pokud by byl tento test spouštěn alternativními implementacemi konsenzu, odhalil by chybu zmíněnou v minulém čísle.

  • ● Eclair #2811, #2813 a #2814 přidávají trampolínovým platbám možnost použít zaslepenou cestu ke konečnému příjemci. Trampolínové routování samo o sobě nadále používá běžné identifikátory uzlu zašifrované v onion zprávě, každý trampolínový uzel se tedy dozví identifikátor následujícího trampolínového uzlu. Avšak je-li použita zaslepená cesta, poslední trampolínový uzel se nově dozví pouze počáteční uzel zaslepené cesty. Nedozví se identifikátor konečného příjemce.

    Dříve záviselo soukromí trampolín na použití několika trampolínových přeposílajících uzlů, aby žádný z nich s jistotou nevěděl, jsou-li posledním přeposílajícím. Nevýhodou tohoto přístupu je používání delších cest, které zvyšovaly pravděpodobnost selhání a vyžadovaly platbu vyšších poplatků. Nově přeposlání platby i přes jediný trampolínový uzel zabrání, aby se tento uzel dozvěděl konečného příjemce.

  • ● LND #8167 umožňuje, aby LND uzel kooperativně zavřel kanál, který má stále jednu či více čekajících plateb (HTLC). BOLT2 specifikace určuje, že správným řešením je, aby jedna strana poslala zprávu shutdown, po které nebudou přijata žádná nová HTLC. Poté, co jsou všechna čekající HTLC vyřízena offchain, obě strany si vyjednají a podepíší transakci kooperativního uzavření. Když v předchozích verzích LND obdrželo zprávu shutdown, uzavřelo kanál jednostranně, což si vyžádalo nadbytečné onchain transakce a poplatky.

  • ● LND #7733 přidává do strážní věže možnost zálohy a vynucení správného uzavření jednoduchých taprootových kanálů, které jsou nyní v LND experimentálně podporovány.

  • ● LND #8275 počíná od spojení vyžadovat podporu určitých univerzálně nasazených vlastností dle specifikace v BOLTs #1092 (viz zpravodaj č. 259).

  • ● Rust Bitcoin #2366 zastarává metodu .txid() objektů Transaction a nahrazuje ji metodou .compute_txid(). Kdykoliv je metoda .txid() volána, je txid transakce vypočítáno nově, což spotřebovává u velkých transakcí či velkého množství malých transakcí významný procesorový čas. Nové jméno pomůže programátorům uvědomit si potenciální náklady volání metody. Metody .wtxid() a .ntxid() (založené na BIP141, respektive na BIP140) jsou podobným způsobem přejmenovány na .compute_wtxid() a .compute_ntxid().

  • ● HWI #716 přidává podporu pro hardwarové podpisové zařízení Trezor Safe 3.

  • ● BDK #1172 přidává do peněženky API pro registraci jednotlivých bloků. Uživatel s přístupem k množině bloků může postupně, blok po bloku, aktualizovat peněženku dle transakcí z těchto bloků. To může být použito pro každý blok v řetězci. Software dále může použít nějaký způsob filtrování (např. kompaktní filtry bloků) k nalezení pouze takových bloků, které pravděpodobně obsahují transakce relevantní pro peněženku, a může tedy uvažovat pouze tuto podmnožinu bloků.

  • ● BINANAs #3 přidává BIN24-5 se seznamem repozitářů s bitcoinovými specifikacemi, jakou jsou BIPy, BOLTy, BLIPy, SLIPy, LNPBP a specifikace DLC. Též jsou vyjmenovány repozitáře se specifikacemi i jiných, souvisejících projektů.