Marea „Curatare” a algoritmului(regulilor) de consens este un soft fork propus de Matt Corallo. Spre deosebire de celelalte imbunatatiri de protocol, inclusiv cele expuse in articolul trecut, acest soft fork nu este menit sa aduca optiuni sau posibilitati noi pentru aplicatia Bitcoin ci, mai degraba, sa inlature cateva vulnerabilitati ale protocolului.
Acestea sunt putin mai tehnice si putin mai ascunse in cod. Ca si exemple: algoritmul de ajustare a dificultatii, modalitatea prin care se face un upgrade in cod si chiar modificarea tranzactiilor care necesita o putere mare de procesare pentru a fi procesate. Aceste vulnerabilitati se presupune ca ar exista dar exploatarea lor ar costa foarte mult vis a vis de cat se poate castiga de pe urma lor, asadar sunt considerate neprofitabile. Putem spune, de asemenea, ca atunci cand cineva exploateaza aceste vulnerabilitati, actiunea de inlaturare a atacatorului si modificarea regulilor se poate face foarte usor.
„The Great Consensus Cleanup”
Totusi, indepartarea acestor vulnerabilitati poate face codul mai sigur si imbunatatirea codului mai facila.
Motivul principal pentru care soft fork-ul „The Great Consensus Cleanup” nu a fost implementat este, probabil, faptul ca acest upgrade va face anumite monede (UTXO) incapabile de a fi cheltuite. Este foarte putin probabil ca aceste monede sa existe dar in acelasi timp este imposibil de identificat daca exista. Implementarea upgrade-ului poate provoca evenimente nedorite de catre anumiti participanti la retea (cei care au UTXO-uri de acest tip), fiind in contradictie cu „Constitutia” bitcoin.
Matt Corallo a propus fork-ul, subliniind obiectivele principale, acestea fiind relativ necunoscute pentru utilizatorii de zi cu zi la fel ca si tranzactiile legacy, dar importante pentru cei care construiesc in ecosistemul Bitcoin.
Impiedicarea utilizatorilor de a folosi P_CODESEPARATOR si FindAndDelete() in tranzactiile legacy (non-segwit).
Inca nu stim daca utilizatorii folosesc aceste doua optiuni in tranzactiile legacy, dar un atacator le poate folosi, marind cantitatea de putere de procesare necesara pentru a verifica o astfel de tranzactie. Avand in vedere ca astfel de tranzactii necesita o putere mare de procesare, odata incluse in block-uri, timpul de verificare al acestora (nr: block-urile) poate dura cu pana la 30 de minute mai mult. Multi nu au auzit despre aceste tipuri de tranzactii si de modalitati de generare a unei tranzactii de acest gen pentru simplul fapt ca acestea se pot realiza foarte usor folosind alte metode. Oricine are nevoie de OP_CODESEPARATOR poate folosi implementarea BIP143 segwit, care inlatura necesitatea unei puteri de procesare foarte mari.
Ca o curiozitate, aceste tipuri de tranzactii nu au for minate sau introduse in retea in versiunea Bitcoin Core 0.16.1 din Iunie 2018.
Atacul de tip Time Warp
Atacul de acest tip permite minerilor care detin majoritatea puterii de procesare (Hash Rate) sa manipuleze dificultatea (sa o mentina sau sa o modifice) chiar si atunci cand puterea de procesare in retea creste, permitandu-le sa produca block-uri mai repede decat protocolul le permite. Accelearea retelei le-ar putea permite minerilor sa mineze extrem de multe block-uri (si sa-si insuseasca block reward-ul pentru fiecare block gasit) punand in circulatie toate monedele in aproximativ 3 saptamani de la lansarea atacului. Desi pare o problema foarte grava, pregatirea atacului dureaza cam 7-10 zile, timp in care participantii la retea observa si pot lua masuri. Nu a incercat nimeni asa ceva pana acum si oricum ar necesita unirea mai multor pool-uri cu puteri mari de procesare.
Interzicerea utilizarii non-push opcodes in scriptSig
Datorita faptului ca Bitcoin, din punct de vedere tehnic, inca accepta non-push opcodes in scriptSig, un atacator poate mari cantitatea de putere necesara pentru a verifica o tranzactie inclusa intr-un block.
Interzicerea utilizarii non-push opcodes in scriptSig este o politica adoptata de mineri inca din 2011 si este interzisa prin cod pentru pentru plati catre BIP16 P2SH si BIP141 Segwit. Soft-fork-ul propus introduce in cod modificari pentru toate tipurile de adrese.
Interzicerea tranzactiilor mai mici sau egale cu 64 bytes.
Avand in vedere ca nu exista posibilitatea de a cheltui bitcoin in siguranta prin tranzactii mai mici sau egale cu 64 bytes, soft-fork-ul propus interzice includerea acestor tranzactii in block-uri valide.
Tranzactiile de acest tip se pot confunda cu hash-urile Merkle Tree-urilor sau vice versa. Aceasta confuzie poate crea vulnerabilitati in demonstrarea autenticitatii Merkle Tree sau a SPV-urilor.
Toate conceptele sunt explicate de Corallo pe larg si urmeaza a fi testate si evaluate de catre experti si de catre cei care detin cheile implementarii in protocol, urmand a fi supuse testului adoptiei de catre comunitate.
Detalii mult mai tehnice puteti gasi pe github.
In articolele urmatoare vom vorbi despre:
Upgrade-ul „NoInput Class (NIC)”
Implementarea OP_CHECKTEMPLATEVERIFY
DriveChain-urile si BIP-urile lor ( BIP- Bitcoin Implementation Protocol)\
