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

Dec 2015   Messa in campo di Segregated witness in testnet
Feb 2016 0.12.0 libsecp256k1 verification
Feb 2016   la funzionalità segregated witness è completata & pronta per la recensione generale
Mar 2016* 0.12.x Messa in campo di OP_CHECKSEQUENCEVERIFY (BIPs 68 & 112) + BIP113 as first BIP9 versionbits soft fork
April 2016* 0.12.x Messa in campo di segregated witness
2016   Weak blocks, IBLTs, oppure entrambi

* 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).

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:

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:

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:

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.

Transazione Bytes risparmiati $0.01/250B $0.05/250B $0.25/250B $1.00/250B
P2PK-in-P2SH 79/107 $0.003 $0.015 $0.079 $0.316
1-of-1 P2SH multisig 83/112 $0.003 $0.016 $0.083 $0.332
2-of-2 P2SH multisig 163/219 $0.006 $0.032 $0.163 $0.652
2-of-3 P2SH multisig 189/254 $0.007 $0.037 $0.189 $0.756

(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:

BIP16 (P2SH) Nuovo tipo di transazione
BIP30 (duplicate txids) Controllo richiesto per i txids duplicati
BIP34 (height in coinbase) Ridotto lo spazio a disposizione del miner per la coinbase di 4 byte
BIP65 (OP_CLTV) Nuovo opcode

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.