Segregated Witness: Co je SegWit a jak funguje

[twitter-follow username="btctip_cz" scheme="dark"].

Segregated Witness - aneb když jde podpis stranou

Segregated witness (SegWit) - o co se jedná? Jde o velice progresivní vlastnost implementovanou od verze bitcoin core 0.13.0, která se snaží řešit nejpalčivější problém současné verze a to jsou:

• vyřešení neúmyslné transaction malleability (doslova poddajnost/pozměnitelnost ID transakce) segregací podpisu do samostatné části, která je ignorována při počítání unikátního ID transakce.
• škálovatelnost a snížení kvadratické složitosti ověřování a podepisování transakcí na lineární
• zvětšení velikosti bloku o cca 70 % pomocí změny algoritmu, který stanovuje limit velikosti bloku
• zahrnutí částky, kterou se každá transakce pokouší utratit, do kryptografického otisku této transakce

SegWit je tedy přítomen v kódu bitcoin core, ale není aktivní - viz dále.

K čemu je SegWit dobrý a co může přinést?

HW peněženky

SegWit nebo jeho obdoba usnadní život všem bitcoinovým peněženkám, zejména těm hardwarovým. V novém serializačním formátu transakce je zahrnutá i částka každého vstupu. Do HW peněženky již není nutné posílat i všechny navázané transakce, jejichž výstupy se snažíme utratit. Implementace peněženek postavených na NFC rozhraní je z bezpečnostního hlediska téměř nemožná bez SegWitu právě z těchto důvodů. Se SegWitem peněženka nepotřebuje všechny navázané transakce a může “slepě” důvěřovat částce, kterou jí nadiktuje NFC terminál, se kterým komunikuje. Pokud by jí lhal o částce, podepsaná transakce bude po zaslání do bitcoinové sítě vyhodnocena jako neplatná, protože selže ověření (správná částka na vstupech povede na jiný otisk - txid).

Oprava "Transaction Malleability"

Nejprve je třeba vysvětlit v čem spočívá tzv. transaction malleability. Jde o chybu v návrhu bitcoinu (nebo spíše trochu nešťastné Satoshiho rozhodnutí), kde je součástí dat transakce, ze kterých se počítá otisk (txid) i samotný podepisovací skript (scriptSig). V tomto skriptu je možné udělat změny, které způsobí, že výsledný otisk transakce je jiný a zároveň nový podpis zůstává stále platným. Segwit přesouvá podpis až za vlastní transakci a původní pole scriptSig (v případě utracení výstupu typu P2WPKH - viz dále) zůstává prázdné. V následném počítání otisku transakce tedy nefiguruje podpis vůbec a tím je problém pozměnitelnosti txid vyřešen. Pro úplnost je třeba uvést, že Segwit zavádí jestě tzv. wtxid, které samotný podpis (witness) zahrnuje. Problémem malleability kódování podpisu, který v případě wtxid existuje, se zabývá BIP146. Nutno podotknout, že wtxid není používáno pro řetězení transakci.  

Boj o velikost bloku - Bitcoin Core a ti druzí

Diskuze na téma velikosti bloku začala někdy kolem roku 2014. Bitcoin foundation (v čele s Gavinem Andresenem) prezentovala tzv. Scalability roadmap. Výsledkem vzrušené debaty v průběhu času byl vznik celkem 3 implementací, které se pokusily tento problém řešit.

• Kam kráčíš Gavine?

Velmi svéráznou cestou se vydal projekt Bitcoin Unlimited, který se za podpory od Rogera Vera snaží protlačit návrh, aby bylo omezení velikosti bloku zcela odstraněno z vrstvy bitcoinového protokolu a přesunuto do transportní vrstvy. Tím by si samotní těžaři mohli stanovovat svoji velikost bloku podle aktuální situace na trhu transakcí. Nebezpečí, která z toho přístupu plynou, jsou evidentní - finanční ztráty vzniklé z nalezených bloků, které momentálně nebudou akceptovány sítí apod. Pověst projektu nedávno utrpěla chybou v kódu, která způsobila ztrátu vytěženého bloku, jehož velikost byla nad aktuální limit. Nechuť k převzetí implementace SegWitu do projektu Unlimited je vysvětlována jako principiální nesouhlas se způsobem nasazení. Unlimited chce jít cestou hardforku - tedy nekompatibilní změny na úrovni bitcoinového protokolu v případě velikosti bloku. Nasazení SegWitu pomocí softforku je považováno za komplikované a riskantní. Názory CEO ViaBTC tuto teorii jenom potvrzují.

• BitcoinXT

Za projektem BitcoinXT stojí bývalý vývojář bitcoin core Mike Hearn. Tento projekt již není dále udržován, Mike se věnuje jiným činnostem spojeným s momentálním “hypem” kolem blockchain technologií. Poslední verze ze srpna 2016 přinesla xThin bloky, kompatibilní se stávající implementací v Bitcoin Unlimited. XT prosazoval také zvětšení bloku formou hardforku, kompatibilní s Bitcoin Classic. Prvotní velikost bloku byla stanovena na 2 MB.  

