Domande frequenti sugli aumenti di capacità

1. Quali tecnologie specifiche sono incluse nella roadmap, e per quando possiamo aspettarcele?
2. La segregated witness è equivalente a un soft fork che porta la massima dimensione del blocco a 4MB, a 2MB, a 1,75MB o cosa? Continuo a sentire cifre diverse.
3. Segregated witness sembra complicata. Sarà pronto l’ecosistema per la sua messa in campo?
4. Segregated witness sembra ancora complessa. Perchè semplicemente non aumentare la dimensione massima del blocco?
5. Ci sarà un hard fork prima o come parte della messa in funzione della segregated witness?
6. Se ci sarà comunque un hard fork, perché non farlo adesso?
7. Come funzionerà la segregated witness per i wallets?
8. Se nessuno è obbligato a fare l’aggiornamento perchè ci si dovrebbe preoccupare di farlo? Ho sentito che il P2SH impiegò quasi due anni per essere adottato in maniera diffusa.
9. Ho sentito che stavate compromettendo le transazioni a zero conferme. Quale tecnologia nella roadmap sulla scalabilità sta permettendo questo?
10. I weak blocks e IBLTs recano semplicemente “2016” nella pianificazione della roadmap. questo significa che non avete la minima idea di quando saranno disponibili?
11. Perchè i miners dovrebbero adottare segwit, visto che non fornisce alcun risparmio di banda, storage, o tempo di processamento per loro?
12. Come posso contribuire?

Quali tecnologie specifiche sono incluse nella roadmap, e per quando possiamo aspettarcele?

La nuova tecnologie verrà messa in campo quando sarà pronta e avrà passato i test. Comunque, pensiamo che la seguente sia una pianificazione ragionevole per i miglioramenti specifici descritti nella roadmap

* Le date con l’asterisco rappresentano quelle in cui ci aspettiamo di rilasciare il codice pronto per un soft-fork. Il codice non sarà rilasciato fino a quando non è stato ben recensito, e l’effettivo fork richiederà tempo per essere attivato (BIP66 si attivò nel luglio 2015 dopo qualche mese; BIP65 si attivò nel dicembre 2015 dopo sole 5 settimane).

• Segregated witness testnet: Una testnet separata (non parte della testnet regolare) che fornisce un’opportunità ai contribtori di Bitcoin Core di testare segregated witness (testimonianza segregata ndt) e agli sviluppatori di wallet di cominciare a lavorarci sopra.

• Verifica Libsecp256k1: Aumento di velocità dal 500% to 700% su hardware x86_64 durante la verifica per aiutare i full nodes a unirsi alla rete e per allegerire il peso dei nodi esistenti.

• OP_CHECKSEQUENCEVERIFY: miglioramento del 25,000% nell’ efficienza dei payment channels bi-direzioionali attraverso la possibilità per gli utenti di lasciare il canale aperto quanto lo desiderano.

• VersionBits: aumenta il numero dei softforks che è possibile mettere in campo. Da 1 a 29 rilasci di nuove versioni simultaneamente, questo permette più veloci e più decentralizzati miglioramenti futuri del network.

• Segregated witness: Aumento diretto di capacità dal 175% al 400%, miglioramento addizionale del 66% nell’efficienza dei canali bi-direzionali di pagamento attraverso il consolidamento delle operazioni di apertura e di chiusura del canale, la fine delle malleabilità di terze parti che pregiudicano la messa in campo degli smart contracts, le fraud proofs per permettere ai clients leggeri di contribuire in modo più efficace al rafforzamento delle verifiche di tipo economico, e la possibilità di migliorare il linguaggio di Scripting di Bitcoin in modo che nuovi e più potenti smart contracts possano essere concepiti.

• IBLTs e weak blocks: Diminuzione del 90% o maggiore della larghezza di banda critica necessaria per distribuire i blocchi creati dai miners che necessitano di essere propagati in fretta con un modesto aumento della banda utilizzata, portando molti dei benefici del Bitcoin Relay Network a tutti i full nodes. Questo miglioramento è ottenuto spalmando l’utilizzo della banda utilizzata dai full nodes nel tempo il che significa che IBLT e weak blocks potrebbero permettere aumenti più sicuri della massima dimensione del blocco.

La segregated witness è equivalente a un soft fork che porta la massima dimensione del blocco a 4MB, a 2MB, a 1,75MB o cosa? Continuo a sentire cifre diverse.

Nella Proposta corrente per il soft fork segregated witness (segwit) ogni byte del witness occupa 0.25 bytes corrispondenti nel computo dello spazio limite del blocco, il che significa che il limite massimo del blocco corrisponde teoricamente a poco meno di 4MB.

