Soft Fork

Představte si Annu a Pavla, kteří si každý na vlastním počítači ověřují Bitcoin. Anna aktualizovala software, Pavel zatím ne. Přichází změna podobná BIP66: digitální podpis, kterým se prokazuje oprávnění utratit určité bitcoiny, musí být zapsán přesněji stanoveným způsobem. Některé dříve přijímané zápisy přestanou být přípustné. Platba se správným podpisem v nově požadovaném formátu projde touto kontrolou u obou. Když ale podpis použije dříve povolený, nyní zakázaný zápis, Anna jej odmítne a Pavel jej ještě může přijmout. Předpokládáme přitom, že platba splňuje ostatní pravidla. Právě tento rozdíl vysvětluje Soft Fork: nová pravidla něco navíc zakazují, aniž by dovolila to, co stará zakazovala. Pokud těžaři vytvářejí bloky vyhovující zpřísněným pravidlům, mohou je oba dál sledovat. Pavel však novou podmínku sám nehlídá. Soft Fork proto umožňuje změnit Bitcoin bez nutnosti současné aktualizace všech uzlů, ale neznamená, že starý software poskytuje stejnou kontrolu jako nový. Sám o sobě také nevytváří druhou měnu. [1] [6]

Full Node je počítač, který samostatně kontroluje bitcoinová pravidla. Při výběru mezi platnými větvemi porovnává souhrnnou práci prokázanou těžbou, nikoli počet hlasů jejich příznivců. Starý full node může dál sledovat řetězec, protože aktualizovaní těžaři běžně vytvářejí bloky, které uznává. Přidanou podmínku ale nekontroluje. Kdyby větev s větší prací nové pravidlo porušila, starý uzel ji může přijmout, zatímco aktualizovaný ji odmítne. Kdo potřebuje novou záruku, musí aktualizovat vlastní ověřovací software. To, že peněženka umí přijmout platbu nebo rozpozná nový formát adresy, ještě neznamená, že sama zkontroluje všechna pravidla sítě. [1] [12]

BIP je očíslovaný technický návrh. Jeho zveřejněním se síť ještě nezmění: někdo musí připravit a ověřit software a jeho uživatelé rozhodnout, zda jej budou používat. Mainnet je hlavní bitcoinová síť, na které se převádějí skutečné bitcoiny. Aktivace určuje, od kdy v ní aktualizované uzly začnou nové pravidlo vyžadovat. Proto se liší přítomnost kódu v programu od jeho používání při kontrole bloků. U popsaných aktivačních postupů znamená lock-in, že byl splněn předpoklad pro pozdější aktivaci; samotné pravidlo se ještě nemusí uplatňovat. Teprve ve stavu ACTIVE jej uzel kontroluje. Stav odvozuje z předchozích bloků vlastní větve. Pokud reorganizace změní tuto historii poblíž aktivační hranice, může se změnit i vypočtený stav. Dva programy s odlišnými aktivačními parametry proto nemusí ve stejnou chvíli přijímat stejné bloky. [2] [15]

Těžař navazuje svůj blok na předchozí, někdy označovaný jako rodičovský. Neověří-li jej, může zbytečně pracovat na větvi, kterou ostatní odmítnou. Při aktivaci BIP66 v červenci 2015 někteří těžaři signalizovali novou verzi, ale dostatečně neověřovali rodičovský blok, na němž těžili. Prodloužili neplatný blok a 4. července vytvořili šestiblokovou neplatnou větev; další kratší incident následoval druhý den. Aktualizované validující uzly obě větve odmítly. Číslo verze nebo bit je tvrzení těžaře, nikoli důkaz, že sám ověřil připravený blok, jeho předchůdce a obsažené transakce. [6] [14]

