Zpravodaj tento týden popisuje návrh na poskytování čitelných bitcoinových platebních instrukcí založených na DNS, shrnuje příspěvek s úvahou o mempoolu a souladu ekonomických podnětů, odkazuje na vlákno s diskuzí o designu Cashu a dalších ecashových systémů, krátce nahlíží na pokračující diskuzi o 64bitové aritmetice v bitcoinových skriptech (včetně specifikace již dříve navrženého opkódu) a poskytuje přehled vylepšeného procesu reprodukovatelné tvorby ASMap. Též nechybí naše pravidelné rubriky s popisem aktualizací klientů a služeb, nových vydání a významných změn v populárních bitcoinových páteřních projektech.

Novinky

  • ● Čitelné bitcoinové platební instrukce založené na DNS: v návaznosti na předchozí diskuzi (viz zpravodaj č. 278) zaslal Matt Corallo do fóra Delving Bitcoin příspěvek s návrhem BIPu, díky kterému bude možné přeložit řetězce jako example@example.com na DNS adresu jako například example.user._bitcoin-payment.example.com, která vrátí TXT záznam podepsaný DNSSEC obsahující URI dle BIP21, např. bitcoin:bc1qexampleaddress0123456. BIP21 URI mohou být rozšířené o podporu několika protokolů (viz BIP70 platební protokoly); například následující TXT záznam by určoval bech32m adresu jako alternativu pro jednoduché onchain peněženky, adresu tiché platby pro onchain peněženky s patřičnou podporou a LN nabídku pro LN peněženky:

    bitcoin:bc1qexampleaddress0123456?sp=sp1qexampleaddressforsilentpayments0123456&b12=lno1qexampleblindedpathforanoffer...

    Návrh BIPu neobsahuje podrobnosti ohledně podporovaných platebních protokolů. Corallo má dva další návrhy: BOLT a BLIP popisující detaily pro LN uzly. BOLT umožňuje vlastníkovi domény nastavit wildcard záznam jako *.user._bitcoin-payment.example.com, který se přeloží na BIP21 URI s parametrem omlookup obsahujícím zaslepenou cestu k uzlu, který po přijetí onion zprávy vrátí BOLT12 nabídku. Plátce, který by chtěl poslat nabídku na example@example.com, potom tomuto uzlu předá identifikátor příjemce (example) a tím bude moci uzel platbu řádně zpracovat. BLIP popisuje možnost, jak by mohl kterýkoliv LN uzel bezpečně tyto platební instrukce přeložit pro kterýkoliv jiný uzel pomocí komunikačního protokolu LN.

    V době psaní zpravodaje byla většina diskuze vedena pod PR v BIP repozitáři. Jeden příspěvek navrhoval použít HTTPS, které může být pro mnoho webových vývojářů přístupnější, ale vyžadovalo by dodatečné závislosti; Corallo řekl, že tuto část specifikace měnit nebude, ale napsal malou knihovnu s ukázkovou webovou stránkou, která za webové vývojáře vše vyřeší. Další příspěvek navrhoval použít existující systém překladu platebních adres založený na DNS OpenAlias, který je již podporován některým bitcoinovým software, např. Electrum. Dalším diskutovaným tématem byl způsob, jak adresy zobrazovat: mělo by to být example@example.com, @example@example.com, example$example.com či jinak?

  • ● Úvaha o mempoolu a souladu ekonomických podnětů: Suhas Daftuar zaslal do fóra Delving Bitcoin příspěvek s několika pohledy na kritéria, která za účelem maximalizace zisku mohou plné uzly použít k výběru transakcí přidaných do svých mempoolů, přeposílaných dalším uzlům a pro těžbu. Příspěvek začíná základními principy a pokračuje až na hranici současného výzkumu. Přístupné popisy by měly být srozumitelné každému, kdo se zajímá o design pravidel pro přeposílání transakcí. Mezi postřehy, které jsou podle nás nejzajímavější, patří:

    • ● Ryzí nahrazení jednotkovým poplatkem nezaručuje soulad ekonomických podnětů: zdá se, že nahrazení transakce platící nižší jednotkový poplatek transakcí platící vyšší jednotkový poplatek by mělo být pro pro těžaře vždy výhrou. Daftuar poskytuje jednoduchý ilustrovaný příklad ukazující, že to tak nemusí vždy být. Zpravodaj č. 288 obsahuje předešlou diskuzi o ryzím nahrazení jednotkovým poplatkem.

    • ● Těžaři s různými hashrate mají různé priority: těžař s 1 % hashrate celé sítě, který se vzdá začlenění konkrétní transakce do své šablony bloku a kterému se podaří nalézt blok, bude mít pouze 1% šanci na vytěžení následného bloku, který by mohl tuto transakci začlenit. Proto má malý těžař silný podnět k výběru co nejvyššího poplatky nyní, i za cenu výrazné redukce výše poplatku dostupného těžařům (i sobě samému) v budoucích blocích.

      V porovnání s ním bude mít těžař s 25 % hashrate, který se rozhodne nezačlenit transakci do bloku, 25% šanci na vytěžení následného bloku, který by mohl tuto transakci obsahovat. Pro tohoto velkého těžaře je výhodné odložit výběr některých poplatků na později, kdy mu to může s určitou pravděpodobností vynést vyšší poplatky.

      Daftuar nabízí příklad dvou konfliktních transakcí. Menší transakce platí vyšší jednotkový poplatek, větší transakce platí vyšší absolutní poplatek. Pokud by nebylo v mempoolu mnoho transakcí s jednotkovým poplatkem podobným větší transakci, blok obsahující tuto transakci by přinesl těžařovi více na poplatcích než blok s menší transakcí (s vyšším jednotkovým poplatkem). Avšak pokud by bylo v mempoolu mnoho transakcí s podobným jednotkovým poplatkem, jako má větší transakce, pro těžaře s menším podílem na celkovém hashrate může být výhodnější vytěžit menší transakci (vyšší jednotkový poplatek), aby získal co nejvíce na poplatcích nyní, zatímco těžař s větším podílem na celkovém hashrate může být motivován vyčkat, až bude výdělečné vytěžit větší transakci (nižší jednotkový poplatek) nebo až se odesílatel unaví čekáním a vytvoří verzi s ještě vyšším jednotkovým poplatkem. Odlišné podněty pro různé těžaře mohou indikovat, že neexistuje jeden univerzální soubor pravidel pro soulad ekonomických podnětů.

    • ● Bylo by užitečné nalézt pravidla souladu ekonomických podnětů, která nejsou odolná vůči DoS: Daftuar popisuje, jak se Bitcoin Core snaží implementovat pravidla, která jsou v souladu s ekonomickými podněty a zároveň jsou odolná vůči útokům odepření služby (DoS). Avšak poznamenává, že „zajímavou a hodnotnou oblastí výzkumu by bylo určit, zda-li existují (a pokud ano, charakterizovat je) chování v souladu s ekonomickým podněty, která nejsou odolná vůči DoS. Pokud existují, mohla by taková chování představovat podněty pro uživatele, aby se připojovali přímo k těžařům, což by mohlo být pro tyto strany vzájemně výhodné, ale celkově škodlivé pro decentralizaci těžby. […] Porozumění těmto scénářům by nám také mohlo pomoci během navrhování protokolů, které jsou odolné vůči DoS, jelikož bychom znali hranice možného.”

  • ● Diskuze o designu Cashu a dalších ecash systemů: před několika týdny zaslal vývojář Thunderbiscuit do fóra Delving Bitcoin příspěvek s popisem schématu zaslepených podpisů stojícího za chaumovským ecash systémem použitým v Cashu. Tento systém používá satoshi jako jednotku zůstatků a umožňuje odesílat a přijímat peníze pomocí bitcoinu a LN. Vývojáři Moonsettler a Zmnscpxj tento týden ve svých odpovědích uvedli některá omezení této jednoduché verze zaslepeného podepisování a popsali, jak by alternativní protokoly mohly přinést další výhody. Diskuze se vedla zcela v teoretické úrovni, ale věříme, že by mohla být zajímavá pro každého se zájmem o ecashové systémy.

  • ● Pokračující diskuze o 64bitové aritmetice a opkódu OP_INOUT_AMOUNT: několik vývojářů pokračovalo v diskuzu o potenciálním budoucím soft forku, který by mohl do bitcoinu přidat 64bitové aritmetické operace (viz zpravodaj č. 285). Většina diskuze se po naší předchozí zmínce soustředila na kódování 64bitových hodnot ve skriptech. Hlavním rozdílem je, zda používat formát minimalizující onchain data nebo formát co nejjednodušší pro programování. Dále se diskutovalo, zda používat celá čísla se znaménkem nebo povolit pouze celá čísla bez znaménka (pro neznalé, mezi které evidentně patří také jeden samozvaný brilantní bitcoinový inovátor: celá čísla se znaménkem indikují, jaké znaménko používají (kladné/záporné); celá čísla bez znaménka mohou být pouze kladná čísla nebo nula). Dále bylo uvažováno, zda umožnit pracovat s většími čísly, potenciálně až 4160bitovými (což odpovídá 520 bytům, tedy současné maximální velikosti prvku bitcoinového zásobníku).

    Tento týden vytvořil Chris Stewart nové vlákno s návrhem BIPu pro opkód původně navržený jako součást OP_TAPLEAF_UPDATE_VERIFY (viz zpravodaj č. 166, angl.). Tento opkód OP_INOUT_AMOUNT přidá do zásobníku hodnotu aktuálního vstupu (což je hodnota výstupu, který utrácí) a hodnotu výstupu, který má stejný index jako tento vstup. Například má-li v transakci první vstup hodnotu 4 milióny sat, druhý vstup 3 milióny sat, první výstup platí 2 milióny sat a druhý výstup 1 milión sat, potom by OP_INOUT_AMOUNT spuštěn během vykonávání druhého vstupu přidal do zásobníku 3_000_000 1_000_000. (Pokud chápeme návrh BIPu správně, bylo by to kódováno jako 64bitové celé číslo bez znaménka v little endian, tedy 0xc0c62d0000000000 0x40420f0000000000). Pokud by byl opkód do bitcoinu přidán, výrazně by kontraktům usnadnil ověřování očekávaného rozsahu částek vstupů a výstupů, např. že uživatel vybral z joinpoolu pouze částku, na kterou měl nárok.

  • ● Vylepšený proces opakovatelného sestavování ASMap: Fabian Jahr zaslal do fóra Delving Bitcoin příspěvek o vývoji ve vytváření mapy autonomních systémů (ASMap, „map of autonomous systems”), které kontrolují routování po rozsáhlých částech internetu. Bitcoin Core se v současnosti pokouší udržovat spojení do různorodých podsítí globálního jmenného prostoru. Aby mohl útočník provést i ten nejjednodušší druh útoku zastíněním („eclipse attack”), potřeboval by získat IP adresy ve všech podsítích. Avšak někteří poskytovatelé internetového připojení (ISP) a hostingové služby kontrolují IP adresy ve více podsítích, což tuto ochranu oslabuje. Projekt ASmap má za cíl poskytovat přímo v Bitcoin Core přibližné informace o tom, který ISP kontroluje které IP adresy (viz zpravodaje č. 52 a č. 83, angl.). Náročným úkolem je umožnit vícero přispěvatelům opakovatelně tuto mapu vytvořit, díky čemuž by bylo možné nezávisle ověřit přesnost obsahu mapy v době jejího vytvoření.

    Jahr tento týden ve svém příspěvku popisuje nástroje a techniky, které podle jeho slov „nabízejí dobrou šanci, že ve skupině s pěti nebo více členy dojde většina účastníků ke stejnému výsledku. […] Kdokoliv může tento proces zahájit, podobně jako Core PR. Účastníci se stejným výsledkem mohou být počítáni jako ACK. Pokud někdo spatří ve výsledcích něco divného nebo zkrátka nenalezne shodu, může požádat o sdílení surových dat a hledat příčiny.”

    Pokud by se tento proces setkal s přijetím (po případných úpravách), mohly by být budoucí verze Bitcoin Core dodávány s ASMapami a tato funkce by mohla být ve výchozím nastavení zapnuta. Díky tomu by se zvýšila odolnost vůči útokům zastíněním.