I blocchi però non sono costituiti solo da dati di witness e ciascun byte non witness conta 1.00 bytes nei confronti del limite massimo del blocco, per questa ragione i blocchi vicini ai 4MB di grandezza sono improbabili.

Secondo alcuni calcoli fatti da Anthony Towns, un blocco pieno solamente di transazioni P2PKH a firma singola standard sarebbe circa 1.6MB e un blocco pieno solo di firme multiple 2-di-2 sarebbe di 2.0MB.

Segregated witness sembra complicata. Sarà pronto l’ecosistema per la sua messa in campo?

Alcune idee sono facili da spiegare ma difficili da realizzare. Altre idee sono facili da realizzare ma difficili da spiegare. Segregated witness sembra essere un’idea di quest’ultimo tipo.

Segwit può essere messa in campo in manera incrementale senza rompere la compatibilità, per cui non è necessaria alcuna significativa preparazione da parte dell’ecosistema. Gli sviuppatori che vogliono farsi un’esperienza “sporcandosi le mani” possono cominciare a testare il loro software nella testnet segwit che verrà messa in campo nel dicembre 2015.

Inizialmente solo i miners che vogliono supportarla dovranno fare l’upgrade per attivarla e rafforzarla sulla mainnet. Le applicazioni esistenti dovranno cambiare solo se vorranno approfittare delle nuove funzionalità.

Le transazioni Segregated witness esigeranno meno commissioni, potranno usufruire di maggiori ottimizzazioni di performance, e potranno supportare gli smart contracts multistage e i protocolli come i payment channels bi-direzionali che possono permettere alla rete di scalare senza aggravio di ulteriori dati per la Blockchain. I wallet sono fortemente incoraggiati ad aggiornarsi ma possono continuare a operare senza modifiche in quanto la messa in campo non rompe la conpatibilità all’indietro.

Segregated witness sembra ancora complessa. Perchè semplicemente non aumentare la dimensione massima del blocco?

C’è un unica riga di codice in Bitcoin Core che dice che la dimensione massima del blocco è di 1,000,000 di bytes (1MB). Il cambiamento più semplice consisterebbe in un hard fork per aggiornare quella riga, per esempio a 2,000,000 di bytes (2MB)

Gli Hard Forks tuttavia sono tutt’altro che semplici:

• Non abbiamo esperienza: I Miners, i negozianti, gli sviluppatori e gli utenti non hanno mai messo in atto un Hard fork, per questa ragione tecniche per farlo in modo affidabile non sono mai state testate.

  Questo a differenza dei soft forks, le cui messe in campo furono inizialmente gestite da Nakamoto, in quelle occasioni abbiamo raccolto abbastanza esperienza dalle complicazioni del BIP16, abbiamo raffinato la tecnica nella messa in campo del BIP34, e abbiamo acquisito sufficienti esperienze con i BIPs 66 e 65 per cominciare a gestire soft forks multipli in futuro con i bits di versione del BIP9.

• L’Upgrade è obbligatorio: Gli Hard forks necessitano che tutti i nodi facciano l’upgrade. Compresi gli operatori dei nodi, se utilizzano questi per proteggere il loro wallet, come anche i client leggeri che ottengono i dati dai nodi.

• Altri cambiamenti sono obbligatori: Anche un cambiamento da una singola riga di codice come quella che aumenta la dimensione massima del blocco ha effetti su altre parti del codice, alcuni dei quali indesiderati. Ad esempio oggi è possibile costruire una transazione che occupa quasi un 1MB di spazio e che richiede 30 secondi o più su un computer moderno per essere validata ( blocchi contenenti transazioni del genere sono effettivamente stati minati). Nei blocchi da 2MB, può essere costruita una transazione da 2MB che potrebbe impiegare oltre 10 minuti per essere validata il che apre dei vettori di attacco basati sul denial of service. Altre linee di codice dovrebbero essere cambiate per prevenire questo tipo di attacchi.

Nonostante queste non indifferenti complessità, con le sufficienti precauzioni, nessuna di queste complicazioni sembra fatale per un hard fork, e noi ci aspettiamo in effetti di andare incontro ad hard forks in futuro. Con Segregated Witness (segwit) però abbiamo un soft fork, simile ad altri soft forks che abbiamo fatto in passato e coi quali abbiamo accresciuto le nostre esperienze nella distribuzione e che ci fornisce in aggiunta molti benefici permettendo che un maggior numero di transazioni sia aggiunta alla Blockchain.

Segwit non richiede cambiamenti ulteriori nella parte più alta degli strati del software rispetto a un semplice aumento della misura massima del blocco, ma se davvero vogliamo vedere scalare il Bitcoin, cambiamenti molto più invasivi saranno necessari comunque, e segwit incoraggerà gentilmente la gente a fare l’upgrade verso modelli più scalabili senza forzarli.

