Taproot byl sloučen do bitcoinového jádra v říjnu 2020, přičemž pro tento vysoce očekávaný upgrade protokolu byla ponechána pouze metoda aktivace zaměřená na přidání flexibility inteligentních smluv a většího transakčního soukromí bitcoinů.

Minulý týden se komunita pro vývoj bitcoinů shromáždila prostřednictvím Internet Relay Chat (IRC), aby diskutovala o parametrech aktivace Taproot a dvou požadavcích na vyžádání kódu (PR) signálního mechanismu BIP 8.

“Ve snaze dostat se blíže k cílové čáře pořádáme v úterý 2. února v 19:00 UTC setkání na IRC na kanálu ## taproot-activation,” organizátor vývoje bitcoinů Michael Folkson oznámeno prostřednictvím mailing listu bitcoin-dev. “Primárním cílem bude dokončení revidované metody aktivace BIP 8 …”

Toto setkání nakonec poskytlo více informací o tom, jak se nejvýznamnější změna protokolu Bitcoinu od doby, kdy se SegWit mohl posunout vpřed.

Poznámka redakce: Prohlášení reprodukovaná z IRC níže byla mírně upravena kvůli jasnosti, ale jinak jsou prezentována tak, jak byla napsána.

Dává tvar návrhu

Vývojář bitcoinů Anthony Towns sestavil návrhy a možné scénáře pro aktivaci Taproot. Na schůzce 2. února, ty, které se zdají mít největší podporu, jsou „BIP 8 (false, 1y)“ a „BIP 8 (true, 1y).“ Nebylo však hlasováno, proběhla pouze diskuse o každé alternativní aktivační metodě.

Ale co to znamená? BIP 8 je mechanismus, který umožňuje upgradovat konsenzus v bitcoinové síti pomocí soft forku, a konkrétně minerem aktivované soft forku nebo MASF s možností přidat po určité době uživatelsky aktivovanou soft fork (UASF). V poslední aktualizaci konsensu (SegWit) byla kromě MASF BIP 9 použita uživatelsky aktivovaná softwarová vidlice (UASF). Taproot se však pro horníky jeví jako nekontroverzní, takže se zdá méně pravděpodobné, že by tentokrát byl nutný UASF.

Vrátíme-li se k návrhu, parametry jsou „lockinontimeout“ a „timeout“, kde lockinontimeout v zásadě znamená, zda by aktivace byla vynucena či nikoli, a „timeout“ znamená okno, ve kterém by byla aktivována. Dalším relevantním parametrem, který nebyl dostatečně diskutován, byl „startheight“.

Pokud je lockinontimeout false a aktualizace nemá dostatečnou podporu, bude zrušena a bude definována nová nabídka. (Vývojář bitcoinů Luke Dashjr popsal lockintimeout = false jako poskytnutí horníků další sílu, kterou nikdy neměli mít),

„Pokud začnete s (timeout = T, lockinontimeout = false), při zasažení T existují tři možnosti: aktivace selže, zkuste to znovu s novou aktivací (timeout = T + 1rok, lockinontimeout = true, např.); předtím řeknete všem, aby přepnuli svůj software na (timeout = T, lockinontimeout = true), kdy jste upgradovali MASF na UASF, “napsal Towns na IRC. “Existuje také možnost přimět každého upgradovat na software, který specifikuje (časový limit = T-6 měsíců, lockinontimeout = true). V takovém případě lidé, kteří upgradovali, začnou odmítat bloky v měsících T-6, a pokud se aktivuje nejdelší řetězec do té doby bude mít starý i nový software soft-fork aktivován. “

Dashjr však nesouhlasí s lockinontimeout = false:

“… Jsme obecně spokojeni s uzamčením času = false?”, Bitcoin Developer Maxim Orlovský zeptal se.

“Ano,” Lightning Developer Rusty Russell odpověděl. “Máme UASF kladivo, pokud ho potřebujeme, ale je lepší ho nepoužívat.”

“Lot = true neznamená, že ji používáme, lot = false znamená, že záměrem je nechat horníky rozhodovat,” napsal Dashjr. “BIP8 (false) je regrese.”

