Aggiornamento Taproot: gli utenti Bitcoin si avvicinano al piano di attivazione, la data è ancora da definire

Molti degli investitori più attivi di Bitcoin hanno praticamente messo a punto il metodo di attivazione per Taproot, il più grande aggiornamento del software Bitcoin degli ultimi anni.

In un incontro pubblico su Internet Relay Chat (IRC) martedì, sviluppatori, minatori, professionisti e appassionati Bitcoin hanno discusso i dettagli su come confezionare l'aggiornamento Taproot in un aggiornamento e come attivarlo una volta che il codice è stato distribuito.

I più attivi dei circa 200 partecipanti alla chat (per lo più, ma non tutti, sviluppatori) sembravano concordare sulla Bitcoin Improvement Proposal (BIP) che sarebbe stata utilizzata per attivare Taproot. Per preparare la BIP alla spedizione, hanno anche votato per "unire" due "pull request" (PR) su GitHub che delineano le regole per la logica di attivazione di Taproot nel codice sorgente di Bitcoin quando arriverà il momento di spingere l'aggiornamento.

Continua a leggere: Come l'aggiornamento Taproot di Bitcoin migliorerà la Tecnologie nell'intero stack software di Bitcoin

ONE di questi, RP n. 1021, include una misura per consentire agli utenti di forzare l'attivazione dell'aggiornamento nel caso in cui i minatori non lo supportino, mentreRP n. 1020 "raccomanda" solo questa forzatura ma non la abilita di default. Poiché la maggior parte dei partecipanti supporta BIP 8 senza attivazione forzata, come ha osservato nella chat il leader dell'incontro e sviluppatore Bitcoin CORE Michael Folkson, un'ulteriore discussione individuerà una data per iniziare l'attivazione e discuterà ulteriormente la misura in cui è necessario un "giorno di bandiera" per forzare l'attivazione.

Perché (probabilmente) T è necessario un giorno di bandiera per Taproot

Non che i minatori che bloccano l'aggiornamento dovrebbero essere un problema per Taproot, che ha circa il 91% di supporto dei minatori,secondo un sondaggio gestito dal vicepresidente di Poolin Alejandro De La Torre.

Il sondaggio fornisce un feedback cruciale dai minatori per l'organizzazione decentralizzata di Bitcoin, che non può coordinare unilateralmente gli aggiornamenti come può fare un fornitore di software centralizzato. Aggiornamenti come Taproot richiedono un coordinamento scrupoloso tra minatori, utenti full-node (coloro che eseguono il codice open source di Bitcoin) e altri stakeholder per garantire che nulla vada storto (come l'introduzione di un bug o la divisione della rete Bitcoin in due versioni incompatibili).

Poiché i miner non hanno mostrato alcuna resistenza a Taproot, la maggior parte dei partecipanti ha espresso una preferenza per BIP8 (falso), con (falso) riferito all'esclusione di un "giorno di bandiera" per forzare l'attivazione tramite nodi completi nel caso in cui l'aggiornamento fallisca per mancanza di attivazione da parte dei miner.

BIP8, come è stato concepito attualmente, darebbe ai miner Bitcoin e agli operatori full-node un anno per adottare l'aggiornamento, dopodiché l'aggiornamento verrebbe "bloccato" con un supporto sufficiente. In ONE versione di questo, BIP8 (falso), l'aggiornamento semplicemente fallisce senza un supporto sufficiente. In un'altra, BIP8 (vero), un "giorno di bandiera" costringerebbe i miner a segnalare l'aggiornamento quando scade il periodo di attivazione, se non lo hanno fatto in anticipo.

Continua a leggere: Tutti i principali pool di mining ora supportano Taproot, il più grande aggiornamento di Bitcoin in anni

Nota tecnica: ci sono alcuni modi per aggiornare Bitcoin, il più semplice è tramite l'attivazione del miner, dove i pool di mining si aggiornano e iniziano a estrarre blocchi secondo le nuove regole. In caso contrario, gli operatori di nodi possono eseguire l'aggiornamento e scegliere di rifiutare i blocchi dai miner che non hanno segnalato il supporto per un aggiornamento. Questo cosiddetto "soft fork di attivazione utente" (UASF), quasiy utilizzato per attivare SegWit, costringerebbe i minatori resistenti ad adottare il nuovo aggiornamento.