Nové typy výstupů transakcí

Segwitem se na různých úrovních zabývají postupně BIPy 141-145. Na úrovni konsenzu je popsán v BIP 141, kde jsou popsány nejdůležitější mechanismy fungování. Za zmínku stojí zejména nové typy transakcí:

• Version 0 pay-to-witness-public-key-hash (P2WPKH)
• Version 0 pay-to-witness-script-hash (P2WSH)

Pro obě varianty zatím není schválen standardní formát adresy. O to se pokouší BIP142, který prozatím nebyl schválen. Peněženka, která by chtěla zaslat Bitcoiny pomocí P2WPKH či P2WSH by musela o výstupní skript požádat protistranu např. pomocí payment protokolu. BIP141 dále ukazuje kompatibilní možnost použití, a sice zabalit P2WPKH nebo P2WSH do redeem skriptu a použít pay-to-script-hash (P2SH).

Změna velikosti bloku

Aktuální limit na velikost bloku (~1 MB) bude se Segwitem zvýšen následovně: - je zaveden nový limit - tzv. block weight, nastavený na 4000000 - velikost všech data bloku mimo všeho, co bylo přidáno pro segwit má nyní nově váhu 4 * velikost-v-bytech - tedy každý byte má váhu 4 - všechna data relevantní pro segwit mají naopak váhu 1 Co z toho plyne? Pokud transakce nebudou používat SegWit, velikost bloku se nezmění. Čím více transakcí bude používat SegWit - tím větší budou mít slevu na místo v bloku a efektivní velikost bloku se zvětší. Vzhledem k tomu, že do Segwit části se přesouvají podpisy, očekává se nárůst velikosti bloku kolem 70 - 75 %. Změnu velikosti transakce v novém schématu lze vyzkoušet na testovací Segwitové síti - segnetu.

Verzování skriptů a pan Schnorr

Tato vlastnost zní jako drobnost. Její dopad je ale zásadní. Vzhledem k tomu, že se mění forma platebních skriptů (scriptPubKey), je velice výhodné zavést verzování, které umožní do budoucna dělat zpětně nekompatibilní změny v platebních skriptech. Současný stav je takový, že se běžně využívalo některých OP_NOP instrukcí (prázdných instrukcí) a přidal se jim význam (viz např. BIP65 a BIP112). Současný přístup k rozšiřování platebních skriptů nebyl příliš čistý. Verzování skriptů nám do budoucna umožní změnit např. podepisovací algoritmus, přidávat nové typy skriptů apod. O čem se aktuálně mluví a co se zkoumá, jsou tzv. Schnorr podpisy. Schnorr implementace je již k dispozici v libsecp256k1. Schnorr může přinést další úsporu místa v blocích pomocí agregace podpisů. Dále nativně podporuje multisig způsobem, že např. 100-ze-100 multisig je stejně velký jako 1-z-1.

Mikroplatby, sidechains, chytré kontrakty

Adam Back se svou firmou Blockstream pracují již delší dobu na projektu Lightning Network. Tato síť využívá propojení s bitcoinovým blockchainem, k zajištění obousměrných platebních kanálů, nejedná se ale o sidechain. K rozumné implementaci potřebuje, aby se stávající protokol zbavil malleability. Pokud se podaří Segwit aktivovat, Lightning Network se svými mikroplatebními kanály se stane skutečností. Jak to funguje? LN umožňuje vytvořit obousměrný platební kanál s využitím bitcoinových transakcí, které zúčastněné strany podepíší, ale neposílají do bitcoinové sítě. Postupně dochází k aktualizaci těchto transakcí podle toho jak jedna strana utrácí. Platná je vždy poslední verze transakce. Finální podoba transakce uzavírá celou session a je zaslána do bitcoinové sítě. Blockchain tak slouží jako arbitr, který vynutí spravedlivé vypořádání transakce. K tomu, aby bylo možné provozovat takový systém, musíme zaručit nezměnitelnost identifikátorů transakcí (txid). Možná, že se tedy dočkáme doby, kdy za kávu v Paralelní Polis nebudeme platit přímo bitcoinem. Ale při návštěvě si otevřeme mikroplatební kanál svojí oblíbenou peněženkou a při odchodu účet uzavřeme. Pokud zapomeneme zaplatit, nebo se pokusíme utéct bez placení, blockchain vše vypořádá za nás.

Kompatibilita