Chcete-li vědět, která pravidla váš uzel skutečně používá, začněte jeho verzí a údaji, které vrací on sám. Příkazy getdeploymentinfo a getblockchaininfo poskytují podle verze programu informace o nasazených změnách a o řetězci. Spolu s dokumentací daného vydání, aktivační výškou a záznamy v logu pomáhají rozlišit připravené pravidlo od již aktivního. Webový průzkumník bloků ukazuje pohled jiné služby; není dokladem toho, co ověřuje váš počítač. Hashrate vyjadřuje výpočetní výkon těžby. Nedává však těžařům oprávnění obejít pravidla vašeho uzlu: ve stavu ACTIVE aktualizovaný uzel odmítne blok, který novou podmínku porušuje, i kdyby za ním stála většina výkonu. Zda se rozdělení řetězce udrží, závisí také na práci jednotlivých větví a na tom, které z nich lidé ekonomicky používají. Prosté odstranění aktivního omezení by znovu povolilo dosud neplatné bloky, a šlo by proto o Hard Fork. Před aktivací lze parametry změnit novým koordinovaným vydáním softwaru; ani taková změna se ale do cizích uzlů nepřenese sama. [1] [15] [16]

Označme V(stará) všechny bloky přijímané pravidly před upgradem. Změna je Soft Fork jen tehdy, když V(nová) leží uvnitř V(stará): nový uzel odmítne další třídu bloků, ale blok vyhovující novým pravidlům projde i starými kontrolami. Název vypovídá o kompatibilitě pravidel platnosti, nikoli o velikosti, bezpečnosti či společenské shodě změny. Zvýšení limitu viditelného starým uzlem nebo povolení dříve neplatného utracení množinu rozšiřuje a obvykle vyžaduje Hard Fork. [1] [17]

Zpřísnění může přinést i novou funkci. BIP66 upřesnil DER, tedy způsob zápisu dat podpisu. BIP65 a BIP112 daly vybraným příkazům NOP, které dříve nic nevynucovaly, nové časové podmínky utracení. SegWit zavedl witness programy a ověřovací data zvaná witness, například podpisy. Taproot později využil jejich rezervovanou verzi 1. Starší uzly příslušné nové podmínky neověřují; výraz anyone-can-spend popisuje tento omezený pohled, nikoli možnost obejít aktualizované uzly a utratit cizí peníze. SegWit navíc kryptograficky váže witness data ke bloku pomocí witness commitment. Tato vazba je uložena v coinbase transakci, první transakci bloku s odměnou těžaři, a zachovává kompatibilitu se starými pravidly základního bloku. [6] [5] [7] [8] [12]

Bit je údaj s hodnotou 0 nebo 1. V poli nVersion, které v hlavičce bloku zaznamenává jeho verzi, mohou jednotlivé bity sloužit jako signály připravenosti těžaře. BIP9 každému nasazení přiřazuje název, konkrétní bit, čas začátku a konečný časový limit. Původní mainnetová varianta vyhodnocuje období po 2 016 blocích. Pokud se ve stavu STARTED objeví nejméně 1 916 signalizujících bloků, tedy 95 %, další období přejde do LOCKED_IN. Následuje ještě jedno období čekání a potom stav ACTIVE. Jestliže se podmínku nepodaří splnit před časovým limitem, může postup skončit ve FAILED. Stav před zahájením se nazývá DEFINED. Tento sled stavů počítá každý uzel z předchozích bloků. O tom, zda pro určitý blok platí nové pravidlo, proto nerozhoduje jeho vlastní nVersion. Signalizace pomáhá načasovat přechod, není hlasováním o platnosti jednotlivých bloků. Jakmile bylo dosaženo lock-in, pozdější signály už výsledek tohoto postupu nemění. [2]

Versionbits umožňují těžařům signalizovat připravenost, nedávají jim však právo přepisovat pravidla ostatních uzlů. BIP8 používá výšky bloků místo časových hranic. Je-li lockinontimeout nastaveno na true a návrh ještě nedosáhl lock-in, poslední období může přejít do MUST_SIGNAL s povinnou signalizací. BIP148 vyžadoval od zúčastněných uzlů odmítání bloků, které nesignalizovaly SegWit; BIP91 použil nižší práh těžařské signalizace pro koordinaci tohoto přechodu. Pokud se vynucování pravidel, hashrate a ekonomické přijetí rozejdou, může vzniknout rozdělení řetězce. Volba aktivace proto zahrnuje bezpečnostní kompromisy. [11] [9] [10] [17]

