Tento týden přinášíme poslední díl naší krátké týdenní série o pravidlech mempoolu. Též nechybí naše pravidelné rubriky popisující významné změny v klientech, službách a populárním bitcoinovém páteřním software.

Novinky

V emailových skupinách Bitcoin-Dev a Lightning-Dev se tento týden neobjevily žádné významné novinky.

Čekání na potvrzení 10: zapojte se

Poslední příspěvek do naší krátké týdenní série o přeposílání transakcí, začleňování do mempoolu a výběru transakcí k těžbě včetně vysvětlení, proč má Bitcoin Core přísnější pravidla, než co je povoleno konsenzem, a jak mohou peněženky využít pravidla co nejefektivněji.

Doufáme, že tato série poskytla čtenářům lepší porozumění, co se děje během čekání na potvrzení. Začali jsme zkoumáním, jak se ideologické hodnoty bitcoinu projevují v jeho struktuře a designu. Distribuovaná struktura peer-to-peer sítě nabízí oproti běžnému centralizovanému modelu zvýšené soukromí a odolnost vůči cenzuře. Otevřená síť propagace transakcí umožňuje každému dozvědět se o transakcích ještě před jejich potvrzením, což zlepšuje efektivitu propagace bloků, usnadňuje počátky novým těžařům a přináší veřejnou aukci blokového prostoru. Jelikož ideální síť sestává z mnoha nezávislých anonymních entit provozujících uzly, musí být software uzlů navržen tak, aby ochraňoval před DoS a minimalizoval provozní náklady.

Poplatky hrají v bitcoinu důležitou úlohu jako „spravedlivý” způsob řešení soutěže o blokový prostor. Mempooly s nahrazováním transakcí a algoritmy výběru a vyloučení využívají k měření užitku transakcí ekonomické incentivy a dávají uživatelům k dispozici nástroje k navyšování poplatků: RBF a CPFP. Kombinace pravidel mempoolu, peněženek se schopností ekonomické konstrukce transakcí a dobrý odhad poplatků vytváří efektivní trh blokového prostoru, který přináší užitek všem.

Jednotlivé uzly dále vynucují pravidla přeposílání transakcí, aby chránily samy sebe před vyčerpáním zdrojů a vyjadřovaly své osobní preference. Na úrovni celé sítě jsou aplikována pravidla standardnosti pro ochranu zdrojů nutných pro škálování, dostupnost uzlů a schopnost měnit pravidla konsenzu. Jelikož drtivá většina sítě tato pravidla vynucuje, jsou důležitou součástí rozhraní, nad nímž jsou bitcoinové aplikace a protokoly druhé vrstvy vystavěny. Avšak nejsou dokonalá. Popsali jsme několik návrhů kolem pravidel, které adresují obecná omezení i konkrétní případy jako jsou například pinning útoky transakcí na druhé vrstvě.

Též jsme zdůraznili, že probíhající evoluce pravidel sítě vyžaduje spolupráci mezi vývojáři pracujícími na protokolech, aplikacích i peněženkách. S růstem bitcoinového ekosystému, tedy s množstvím software, případů užití a uživatelů, roste důležitost i náročnost procesu decentralizovaného rozhodování. Tento systém vyvstává ze zájmů a cílů účastníků bitcoinové sítě. Není v jejím středu žádná firma sbírající názory zákazníků a najímající inženýry k přidávání nových funkcí. Kdo si přeje být součástí širšího konsenzu sítě, může si vybrat svou cestu: může se učit, ptát se, hlásit problémy, účastnit se návrhu sítě nebo přímo přispívat ve vývoji novinek.

Až budete příště příliš dlouho čekat na potvrzení své transakce, budete vědět, co dělat.

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.

• ● Peněženka od 10101 testuje sdílení prostředků mezi LN a DLC: 10101 oznámili peněženku postavenou nad LDK a BDK, která uživatelům umožňuje obchodovat deriváty nekustodiálním způsobem pomocí DLC v offchain kontraktu, který též může být použit k posílání, přijímání a přeposílání LN plateb. DLC závisí na orákulech, která vydávají atestace ceny použitím adaptor podpisů.