Russell však argumentoval proti tomu, co považuje za uložení pro vývojáře: „Cítím, že je důležité vyhnout se tomu, aby se vývojář stal pověřením nad protokolem, a také mám rád únikový poklop, pokud by se před aktivací objevily problémy,“ napsal. “Proto dávám přednost začátku lockin = false a znovu se vrátím po 6 měsících, pokud se neaktivuje.”

“Neexistuje žádný mandát vývojáře … dává větší smysl dělat 1 rok, nepravdivý než 1 rok, pravdivý pro stejné období 1 rok [v případě dvou následujících nasazení],” odpověděl Dashjr.

Ale Russell se nezdál být pod vlivem:

“Nesouhlasím,” napsal. “Horníci získávají koordinační sílu, protože je můžeme spolehlivě měřit decentralizovaným způsobem, na rozdíl od jiných skupin.” To znamená schopnost * ne * koordinovat, ano. Ale máme také plán, protože díky BIP-8 je UASF mnohem méně pravděpodobné, že způsobí rozkol. To je tak dobré, jak to dokážeme. “

“Lot = true IS plánování za to,” napsal Dashjr v odpovědi, “to nezabrání těžařům dělat MASF.”

Jiní v chatu navrhli, aby lockinontimeout = false bylo volitelné, ale výchozí:

„Lot = false je bezpečnější než lot = true, takže stojí za to nejprve udělat lot = false, protože víme, že hashpower je ~ 90% již pro-taproot,“ napsal vývojář CoinSwap Chris Belcher.

Pokud uživatelé IIF mohou v určitém okamžiku snadno změnit lot = false na lot = true, aniž by vyžadovali nové vydání jádra, podporuji ponechání výchozího nastavení lot = false, “ Keagan McClelland napsal.

Kladivo UASF

Objasnit:

BIP8 w / LockinOnTimeout je záložní MASF w / UASF.

Dokud se horníci aktivují, nedojde k žádnému UASF.

Předem plánovaný UASF také zajišťuje, že k MASF dojde:

Zabraňuje tomu, aby horníci měli právo veta, a vytváří náležitou pobídku k zajištění toho, aby došlo k MASF.#Bitcoin #Taproot

– Luke Dashjr (@LukeDashjr) 2. února 2021

Dashjr chce použít „BIP 8 (true)“, záložní řešení UASF, jako zařízení teorie her, aby se ujistil, že horníci aktivují Taproot, a nedají jim žádnou možnost „veta“, stejně jako to, co se stalo se SegWitem.

“Vzhledem k požadavkům na signalizaci, Jakého typu pádového nebo smutného útoku by mohl těžařský fond dosáhnout, pokud si cení stání taprootu?” uživatel s názvem „rukavice“ se v IRC zeptal 2. února. „Např. zneužití mezní hashrate vyžadované pro aktivaci.“

Připomínáme, že signalizace je o snížení rizik vidlice a nemá nic společného s politickou podporou nebo hlasováním.

“MASF je upřednostňovaná cesta, s UASF jako záložní řešení, pokud horníci nedokáží signalizovat,” napsal Dashjr. “Komunita by mohla UASF přesunout dříve, pokud je jasné, že ji někdo pozastavuje.”

PR 1020 a 1021

Aby byl BIP 8 funkční, musel by být upraven. To znamená změny v signalizačním mechanismu a jedná se o kódové PR, jejichž cílem je to udělat:

  • 1020: Po fázi LOCKED_IN by bylo zbytečné signalizovat horníky, protože v této fázi už bude soft fork definitivně aktivován.
  • 1021: Povolit některým blokům MUST_SIGNAL nesignalizovat.

1020 obdrželo potvrzení na schůzi 2. února a 1021 byla původně považována za zbytečnou.

“Dobře, takže 1021 je relevantní pouze tehdy, když horníci NENÍ aktivováni vidličkou,” napsal Dashjr. “1021 je ve scénáři UASF POUZE … umožňuje až 5% bloků chybět požadovaný signál … IMO je to zbytečné a jen to zvyšuje složitost.”