Segwit je nasazován jako softfork, s návrhem jak celou věc připravit přišel Luke-jr. U neaktualizovaných uzlů bitcoinové sítě je očekáváno následující chování: - uzel bude fungovat bez změny - uzel neuvidí/bude ignorovat všechna witness, které jsou vždy až za transakcí - všechny witness programy se budou jevit jako výstupní skripty, které může utratit každý (nechávají nenulovou hodnotu na zásobníku interpretu platebních skriptů) U neaktualizovaných peněženek se očekává toto chování:

• příjem BTC z peněženek podporujících Segwit bude možný
• posílání BTC do Segwit peněženek pomocí P2SH
• posílání BTC do Segwit peněženek s použitím nativních witness programů (P2WPKH nebo P2WSH). Za předpokladu, že podporují stávající platební protokol specifikovaný v BIP 70
• nemožnost validace jakékoliv Segwit transakce

Kdy a jak dojde k aktivaci?

O vlastní aktivaci hlasují těžaři vhodným nastavením version bitů v hlavičce bloku dle standardu BIP9. Momentálně hlasuje pro tuto vlastnost cca 20-25 % všech těžařů - nikdo jiný nemůže (bohužel) hlasování technicky ovlivnit. Hlasování bylo spuštěno 15. 11. 2016 a bude v kódu bitcoin core aktivní nejdéle do 15. 11. 2017. Do té doby musí dojít ke shodě mezi těžaři. Shoda spočívá v tom, že 95 % bloků z jedné periody obtížností (2016) musí signalizovat připravenost na SegWit. Potom dojde k tzv. lock-in fázi, kdy bitcoinová síť bude čekat dalších 2016 bloků než dojde k aktivaci. Lock-in fáze dává možnost všem uzlům aktualizovat verzi bitcoin software.  

Bitcoinová politika

Mezi zastánci hardforku - v podobě Bitcoin Unlimited, případně Bitcoin Classic - a Bitcoin Core implementaci vznikla určitá nesnášenlivost. Core tvrdí, že neodmítá návrhy na zlepšení od Bitcoin Unlimited a dalších. Zároveň ale nedochází k žádoucí technické diskuzi nad jednotlivými tématy. Bitcoin Unlimited nechce integrovat Segwit do svého kódu, protože ho považuje za komplikovaný, zde se uvádí argumenty. Atmosféra v celé komunitě je tímto dost postižená a je těžké si o celé věci udělat konzistentní názor. Kde končí technické argumenty a začíná souboj osobních zájmů jednotlivých skupin? Tomuto tématu se podrobně věnuje i článek Válka o velikost bitcoinového bloku.  

Hlasování probíhá - co bude dál?

Segwit se snaží umazat část technologického dluhu, který vznikl některými fatálními rozhodnutími v době návrhu protokolu (malleability, špatné škálování při ověřování transakcí, chybějící hodnota vstupu podepisované transakce). Pokud se to podaří a bude schválen, čeká nás pestrá budoucnost s mnoha novými technologiemi jako mikroplatební kanály, nové typy levných, ale bezpečných peněženek (NFC tokeny apod.), agregace podpisů pomocí Schnorra. Pokud schválen nebude, přichází v úvahu několik scénářů:

• vyhraje hardfork v podobě Bitcoin Unlimited. Výsledkem by mohlo být fyzické rozdvojení blockchainu podobně jako se stalo u projektu Ethereum a koexistence dvou paralelních měn, alespoň po určitou dobu.
• nestane se nic, ani jedna varianta nebude schválena
• vývojáři v kódu Bitcoin Core upraví délku schvalovacího období a bude záviset na těžařích, zda-li takovou verzi budou ochotni nasadit do produkce.

Aktuální stav hlasování: Čeká nás určitě zajímavé období a současný vývoj na burze do celé situace vnáší ještě dobrodružnější faktor. Jde přeci o spoustu peněz nebo ne?

Odkazy - Segwit

• • https://segwit.org
  • http://achow101.com/2016/04/Segwit-FUD-Clearup

• • info pro vývojáře peněženek: https://bitcoincore.org/en/segwit_wallet_dev/

• aktuální serializace transakcí: https://en.bitcoin.it/wiki/OP_CHECKSIG
• https://petertodd.org/2016/segwit-consensus-critical-code-review
• jak by vypadal hardfork v podání pružných transakcí: https://zander.github.io/posts/Flexible_Transactions/
• rozhovor s Tone Vayes co se stane, pokud segwit neuspěje: http://bitcoinist.com/interview-tone-vays/

Odkazy - ostatní

• případ záhadné OP_CODESEPARATOR: https://bitcointalk.org/index.php?topic=52949.0
• web API k full nodu: https://chainquery.com/bitcoin-api/decoderawtransaction
• implementace v C#: https://programmingblockchain.gitbooks.io/programmingblockchain/content/other_types_of_ownership/p2w_over_p2sh.html

[twitter-follow username="btctip_cz" scheme="dark"]. [easy-social-share buttons="facebook,twitter,google,linkedin" counters=1 counter_pos="inside" hide_names="no" template="tiny-retina"]