P2SH (BIP16) umožňuje poslat prostředky na otisk skriptu, tedy programu s podmínkami jejich pozdějšího utracení. Při jeho zavedení v roce 2012 pomáhala signalizace v coinbase transakcích zjistit připravenost těžařů. Samotné nové kontroly se však začaly uplatňovat od stanovené časové hranice bloků; signalizace nebyla náhradou ověření. Coinbase je první transakce bloku s odměnou těžaři. Další změny používaly verzi bloku a signalizační prahy. BIP34 tak zavedl povinné zapsání výšky bloku, jeho pořadového čísla v řetězci, do coinbase. BIP66 zpřísnil formát podpisů DER a BIP65 přidal CHECKLOCKTIMEVERIFY, kontrolu nejdřívějšího času či výšky pro utracení. Postupné zvyšování čísla verze ztěžovalo souběžné zavádění nezávislých změn. BIP9 proto přinesl samostatné bity. V roce 2016 se ve výšce 419 328 společně aktivovaly BIP68, BIP112 a BIP113, každý ale řeší jinou část časových podmínek. BIP68 zavádí relativní čekání od potvrzení utráceného výstupu. BIP112 umožňuje toto čekání vyžadovat ve skriptu pomocí CHECKSEQUENCEVERIFY, zkráceně CSV. BIP113 naproti tomu mění čas používaný pro absolutní časový zámek transakce: místo času právě posuzovaného bloku používá Median Time Past, medián časů předchozích 11 bloků. Společná aktivace tedy neznamená, že všechny tři návrhy zavádějí stejný relativní zámek. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit se aktivoval ve výšce 481 824 v srpnu 2017. Oddělil ověřovací data witness, například podpisy, od části transakce používané k výpočtu jejího identifikátoru txid. Proč na tom záleží? U staršího zápisu mohl někdo změnit podobu podpisu, a tím i identifikátor transakce, aniž by změnil, komu a kolik se platí. Této možnosti se říká malleabilita. Změna samotných witness dat txid nemění; SegWit však tímto způsobem neopravuje vstupy, které nadále používají starší formát. Starý uzel vidí transakci bez witness dat a program witness v0 považuje za anyone-can-spend. Aktualizovaný uzel navíc ověřuje witness a podpisový digest, tedy otisk podepisovaných dat. Witness commitment uložený ve výstupu coinbase kryptograficky váže witness data ke bloku, takže jejich změnu či vynechání lze při úplné kontrole odhalit. Weight, tedy váha dat při započítávání do kapacity bloku, umožnil zvýšit efektivní kapacitu. Základní blok, který vidí starý uzel, přitom zůstal v původním limitu jednoho megabajtu. [8]

Key-path umožňuje utracení podpisem odpovídajícím výstupnímu klíči, script-path splněním podmínek odhaleného skriptu. Schnorr je typ podpisu a Tapscript jazyk těchto skriptů. BIP341 a BIP342 definují pro nativní SegWit výstupy s 32bajtovým witness programem verze 1 utrácení cestou key-path a script-path se Schnorrovými podpisy a Tapscriptem. Starý uzel rezervovaný program opět považuje za anyone-can-spend: podmnožina zůstává zachována, úplná validace nikoli. Mainnet použil upravený BIP9 Speedy Trial s prahem 1 815 z 2 016 bloků, tedy 90 %, a minimální aktivační výškou 709 632. Taproot se v ní aktivoval 14. listopadu 2021; pravidla Taprootu a způsob jejich aktivace jsou dvě samostatné otázky k auditu. [12] [13] [16]