Zpravodaj tento týden shrnuje pokračující diskuzi o odměňování těžařů v poolu obchodovatelnými ecashovými share a popisuje nový návrh umožňující offchain urovnání DLC. Též nechybí naše pravidelné rubriky s oznámeními nových vydání a popisem významných změn v populárním bitcoinovém páteřním software.

Novinky

  • Pokračující diskuze o používání ecash k vyplácení odměn za těžbu v poolu: diskuze o používání ecash k vyplácení odměn za každý share zaslaný těžaři v poolu od našeho předchozího souhrnu vlákna ve fóru Delving Bitcoin dále pokračuje. Matt Corallo se již dříve tázal, proč by pool přidával další kód a účetnictví pro zpracování obchodovatelných ecashových share, když mohou jednoduše platit těžařům pomocí normálního ecash či LN. David Caseria odpověděl, že v některých PPLNS schématech (pay per last N shares, platba za posledních N share) jako TIDES může těžař čekat, až pool nalezne několik bloků, což může v případě menších poolů trvat dny či týdny. Namísto čekání by mohl těžař svá ecashová share okamžitě prodat na trhu (aniž by poolu nebo třetí straně odhalil či naznačil svou identitu).

    Caseria dále poznamenal, že pro existující těžební pooly je finančně náročné podporovat schéma plné výplaty za share (full pay per share, FPPS), ve kterém těžař za vytvořený share obdrží odměnu poměrnou k odměně za celý blok (včetně poplatků z transakcí). Svou myšlenku již dále nerozvinul, ale dle našeho chápání je problémem proměnlivost poplatků, která pooly nutí držet velké rezervy. Na příklad pokud těžař do poolu přispívá 1 % hashrate a vytvoří share nad šablonou s 1 000 BTC za poplatky a 3BTC odměnou, měl by od svého poolu obdržet kolem 10 BTC. Avšak pokud pool tento blok nevytěží a vytěží jiný s poplatky, které tvoří jen zlomek hodnoty odměny za jeho nalezení, má pool k rozdělení mezi všechny své těžaře pouze 3 BTC. Bude tak muset platit ze svých rezerv. Pokud se to děje příliš často, jeho rezervy se vyčerpají a pool skončí. Pooly tento problém řeší několika způsoby včetně používání různých zástupných metrik za skutečné poplatky.

    Vývojář vnprc popsal své řešení, které se zaměřuje na ecashové share obdržená v PPLNS schématu. Domnívá se, že by mohlo být obzvláště užitečné pro spouštění nových poolů: první těžař, který se k poolu připojí, trpí stejnou vysokou variabilitou jako sólo těžař, proto obvykle pool založí jen existující velcí těžaři nebo ti, kteří jsou ochotni pronajmout si významný hashrate. Vnprc se však domnívá, že s PPLNS ecashovými share by mohl být pool spuštěn jako klient většího poolu a i první těžař, který se připojí, by měl nižší variabilitu než při těžbě sólo. Tento prostředník by potom mohl vydělané ecashové share prodat a financovat tím kterékoliv schéma výplat těžařům, které si zvolí. Po získání významnějšího množství hashrate by měl i tento pool-prostředník dostatečnou sílu na vyjednávání s většími pooly o alternativních šablonách bloků, které by byly pro jeho těžaře vhodnější.

  • Offchain DLC: vývojář conduition zaslal do emailové skupiny DLC-dev příspěvek s popisem protokolu, který umožňuje vytvářet množství DLC offchain útratou financující transakce podepsané oběma stranami. Po urovnání offchain DLC (např. po získání všech potřebných podpisů orákulí) mohou obě strany podepsat další offchain platbu a přeposlat prostředky dle kontraktu. Třetí alternativní útrata může nato prostředky poslat do nových DLC.

    Kulpreet Singh a Philipp Hoenisch ve svých odpovědích odkázali na předchozí výzkum a vývoj této základní myšlenky, včetně možnosti použít jeden sdílený fond v offchain DLC i v LN (viz zpravodaje č. 174, angl., a č. 260). Conduition ve své odpovědi popsal rozdíly od předchozích návrhů.

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 v0.1 je milníkem této knihovny pro budování peněženek a aplikací s podporou LN. Mezi novinky patří „podpora pro obě strany protokolu pro vyjednávání otevření LSPS kanálu, […] podpora překladu čitelných jmen (Human Readable Names) dle BIP353 [a snížení] nákladů na onchain poplatky během vyrovnání několika HTLC při vynuceném zavření kanálu.”

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.

  • Eclair #2936 přidává 12blokovou prodlevu, než označí kanál za zavřený po utracení otevíracího výstupu za účelem propagace splicu (viz zpravodaj č. 214, angl., a objasnění motivace od vývojáře Eclair). Utracené kanály budou dočasně sledovány v nově přidané mapě spentChannels, ze které jsou po 12 blocích buď odstraněny nebo označeny za účastníky splicingu. Po splicu jsou aktualizovány krátký identifikátor (SCID) rodičovského kanálu, jeho kapacita a zůstatky; nový kanál se nevytváří.

  • Rust Bitcoin #3792 přidává schopnost kódovat a dekódovat zprávy v2 P2P transportního protokolu dle BIP324 (viz též zpravodaj č. 306). Přidána byla nová struktura V2NetworkMessage, která obaluje původní výčtový seznam NetworkMessage a poskytuje v2 kódování a dekódování.

  • BDK #1789 mění výchozí verzi transakce z 1 na 2. Záměrem je zvýšení soukromí, neboť před touto změnou byly BDK peněženky snadněji identifikovatelné (verzi 1 používá jen 15 % sítě). Verze 2 bude dále vyžadována v implementacích BIP326, které taprootovým transakcím přinesou obranu proti fee snipingu založenou na nSequence.

  • BIPs #1687 začleňuje BIP375 specifikující používání tichých plateb s PSBT. V případě více nezávislých podepisujících stran je vyžadován DLEQ doklad, který ostatním bez nutnosti odhalit jakékoliv soukromé klíče potvrdí, že jejich podpis nepovede ke zneužití prostředků (viz též zpravodaj č. 335 a podcast č. 327, angl.).

  • BIPs #1396 odstraňuje z payjoinové specifikace v BIP78 rozpor s PSBT specifikací v BIP174. V BIP78 dříve příjemce po zkompletování vstupů odstranil data o UTXO, i když je odesílatel potřeboval. Nově budou údaje o UTXO zachovány.

Chcete víc?

Další diskuze o tématech zmíněných v tomto zpravodaji proběhnou v týdenním Bitcoin Optech Recap na Riverside.fm dne 21. 1. v 15:30 UTC. Diskuze jsou nahrávány a zpřístupněny na stránce našeho podcastu.