Gli sviluppatori, i miners, e la comunità hanno acquisito una significativa esperienza mettendo in campo i soft forks, e noi crediamo che segwit può essere messo in campo almeno altrettanto velocemente, e probabilmente in modo più sicuro, rispetto ad un hard fork che aumenti la massima dimensione del blocco.

Ci sarà un hard fork prima o come parte della messa in funzione della segregated witness?

No. Questo non è parte della roadmap.

Se ci sarà comunque un hard fork, perché non farlo adesso?

Abbiamo attualmente la capacità di aumentare la capacità del sistema attraverso soft forks che hanno un vasto consenso senza le implicazioni di un hard fork, come descritto in una precedente domanda, per cui l’aspettativa del fatto che ci sarà un hard fork in futuro non è una ragione sufficiente per farlo ora.

Oltre a darci una maggiore capacità in termini di transazioni, i miglioramenti proposti nella roadmap (combinati con altre tecnologie come i payment channels bidirezionali) danno agli utenti la possibilità di ridurre la quantità di spazio blockchain che usano mediamente—aumemntando in effetti la capacità del sistema Bitcoin senza aumentare la quantità di banda utilizzata dai full nodes.

Per esempio:

• BIP68 e BIP112 permettono ai payment channels bi-direzionali di stare aperti indefinitamente, il che ci aspettiamo riduca il numero di transazioni dei payment channels che devono essere confermate sulla blockchain.

• Segregated witness permette alla transazione di chiusura di un payment channel di combinarsi con una transazione di apertura di un altro payment channel riducendo lo spazio della blockchain utilizzato per cambiare canale di circa il 66%.

• Segregated witness permette ai soft forks di cambiare il Liguaggio Di Scripting del Bitcoin in modi che potrebbero ridurre la dimensione media di una transazione, per esempio utilizzando il public-key-recovery-from-signatures o le firme combinate Schnorr.

• Segregated witness permette la creazione di una fraud proof compatta che potrebbe sollevare il livello di sicurezza dei client leggeri a Verifica di Pagamento Semplificata (SPV) fino a un livello vicino a quello dei full nodes, il che potrebbe permettere alla rete di funzionare bene con un numero inferiore di full nodes rispetto a quanto avviene con la tecnologia attualmente in uso.

L’effetto reale di queste tecnologie è sconosciuto, ma scalare ora attraverso un soft fork che gode di un largo consenso ci permette di ottenere i vantaggi immediati, testare e misurare le potenzialità di medio termine, e usare questi dati per i piani di lungo periodo.

Come funzionerà la segregated witness per i wallets?

I wallets che suppartano P2SH possono migrare completamente alla segregated witness in due fasi:

• Phase 1: Gli scripts subiscono l’operazione di hash due volte, la prima a 256 bits e poi a 160 bits. L’hash a 160 bits sarà compatibile con gli indirizzi P2SH esistenti, in questo modo i wallet saranno in grado di mandare e ricevere bitcoins a e da wallets attualmente esistenti.

• Phase 2: Gli script subiscono una sola operazione di hash a 256 bits. Questo formato non sarà compatibile con i wallets esistenti ma permetterà una più efficiente allocazione dello spazio nel blocco e offrirà una migliore sicurezza per merito di una migliore resistenza alla collisione.

Se nessuno è obbligato a fare l’aggiornamento perchè ci si dovrebbe preoccupare di farlo? Ho sentito che il P2SH impiegò quasi due anni per essere adottato in maniera diffusa.

Ogni byte della parte witness di una transazione segregated witness (segwit) occupa uno spazio corrispondente a soli 0.25 bytes in una transazione. Siccome le commissioni della transazione sono basate sull’ampiezza della transazione, questo è uno sconto effettivo del 75% sulle commissioni per quella parte di transazione—ma solo per coloro che utilizzano segwit.

David Harding ha fornito una tabella dei risparmi stimati a vari livelli di commissioni/transazioni. Da questa si rileva, che se la commissione di una tipica transazione da 250-byte è di 0.01 USD, utilizzando segwit si risparmieranno circa 0.003 USD quando spendiamo l’output di una transazione P2PK-in-P2SH.

(Non ci aspettiamo che le commissioni raggiungano i livelli che vediamo in tabella. Questi sono riportati solo per riferimento.)

I wallet web e gli exchanges che mandano grandi quantità di transazioni ogni giorno a prezzo fisso (come per esempio gratis oppure con l’1% di commissione a transazione) tenderanno ad essere early adopters–per loro anche il piccolo risparmio per spesa riportato nella tabella sopra tende a raggiungere un ammontare significativo se ripetuto centinaia o migliaia di volte in un giorno.