Ale později ve výměně výzkumník Blockstream Nick Jonas poukázal na 1021 by mohlo být nutné.

“Re # 1021, pokud se rozhodnete spustit bip8 (true) s většinou uzlů stále spuštěných bip8 (false), opravdu byste nespustili kód, který neimplementuje # 1021, protože jinak byste mohli skončit ve špatném řetězci,” napsal Jonas.

“Nick má silnou stránku,” odpověděl Dashjr, později v IRC. “Bez 1021 byste mohli spustit LOT = true a nedodržovat řetězec aktivovaný Taprootem!”

Při další výměně relevantní pro tyto PR si Towns všiml, jak by tyto PR mohly být relevantní pro potenciál špatných aktérů.

„(1) Argumentem zde je, že během UASF vyžaduje signalizace riziko rozštěpení řetězce – pokud blok nesignalizuje, bude na tom stavět miner, který není UASF, ale každý ví, že oba bloky budou odmítnuty, takže to je příležitost pro útočníky zdvojnásobit útratu. přijetí co největšího počtu nesignalizačních bloků (tj. až 5%) omezuje útok, “napsal Towns. „(2) Druhou úvahou je, pokud začnete s delším časovým limitem (časový limit = 2 roky, lockinontimeout = true / false) a poté chcete urychlit aktivaci, protože všichni upgradují, trhy tvrdí, že to chtějí, a je tu 6% horníků, kteří se snaží přesvědčit každého, že bitcoiny naštve, a měli bychom přejít do jiného řetězce, pak můžeme nastavit (časový limit = 1 rok, lockinontimeout = true). “

“Ale tito horníci způsobí problém, jakmile stejně dosáhneme 5%, že?” Zeptal se Dashjr.

„„ Vytvořte problém, jakmile dosáhneme 5% “- ano,“ odpovědělo Towns, „pokud existuje >prahoví těžaři mohou vytvořit problém; pokud jsou tam jen 2% nebo tak, vyhneme se tak problému, pokud uděláme kratší časový limit s lockinontimeout = true, pak pokud narazíme na časový limit a dostaneme 98% bloků signalizujících, ale ne 100%, to zajistí, že všichni zůstanou v konsensu , ai když je to 98% řetězec, který pokračuje s nejdelší váhou, lidé, kteří provedli rychlý UASF ve stylu bip148, nemusí downgradovat svůj software. “

“Vzhledem k tomu, že 1021 je scénář UASF pouze to, že je třeba ho sloučit, dokud je nepravděpodobný okamžik, kdy je to potřeba?” Zeptal se Folkson.

“Ano, má to smysl pouze tehdy, pokud tento kód používají staré uzly,” odpověděl uživatel ghost43.

Nakonec byly obě PR sloučeny.

Celkem

BIP 8 (což je varianta BIP 9) se v současné době jeví jako nejzávažnější aktivační mechanismus. Sporuje se však o tom, zda by aktivace měla být pevná, i když představuje riziko UASF, které by těžařům upíralo právo veta; udělejte to bezpečně s pravděpodobností zpoždění aktivace v případě nedostatečné signalizace; nebo nastavte jako výchozí hodnotu false a v případě potřeby aktivujte true. Zastánci první možnosti si myslí, že těžaři by neměli mít možnost narušit komunitní proces, zatímco příznivci druhé možnosti si myslí, že záložní řešení UASF je zbytečné a ukazuje neodůvodněný požadavek, protože horníci prokázali přijetí Taprootu.

PR 1021 je bezpečnější obecná oprava chyby BIP 8, protože brání rozdělení řetězu v některých případech, kdy více než 95 procent, ale méně než 100 procent veškeré hash síly podporuje měkkou vidlici.

Příští schůzka aktivace Taproot (úterý 16. února v 19:00 UTC) je nastavena tak, aby byla zaměřena na kontrolu kódu, po níž bude následovat další schůzka k projednání parametrů. Jak diskuse pokračuje, bitcoin se přibližuje k jeho nejvýznamnějšímu upgradu protokolu za poslední roky.