Soft fork je koordinovaný přechod z množiny platnosti V(stará) na její podmnožinu V(nová). Aktivace určí blok, od něhož aktualizované full nody omezení vynucují. Signalizace těžařů může koordinovat připravenost, o platnosti však rozhoduje pravidlo spuštěné v uzlech; návrh, implementace, nasazení, aktivace a přijetí nejsou totéž.
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. [Bitcoin Developer Guide — Consensus rule changes] [Bitcoin Optech — Soft fork activation]
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í validační software; schopnost peněženky přijmout platbu, kompatibilita formátu a úplná konsenzuální validace jsou odlišné věci. [Bitcoin Developer Guide — Consensus rule changes] [BIP 341 — Taproot deployment]
Bitcoin vytvářel podmnožiny několika technikami. BIP66 zakázal podpisy bez striktního DER, které stará pravidla přijímala. BIP65 a BIP112 přidaly podmínky opkódům NOP, jež starý interpret považoval za úspěšné nicnedělání. SegWit a Taproot daly význam rezervovaným verzím witness programu, které starý uzel vidí jako anyone-can-spend. Konstrukce zároveň musí zabránit obejití nové kontroly; SegWit proto zavázal witness data přes coinbase a zachoval stará pravidla základního bloku. [BIP 66 — Strict DER signatures] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Segregated Witness] [BIP 341 — Taproot deployment]
Kód může obsahovat neaktivní pravidlo dlouho předtím, než začne platit na mainnetu. BIP a zkontrolovaná implementace nejsou nasazení, parametry nasazení nejsou lock-in, lock-in pouze naplánuje budoucí vynucení a teprve stav ACTIVE znamená kontrolu daného bloku. Každý uzel stav vypočítává z předků své vlastní větve. Reorganizace u hranice jej může přepočítat a software s jinými parametry může začít vynucovat neslučitelná pravidla. [BIP 9 — Version bits with timeout and delay] [Bitcoin Core — versionbits.cpp]
BIP9 přiřazuje nasazení název, bit verze, čas začátku a timeout. Původní mainnetová varianta vyhodnocuje periody po 2 016 blocích: po nejméně 1 916 signalizujících blocích, tedy 95 %, přejde ze STARTED do LOCKED_IN, jednu periodu čeká a potom je ACTIVE; jinak může skončit FAILED. Úplný sled je DEFINED, STARTED, LOCKED_IN, ACTIVE a FAILED. Stav bloku závisí na předcích, ne na jeho vlastním nVersion, a signalizace po lock-in už výsledek nemění. [BIP 9 — Version bits with timeout and delay]
Versionbits ukazují připravenost těžaře a koordinují přechod; nepřidělují těžařům trvalé vlastnictví konsenzu. BIP8 používá výšky a s lockinontimeout může v posledním okně vynutit signalizaci. BIP148 naopak přikazoval zúčastněným uzlům odmítat bloky nesignalizující SegWit; BIP91 snížil těžební práh, aby se s tímto tlakem koordinoval. Povinná aktivace může rozdělit řetězec, pokud se rozejdou uzly, hash rate a ekonomické přijetí, takže i aktivační metoda je bezpečnostní kompromis. [BIP 8 — Version bits with lock-in by height] [BIP 148 — Mandatory activation of SegWit] [BIP 91 — Reduced threshold SegWit MASF] [Bitcoin Optech — Soft fork activation]
P2SH podle BIP16 se v roce 2012 aktivoval signalizací v coinbase a časovou hranicí. BIP34 použil verzi bloku a práh pro povinnou výšku v coinbase. Stejný celočíselný postup spustil striktní DER v BIP66 a CHECKLOCKTIMEVERIFY v BIP65, ale spotřebovával hodnoty verze a neuměl souběžná nasazení. BIP9 proto zavedl nezávislé bity. BIP68, BIP112 a BIP113 se pak aktivovaly společně jako relativní locktime a CSV ve výšce 419 328 v roce 2016. [BIP 16 — Pay to Script Hash] [BIP 34 — Block v2, height in coinbase] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Strict DER signatures] [BIP 112 — CHECKSEQUENCEVERIFY]
SegWit se aktivoval ve výšce 481 824 v srpnu 2017. Starý uzel vidí transakci bez witness dat a program witness v0 považuje za anyone-can-spend; aktualizovaný ověří witness, nový podpisový digest a pravidla proti malleabilitě. Merkleův závazek witness dat ve výstupu coinbase brání těžaři data bez odhalení změnit či vynechat. Účtování pomocí weight zvýšilo efektivní kapacitu, aniž by základní blok viditelný starým uzlem překročil starý limit jednoho megabajtu. [BIP 141 — Segregated Witness]
BIP341 a BIP342 dávají witness programu verze 1 key-path a script-path utrácení 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. [BIP 341 — Taproot deployment] [BIP 342 — Tapscript] [Bitcoin Core 0.21.1 release notes — Taproot deployment]
Při aktivaci BIP66 v červenci 2015 někteří těžaři signalizovali novou verzi, ale dostatečně nevalidovali 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 šablonu, rodiče a transakce. [BIP 66 — Strict DER signatures] [Bitcoin.org — July 2015 BIP66 chain fork alert]
Ve stavu ACTIVE aktualizované uzly odmítají porušující blok bez ohledu na podíl hash rate; zda vznikne trvalé rozdělení, závisí na práci větví a jejich ekonomickém používání. Prosté odstranění omezení by znovu povolilo dnes neplatné bloky, a je proto hard forkem; před aktivací lze parametry či kód nahradit koordinovaným vydáním. Provozovatel ověří vlastní verzi, getdeploymentinfo či getblockchaininfo, přesné parametry, aktivační výšku a logy. Graf signalizace ani štítek exploreru místní validaci nenahradí. [Bitcoin Developer Guide — Consensus rule changes] [Bitcoin Core — versionbits.cpp] [Bitcoin Core 0.21.1 release notes — Taproot deployment]
Pro nejúplnější obraz čtěte toto heslo společně s Konsensuální pravidla, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. Opačným směrem na něj odkazují také Hard Fork, BIP (Bitcoin Improvement Proposal), Konsensuální pravidla, Válka o velikost bloků.