Změny ve službách a klientech

V této měsíční rubrice upozorňujeme na zajímavé aktualizace bitcoinových peněženek a služeb.

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.

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 #27877 přidává do peněženky Bitcoin Core novou strategii výběru mincí CoinGrinder (viz zpravodaj č. 283). Účelem této strategie je použití v případech, kdy je odhadovaný jednotkový poplatek v porovnání s dlouhodobou úrovní vysoký. To peněžence umožní vytvořit malé transakce nyní (důsledkem může být nutnost vytvořit větší transakce později, snad s nižším jednotkovým poplatkem).

  • ● BOLTs #851 přidává do specifikace LN podporu oboustranného financování („dual funding”) spolu s podporou protokolu pro interaktivní konstrukci transakcí. Interaktivní konstrukce umožňuje dvěma uzlům vyměnit si detaily o nastavení a UTXO a tím spolupracovat na vytvoření otevírající transakce. Oboustranné financování umožňuje transakci obsahovat vstupy kterékoliv nebo obou stran. Například Alice může chtít otevřít s Bobem kanál. Před touto změnou musela Alice poskytnout kompletní financování kanálu. Nyní může Alice otevřít s Bobem kanál, ve kterém poskytne kompletní financování on nebo se o financování podělí. Může to být použito spolu s protokolem inzerátů likvidity („liquidity advertisements”), který zatím do specifikace přidán nebyl.