Consensul privind modul de activare a actualizării Taproot a Bitcoin este aproape

Mulți dintre cei mai activi actori ai Bitcoin au aproape că au pus în aplicare metoda de activare pentru Taproot, cel mai mare improve al software-ului Bitcoin din ultimii ani.

Într-o reuniune publică de pe Web Relay Chat (IRC), marți, dezvoltatorii Bitcoin, minerii, profesioniștii în afaceri și entuziaștii au prezentat specificul modului de a împacheta actualizarea Taproot într-o actualizare – și cum să-l activați odată ce codul a fost expediat.

Cei mai activi dintre cei aproximativ 200 de participanți la chat (cea mai mare parte, dar nu toți, dezvoltatorii) păreau de acord asupra propunerii de îmbunătățire Bitcoin (BIP) care va fi utilizată pentru a activa Taproot. Pentru a pregăti BIP pentru expediere, au votat, de asemenea, să „îmbine” două „solicitări de tragere” (PR) pe GitHub care descriu regulile pentru logica de activare Taproot în codul sursă al Bitcoin, atunci când va veni momentul să împingem actualizarea.

Una dintre acestea, PR # 1021, embrace o măsură pentru a permite utilizatorilor să activeze forțat actualizarea în cazul în care minerii nu o acceptă, în timp ce PR # 1020 doar „recomandă” această forțare, dar nu o permite în mod implicit. Deoarece majoritatea tuturor participanților acceptă BIP 8 fără activare forțată, așa cum a remarcat liderul întâlnirii și dezvoltatorul Bitcoin Core Michael Folkson în chat, discuțiile ulterioare vor stabili o dată pentru începerea activării – și vor discuta în continuare măsura în care o „zi de pavilion” pentru a forța activarea este necesar.

Nu faptul că minerii care blochează actualizarea ar trebui să fie o problemă pentru Taproot, care are un sprijin de 91% pentru miner, conform unui studiu condus de vicepreședintele F2Pool Alejandro De La Torre.

Sondajul oferă suggestions essential de la mineri pentru organizația descentralizată a Bitcoin, care nu poate coordona unilateral actualizările așa cum poate un furnizor de software program centralizat. Actualizările precum Taproot necesită o coordonare minuțioasă între mineri, utilizatori cu nod complet (cei care rulează codul open-source al Bitcoin) și alte părți interesate pentru a se asigura că nimic nu merge prost (cum ar fi introducerea unei erori sau împărțirea rețelei Bitcoin în două versiuni incompatibile).

Deoarece minerii nu au manifestat nicio rezistență la Taproot, majoritatea participanților au exprimat o preferință pentru BIP8 (fals), (fals) făcând referire la excluderea unei „zile de pavilion” pentru a forța activarea prin noduri full în cazul în care actualizarea eșua din lipsa activării minerului .

BIP8 așa cum a fost conceput în prezent ar oferi minerilor Bitcoin și operatorilor de nod complet un an pentru a adopta actualizarea, după care actualizarea va fi „blocată” cu suficientă susținere. Într-o versiune a acestuia, BIP8 (fals), actualizarea eșuează pur și simplu fără suficient suport. Într-un alt, BIP8 (adevărat), o „zi de pavilion” i-ar obliga pe mineri să semnaleze pentru actualizare atunci când expiră intervalul de timp de activare dacă nu au făcut acest lucru în prealabil.

Notă tehnică: Există câteva modalități de a actualiza Bitcoin, cea mai ușoară fiind prin activarea minerilor, unde piscinele de minerit se actualizează și încep blocurile de minerit în conformitate cu noile reguli. În caz contrar, operatorii de noduri pot face improve și pot alege să respingă blocurile de la mineri care nu au semnalat suport pentru o actualizare. Acest așa-numit „consumer activate tender fork” (UASF), folosit și pentru activarea SegWit, ar forța minerii rezistenți să adopte noul improve.