Ho sentito che stavate compromettendo le transazioni a zero conferme. Quale tecnologia nella roadmap sulla scalabilità sta permettendo questo?

Nessuna di queste. in condizioni normali, la versione attuale di Core non rimpiazzerà una transazione non confermata con un’altra transazione che spende anche uno solo degli stessi inputs. Qualcuno pensa che questo voglia dire che la prima transazione che si vedono spendere un particolare input sia sicura, ma questo è falso (se fosse vero, non avremmo bisogno della blockchain.)

Questa attuale policy di default non implica che coloro i quali vogliono aggiornare le loro transazioni non confermate non possano farlo. La versione originale di Bitcoin forniva agli utilizzatori un modo per annunciare che volevano aggiornare una transazione, ma Nakamoto dovette disabilitarla nel 2010 per scongiurare attacchi di tipo denial-of-service.

Gli sviluppatori recenti del Bitcoin Core hanno capito che potevano prevenire gli attacchi DOS esigendo che le transazioni aggiornate pagassero commissioni extra e hanno ripristinato il meccanismo di Nakamoto per indicare quando una transazione può essere rimpiazzata. Questa funzionalità è prevista per la versione di Bitcoin Core 0.12.0 (gennaio/febbraio 2016) ma, come la funzionalità originale di Nakamoto, è facoltativa e gli utenti che vogliono essere in grado di rimpiazzare la loro transazione devono usare un wallet che supporti questa funzione.

Attualmente non ci sono wallet che supportano questa funzione, ma i wallet che la supporteranno in futuro potranno combinare insieme transazioni multiple per ridurre lo spazio che queste occupano nella blockchain così come aumentare le commissioni che pagano su transazioni che stanno impiegando molto tempo per la conferma, evitando che le transazioni rimangano sospese (un problema di usabilità noto).

I weak blocks e IBLTs recano semplicemente “2016” nella pianificazione della roadmap. questo significa che non avete la minima idea di quando saranno disponibili?

Weak blocks and IBLTs sono due tecnologie separate che sono ancora studiate intensamente per scegliere i giusti paramentri ma il numero di sviluppatori che lavorano su di esse è limitato per questo è difficile stimare quando saranno realizzate.

Weak blocks e IBLTs possono essere entrambe messe in campo come miglioramenti di rete puri (non sono richiesti forks nè soft nè hard) il che significa che ci sarà solo un breve lasso di tempo tra il completamento della fase di test al momento in cui i loro benefici saranno disponibili a tutti i nodi che avranno fatto l’upgrade. Noi speriamo che ciò avvenga nel corso del 2016.

Dopo la messa in campo, entrambi Weak Blocks e IBLTs potrebbero beneficiare di un piccolo soft fork (l’ordinamento canonico di transazione), che dovrebbe essere facile da attuare utilizzando il sistema versionbits del BIP9 descritto altrove in questa FAQ.

Perchè i miners dovrebbero adottare segwit, visto che non fornisce alcun risparmio di banda, storage, o tempo di processamento per loro?

Neanche la maggior parte dei soft forks precedenti ha procurato ai miners benefici in questi termini. Ad esempio:

Il soft fork relativo al BIP66 (strict DER) che si attivò nel Luglio 2015 fornì immediatamente tempi di processamento ridotti rendendo possibile il passaggio a libsecp256k1 per la validazione come descritto da qualche altra parte in questa FAQ. La riduzione del tempo di verifica fa di questo soft fork una gradita novità in quanto fornisce immediati vantaggi ai miners.

Ciò che fa Segregated Witness (segwit) è fornire vari benefici importanti a chiunque lo utilizzi per creare transazioni:

Un rimedio permanente per la malleabilità che permette agli smart contracts a più stage di fiorire, una lieve riduzione delle commissioni, facili aggiornamenti futuri del Linguaggio di Scripting Bitcoin che permettono ai wallet di avere accesso a nuove funzionalità.

Attraverso i soft forks e atraverso discussoni come quella della sessione dei miners allo Scaling Bitcoin di Hong Kong, i miners hanno ripetutamente dimostrato che vogliono che il Bitcoin sia il più utile sistema possibile anche se non dovessero ricevere nessun beneficio diretto da questo. Segwit e altri miglioramenti nella roadmap forniscono significativi avanzamenti di usabilità.

In aggiunta, segwit permette ai miners di mettere più transazioni nei loro blocchi il che permette di aumentare i loro ricavi per blocco minato.

Come posso contribuire?

Comincia con il leggere la pagina del contributor di Bitcoin Core su Bitcoin.org. in particolare, la revisione del codice è una parte critica nel mettere in atto i soft fork.

Per ricevere suggerimenti specifici su come si può contribuire, unisciti al canale IRC #bitcoin-dev.