• ● Ohlášen LDK Node: Tým LDK ohlásil LDK Node v0.1.0. LDK Node je rustová knihovna lightningového uzlu, která používá knihovny LDK a BDK. Přináší vývojářům možnost rychle založit lightningový uzel a zároveň jim nechává vysoký stupeň nastavitelnosti.

• ● Ohlášeno Payjoin SDK: Payjoin Dev Kit (PDK) bylo ohlášeno jako rustová knihovna, která implementuje BIP78 pro použití v peněženkách a službách, které si přejí integrovat payjoin.

• ● Ohlášena beta verze Validating Lightning Signer (VLS): VLS umožňuje oddělit lightningový uzel od klíčů, které kontrolují jeho prostředky. Namísto používání lokálních klíčů přesměruje uzel běžící s VLS požadavky na podepsání vzdálenému podpisovému zařízení. Beta vydání podporuje CLN a LDK, validační pravidla vrstvy 1 i 2, možnost zálohy a obnovy a poskytuje referenční implementaci. Blogový příspěvek s oznámením dále prosí o testování, funkční požadavky a další zpětnou vazbu.

• ● BitGo přidává podporu MuSig2: BitGo oznámilo podporu BIP327 (MuSig2) a s ním i nižší poplatky a vyšší soukromí v porovnání s ostatními podporovanými druhy adres.

• ● Peach přidává podporu RBF: Mobilní aplikace Peach Bitcoin pro peer-to-peer směnu oznámila podporu pro navýšení poplatků pomocí Replace-By-Fee (RBF).

• ● Peněženka Phoenix přidává podporu splicingu: ACINQ oznámil beta testování následující verze své mobilní lightningové peněženky Phoenix. Peněženka podporuje jediný dynamický kanál, který se rebalancuje pomocí splicingu a mechanismu připomínajícího swap-in-potentiam.

• ● Mining Development Kit žádá o zpětnou vazbu: Tým pracující na Mining Development Kit (MDK) zveřejnil článek o průběhu vývoje hardware, software a firmware pro systémy pro těžbu bitcoinů. Příspěvek žádá komunitu o zpětnou vazbu a připomínky k případům použití, šíři záběru a jejich přístupu.

• ● Binance přidává podporu lightningu: Binance ohlásil podporu posílání (výběrů) a přijímání (vkladů) po lightning network.

• ● Nunchuk přidává podporu CPFP: Nunchuk ohlásil podporu pro navyšování poplatků pomocí Child-Pays-For-Parent (CPFP), a to na straně odesílatele i příjemce transakce.

Významné změny v kódu a dokumentaci

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 #27411 přestane oznamovat své Tor a I2P adresy spojením na jiných sítích (jako jsou IPv4 nebo IPv6) a též nebude oznamovat své adresy z neanonymních sítí spojením na Tor a I2P. Zabrání to možnosti párování běžných a anonymizovaných adres. CJDNS se tato změna zatím týkat nebude.

• ● Core Lightning #6347 přidává pluginům schopnost odebírat všechny události použitím *.

• ● Core Lightning #6035 přidává možnost vyžádat bech32m adresu pro příjem vkladů na P2TR výstupy. Drobné z transakce budou ve výchozím nastavení také poslány na P2TR výstup.

• ● LND #7768 implementuje BOLTy #1032 a #1063 (viz zpravodaj č. 225, angl.), které umožňují konečnému příjemci platby (HTLC) akceptovat vyšší částku a delší expirační dobu, než které byly požadované. Dříve se příjemci založení na LND drželi požadavku z BOLT4, že částka a expirační doba se musí přesně rovnat. Tato přesnost však dávala možnost drobnými změnami těchto hodnot odhalit, zda byl následující skok konečným příjemcem.

• ● Libsecp256k1 #1313 přináší automatické testování vývojovými verzemi kompilátorů GCC a Clang. Testování může odhalit změny způsobující běh některého kódu libsecp256k1 v proměnlivém čase, který může vést k útokům postranními kanály. Zpravodaj č. 246 poukazuje na jednu příležitost, kde se tak mohlo stát, a zpravodaj č. 251 odkazuje na jinou a na oznámení o plánech na podobné testování.