„Complet anecdotic, dar nu am văzut orice [emphasis theirs] opoziție față de Taproot ”, a spus unul willcl_ark în chat, referindu-se la necesitatea sau nu a unei zile de pavilion. „Cred că utilizarea celui mai mic numitor comun al parametrilor de activare (fals) pare a fi alegerea sensibilă pentru a evita orice diviziuni intenționate sau accidentale ale lanțului în cazul în care minerii nu semnalizează”.

Alții încă, precum prolificul dezvoltator Bitcoin Core, Luke Dashjr, nu sunt convinși că includerea unei zile de pavilion nu este necesară. De fapt, este o chestiune de principiu să demonstrezi că operatorii de noduri decid software-ul, nu minerii.

„Nu contează”, a spus el în chat, referindu-se la sprijinul minerilor. „Minerii nu decid modificările de protocol”, a continuat el, subliniind că operatorii nodului sunt cei care decid în schimb alegând ce software program să ruleze. Mai mult, el a susținut că BIP8 (fals), „let[s] minerii decid ”soarta actualizării. Când va veni momentul, a spus el mai târziu în chat, își va configura nodul pentru a rula versiunea BIP8 (adevărată) care respinge blocurile non-Taproot de la mineri.

„BIP8 cu obligatoriu [activation] nu este o demonstrație inutilă de forță ”, a spus hsjoberg, reiterând convingerea lui Dashjr că alegerea de către utilizator a unui UASF este o verificare și un echilibru necesar asupra apatiei minerilor.

Cu toate acestea, o demonstrație de forță ar putea introduce riscuri inutile și ar putea crea un precedent nedorit pentru viitoarele deliberări de actualizare, mai ales atunci când minerii nu au oferit utilizatorilor niciun motiv pentru a fi combativi, așa că mergeți la argumentele în favoarea BIP8 (fals).

„[BIP8 false] este mai sigur decât [true], deci merită să o faci [false] mai întâi, având în vedere că știm că puterea de putere este de aproximativ 90% deja pro-Taproot ”, a spus Chris Belcher, dezvoltatorul Bitcoin Core și CoinSwap.

Alții, cum ar fi Suredbits și dezvoltatorul Bitcoin Core, Ben Carman, au subliniat că ați putea configura upgrade-ul mai târziu în activare pentru a embrace ziua pavilionului în cazul în care minerii nu reușesc să semnaleze, „ceea ce face mai sigur și mai ușor pentru utilizatori aplicarea UASF”.

La sfârșitul întâlnirii, participanții au fost de acord să îmbine cererile de pull pe GitHub atât pentru o rută de activare neforțată (PR # 1020), cât și pentru o rută de activare forțată (PR # 1021). Cu ambele reguli în GitHub de la Bitcoin Core, regulile pentru o activare forțată ar putea fi folosite numai dacă este necesar.

Scenariul de împărțire a lanțului descris de willcl_ark este în esență bogeymanul pe care toată lumea vrea să-l evite aici. Teama este că BIP8 (adevărat) necesită 100% din hashrate pentru a semnaliza upgrade-ul după terminarea termenului de activare Taproot. Astfel, dacă suficient de mulți utilizatori au parcurs această rută în același timp în care alții folosesc BIP8 (fals) pentru activarea neforțată (care necesită doar 95% din hashrate), cele două versiuni de cod diferite pot crea două istorice incompatibile ale registrului tranzacțiilor Bitcoin.

De aceea, dacă semnalizarea forțată trebuie să se întâmple, este bine să o faceți prin PR # 1021 de AJ Townes, care „face mai sigur opțiunea UASF, care este cel mai„ periculos ”scenariu”, a scris Carman în chat.

Deocamdată, se pare că cei implicați în discuții favorizează BIP8 (fals) cu adăugarea unui UASF prin PR # 1021, dacă este necesar, dar este necesară o discuție suplimentară pentru a analiza cronologia exactă a perioadei inițiale de activare (sau cât timp utilizatorii au pentru a face improve după actualizarea se activează), precum și ce dată de activare să setați.

Aceste „ce dacă” și „când” vor fi evidențiate, printre alte chestiuni, într-o ședință miercuri viitoare.