From 344b1104c16a4f2e34ead9c200fcf20a4743bfea Mon Sep 17 00:00:00 2001 From: Gabriele Domenichini Date: Fri, 25 Dec 2015 09:23:31 +0100 Subject: [PATCH] Translated bitcoin capacity-increases-FAQ.md in italian Some constructions in italian don't work so well. I have tried to expose the concept as best as I colud remaining adherent to the original text. --- it_IT/bitcoin-core/capacity-increases-faq.md | 388 +++++++++++++++++++ 1 file changed, 388 insertions(+) create mode 100644 it_IT/bitcoin-core/capacity-increases-faq.md diff --git a/it_IT/bitcoin-core/capacity-increases-faq.md b/it_IT/bitcoin-core/capacity-increases-faq.md new file mode 100644 index 00000000..637a9d65 --- /dev/null +++ b/it_IT/bitcoin-core/capacity-increases-faq.md @@ -0,0 +1,388 @@ +--- +# This file is licensed under the MIT License (MIT) available on +# http://opensource.org/licenses/MIT. + +layout: base-core +lang: it +id: bitcoin-core-capacity-increases-faq +columns: 1 +title: FAQ sugli Aumenti di capacità — Bitcoin Core +breadcrumbs: + - bitcoin + - bcc + - Capacity increases FAQ +--- +# Domande frequenti sugli aumenti di capacità + +1. Indice +{:toc} + +## Quali tecnologie specifiche sono incluse nella roadmap, e per quando possiamo aspettarcele? {#roadmap-dates} + +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][BIP68] & [112][BIP112]) + [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). + + +- **Segregated witness testnet:** Una testnet separata (non parte + della testnet reolare) 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 herdware + x86\_64 durante la verifica per aiutare i full nodes a unirsi alla rete e per + allegerire il peso dei nodi esistenti. + +- **[OP\_CHECKSEQUENCEVERIFY][BIP112]:** miglioramento del 25,000% nella bi-directional + [payment channel efficiency][] attraverso la possibilità per gli utenti di + lasciare il canale aperto quanto lo desiderano. + +- **[VersionBits][BIP9]:** 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][bip-segwit]:** 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 dei parametri economici, 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][increase in total bandwidth], 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. {#segwit-size} + +Nella [Proposta corrente][current proposal] 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][calculations] 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. + +[current proposal]: https://youtu.be/fst1IK_mrng?t=2234 +[calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html + +## Segregated witness sembra complicata. Sarà pronto l'ecosistema per la sua messa in campo? {#ecosystem-ready} + +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? {#size-bump} + +C'è un [unica riga di codice][max_block_size] 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][BIP66] e [65][BIP65] 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? {#pre-segwit-fork} + +No. Questo non è parte della [roadmap][]. + +[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html + +## Se ci sarà comunque un hard fork, perché non farlo adesso? {#why-not-now} + +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][q simple raise], 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? {#segwit-in-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. {#why-upgrade} + +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][estimated savings] +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? {#rbf} + +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-iblts} + +[Weak blocks and IBLTs][] sono due tecnologie separate che sono ancora +[studiate intensamente][actively studied] 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][canonical transaction ordering]), che +dovrebbe essere facile da attuare utilizzando il sistema versionbits del +[BIP9][] descritto altrove in questa FAQ. + +[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions + +## Perchè i miners dovrebbero adottare segwit, visto che non fornisce alcun risparmio di banda, storage, o tempo di processamento per loro? {#why-mine-segwit} + +Neanche la maggior parte dei [soft forks precedenti][previous soft forks] 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][Miners' Panel] 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][Bitcoin Core contributor] su Bitcoin.org. +in particolare, la [revisione del codice][code review] è 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][]. + +[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&uio=d4 +[actively studied]: http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/ +[bip-segwit]: https://github.com/jl2012/bips/blob/segwit/bip-segwit.mediawiki +[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki +[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki +[BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki +[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki +[BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki +[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki +[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki +[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki +[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki +[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki +[bitcoin core contributor]: /en/bitcoin-core/ +[Bitcoin relay network]: http://bitcoinrelaynetwork.org/ +[code review]: https://bitcoin.org/en/development#code-review +[estimated savings]: https://www.reddit.com/r/bitcoinxt/comments/3w1i6b/i_attended_scaling_bitcoin_hong_kong_these_are_my/cxtkaih +[increase in total bandwidth]: https://scalingbitcoin.org/hongkong2015/presentations/DAY1/3_block_propagation_1_rosenbaum.pdf +[libsecp256k1]: https://github.com/bitcoin/secp256k1 +[libsecp256k1 verification]: https://github.com/bitcoin/bitcoin/pull/6954 +[max_block_size]: https://github.com/bitcoin/bitcoin/blob/3038eb63e8a674b4818cb5d5e461f1ccf4b2932f/src/consensus/consensus.h#L10 +[miners' panel]: https://youtu.be/H-ErmmDQRFs?t=1086 +[payment channel efficiency]: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf +[previous soft forks]: https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki#classification-of-existing-bips +[weak blocks and iblts]: https://www.youtube.com/watch?v=ivgxcEOyWNs&t=1h40m20s +[q simple raise]: #size-bump