"Completamente aneddotico ma non ho vistoQualunque [enfasi loro] opposizione a Taproot", ha detto ONE willcl_ark nella chat, riferendosi alla necessità o meno di un flag day. "Penso che usare il minimo comune denominatore dei parametri di attivazione (falso) sembri la scelta sensata per evitare qualsiasi divisione intenzionale o accidentale della catena nel caso in cui i minatori T segnalino".

Qual è il problema?

Altri ancora, come il prolifico sviluppatore Bitcoin CORE Luke Dashjr, non sono convinti che l'inclusione di un flag day sia superflua. In effetti, è una questione di principio dimostrare che sono gli operatori dei nodi a decidere il software, non i miner.

"T importa", ha detto nella chat in riferimento al supporto dei miner. "I miner non decidono i cambiamenti di protocollo", ha continuato, lasciando intendere che sono gli operatori dei nodi a decidere invece scegliendo quale software eseguire. Inoltre, ha sostenuto che BIP8 (falso), "lascia che i miner decidano" il destino dell'aggiornamento. Quando arriverà il momento, ha detto più avanti nella chat, configurerà il suo nodo per eseguire la versione BIP8 (vera) che rifiuta i blocchi non Taproot dai miner.

"BIP8 con [attivazione] obbligatoria non è una dimostrazione di forza non necessaria", ha affermato hsjoberg, ribadendo la convinzione di Dashjr che la scelta dell'utente di un UASF sia un necessario controllo e bilanciamento dell'apatia dei minatori.

Continua a leggere: UASF rivisitato: la rivolta degli utenti di Bitcoin lascerà un'eredità duratura?

Tuttavia, una dimostrazione di forza potrebbe comportare rischi inutili e creare un precedente indesiderato per future deliberazioni sugli aggiornamenti, soprattutto quando i miner non hanno dato agli utenti alcun motivo di essere ostili, come dimostrano gli argomenti a favore del BIP8 (falso).

"[BIP8 false] è più sicuro di [true], quindi vale la pena provare prima [false] dato che sappiamo che l'hashpower è già pro-Taproot per circa il 90%", ha affermato Chris Belcher, sviluppatore di Bitcoin CORE e CoinSwap.

Altri, come lo sviluppatore di Suredbits e Bitcoin CORE Ben Carman, hanno sottolineato che è possibile configurare l'aggiornamento in un secondo momento durante l'attivazione per includere il flag day nel caso in cui i miner non segnalino, "rendendo più sicuro e facile per gli utenti far rispettare l'UASF".

Alla fine dell'incontro, i partecipanti hanno concordato di unire le richieste di pull su GitHub sia per un percorso di attivazione non forzata (PR #1020) sia per un percorso di attivazione forzata (PR #1021). Con entrambe queste regole nel GitHub di Bitcoin Core, le regole per un'attivazione forzata potevano essere utilizzate solo se necessario.

Più riflessione

Lo scenario di divisione della catena descritto da willcl_ark è fondamentalmente l'uomo nero che tutti vogliono evitare qui. Il timore è che BIP8 (true) richieda il 100% di hashrate per segnalare l'aggiornamento dopo la scadenza dell'attivazione di Taproot. Quindi, se un numero sufficiente di utenti ha seguito questa strada nello stesso momento in cui altri utilizzano BIP8 (false) per l'attivazione non forzata (che richiede solo il 95% di hashrate), le due diverse versioni del codice potrebbero creare due cronologie incompatibili del registro delle transazioni di Bitcoin.

Ecco perché, se proprio si deve ricorrere alla segnalazione forzata, è meglio farlo tramite il PR #1021 di AJ Townes, che “rende più sicura l’opzione UASF, che è lo scenario più ‘pericoloso’”, ha scritto Carman nella chat.

Per ora sembra che coloro che sono coinvolti nelle discussioni siano favorevoli al BIP8 (falso) con l'aggiunta di un UASF tramite PR #1021 se necessario, ma sono necessarie ulteriori discussioni per definire la tempistica esatta del periodo di attivazione iniziale (o per quanto tempo gli utenti hanno a disposizione per l'aggiornamento dopo che l'aggiornamento è attivo), nonché la data di attivazione da impostare.

Questi “cosa succederebbe se” e “quando” saranno discussi, tra le altre cose, in una riunione del 16 febbraio.