È Partito il soft fork per l'aumento del block size

[Sandro kensan]

Today marks the release of Bitcoin Core version 0.13.1. This is the official introduction of Segregated Witness, the long-awaited centerpiece of Bitcoin Core’s scalability road map. Starting November 15, Bitcoin miners can signal support for the proposed protocol upgrade, which, if activated, enables a number of new features on the Bitcoin network as well as an effective block size limit increase.

Il 27 ottobre è iniziata la distribuzione del soft fork di nome Segregated Witness che porterà l'aumento del block size fino a quasi 2 MB, quindi quasi un raddoppio (1.6~2.0MB). Il team che ha distribuito l'upgrade è quello del Bitcoin Core.

I tempi minimi sono 15 novembre per raggiungere il 95% del consenso e poi verso metà dicembre ci sarà lo switch. Nel caso peggiore ci sarà tempo fino al 15 novembre del prossimo anno per seguire la procedura indicata dal BIP9.

Pare che ci siano dei minatori cinesi che raggiungono una percentuale del 9% della potenza che non voglia adottare il Segregated Witness ma ci sarà tempo per vedere come evolveranno le cose, c'è un anno massimo di tempo.

Maggiori info:

https://bitcoinmagazine.com/articles/segregated-witness-officially-introduced-with-release-of-bitcoin-core-1477611260

Vedremo i grafici a partire dal 15 novembre sulla percentuale di adozione di Bitcoin Core version 0.13.1 e quindi si capirà quanto tempo si dovrà aspettare per raggiungere il 95% dell'hash rate.

Activation will follow the standards as established by Bitcoin Improvement Improsal (BIP)9. This means that, within a single difficulty period of 2016 blocks (about two weeks), at least 95 percent of blocks must be mined by a miner that signals support for Segregated Witness. If this threshold is reached, the following difficulty period allows everyone who wants to upgrade the chance to do so. After that, Segregated Witness support is activated, and Segregated Witness transactions are accepted by Bitcoin miners.

Alcune info utili nel caso in cui parta lo switch (speriamo):

I think this guide is overly technical for average user. It should have some simple questions on the top like this:

• Can I use my non-upgraded wallet? Yes.
• Is there a risk of losing my bitcoins? No.
• Can I use bitcoin as I used to? Yes, except with non-upgraded wallet sometimes you might not see unconfirmed transactions. You will still always see transactions when they have 1 confirmations or more.

[Jack Liver]

sarebbe una grandissima inovazione il segwit aprirebbe ai lightning network ma al contempo provo grande scetticismo nei confronti dell'adozione da parte dei miner/pool sarei contento di essere smentito.

[Sandro kensan]

sarebbe una grandissima inovazione il segwit aprirebbe ai lightning network ma al contempo provo grande scetticismo nei confronti dell'adozione da parte dei miner/pool sarei contento di essere smentito.

Mi pare di avere capito che fin'ora il bitcoin core team è stato quello che ha determinato tutte le scelte del sistema bitcoin. Per questo viaBTC o come si chiama si oppone a quest'ennesima scelta fatta dai cores in quanto la vedono come una centralizzazione delle decisioni.

[Jack Liver]

c'e anche il peso che hanno i fee per i miner non so se abbiate seguito la piccola crisi che giorni fa si è verificata sul network, potete dare un sguardo allo storico questo link https://www.bitcoinqueue.com/details/all.html il numero di transazioni accumulate nel mempool in attesa di conferma ha superato le 70k.

ciò ha costretto l'utente interessato a un trasferimento rapido ( le canoniche due conferme in meno di un ora ) a pagare un fee più alto rendendo i blocchi molto più convenienti da minare con ben più di 1-1,5BTC di fee oltre ai 12,5BTC di reward.


da questo punto di vista il segwit portando quasi al raddoppio delle dimensioni abbatte di conseguenza anche i fee, già adesso con certi blocchi rendono solo un 0,15-0,50BTC come potete vedere su http://blockr.io/ i lightning network con le transazioni off-chain potrebbero portarli quasi a zero, sarebbe una misura che comprometterebbe la futura rendita delle mining farm.

[arulbero]

Quindi dal 15 novembre partono periodi di 2016 blocchi ciascuno, all'interno di ogni periodo si fa ogni volta una sorta di votazione, se in una di queste votazioni si raggiunge il 95% allora si attiva il soft fork.

Visto che c'è tempo massimo un anno, ci saranno all'incirca 52 settiamane / 2 = 26 periodi diversi di voto oppure la finestra dei 2016 blocchi è "mobile"?

Se al 15 novembre 2017 non si è attivato il soft fork, segwit non potrà più essere riproposto in nessuna forma più avanti? Cioè ogni singola proposta è solo una tantum?

[Sandro kensan]

Quindi dal 15 novembre partono periodi di 2016 blocchi ciascuno, all'interno di ogni periodo si fa ogni volta una sorta di votazione, se in una di queste votazioni si raggiunge il 95% allora si attiva il soft fork.

Visto che c'è tempo massimo un anno, ci saranno all'incirca 52 settiamane / 2 = 26 periodi diversi di voto oppure la finestra dei 2016 blocchi è "mobile"?

Se al 15 novembre 2017 non si è attivato il soft fork, segwit non potrà più essere riproposto in nessuna forma più avanti? Cioè ogni singola proposta è solo una tantum?

Io tiro a indovinare usando un po' di logica ma gli esperti qui dentro diranno la loro in modo appropriato. Credo che i conti si facciano alla fine di ogni blocco, la blockchain è fatta a blocchi e pure il tempo è spezzato sulla base dei blocchi.

Credo che non ci sia nessuna regolamentazione e l'unica regola è il Bitcoin Core version 0.13.1 per cui spero non ci sarà bisogno di arrivare all'anno prossimo ma comunque nulla osta che sia ripresentata (in generale) ma sarebbe di cattivo gusto.

[gbianchi]

Quindi dal 15 novembre partono periodi di 2016 blocchi ciascuno, all'interno di ogni periodo si fa ogni volta una sorta di votazione, se in una di queste votazioni si raggiunge il 95% allora si attiva il soft fork.

Visto che c'è tempo massimo un anno, ci saranno all'incirca 52 settiamane / 2 = 26 periodi diversi di voto oppure la finestra dei 2016 blocchi è "mobile"?

Se al 15 novembre 2017 non si è attivato il soft fork, segwit non potrà più essere riproposto in nessuna forma più avanti? Cioè ogni singola proposta è solo una tantum?

Io tiro a indovinare usando un po' di logica ma gli esperti qui dentro diranno la loro in modo appropriato. Credo che i conti si facciano alla fine di ogni blocco, la blockchain è fatta a blocchi e pure il tempo è spezzato sulla base dei blocchi.

Credo che non ci sia nessuna regolamentazione e l'unica regola è il Bitcoin Core version 0.13.1 per cui spero non ci sarà bisogno di arrivare all'anno prossimo ma comunque nulla osta che sia ripresentata (in generale) ma sarebbe di cattivo gusto.

ricordo inoltre che stiamo parlanda di statistica. se il 10% dei miner si oppone, dal punto di vista statistico ci sono delle buone possibilita' che il softfork passi ugualmente.
ricordo che la generazione e' statistica, quindi la divisioni 90% (favorevoli) 10% (contrari) non e' ferrea.

basta una devianza temporanea dalla media relativamente piccola per far passare il segwit.

si puo' anche fare un calcolo preciso di quante probabilita' ci siano nei vari casi (ad esempio 90%-10%, 85%-15%) ecc..

[Sandro kensan]

ricordo inoltre che stiamo parlanda di statistica. se il 10% dei miner si oppone, dal punto di vista statistico ci sono delle buone possibilita' che il softfork passi ugualmente.
ricordo che la generazione e' statistica, quindi la divisioni 90% (favorevoli) 10% (contrari) non e' ferrea.

basta una devianza temporanea dalla media relativamente piccola per far passare il segwit.

si puo' anche fare un calcolo preciso di quante probabilita' ci siano nei vari casi (ad esempio 90%-10%, 85%-15%) ecc..

Per rafforzare il concetto dico che ho letto che il gruppo di minatori che si oppone (o almeno la leadership dice questo) ha una percentuale tra il 4 e il 15%, quindi basta che durante l'anno cali un po' il suo hash rate e segwit passa.

Non ho capito se la potenza di calcolo di questo gruppo sia in mano a una singola società o se sia un pool di minatori con una società come rappresentante, comunque il gruppo si potrebbe disfare magari magari momentaneamente proprio per fare passare segwit come anche potrebbero arrivare nuovi miners contrari.

Le statistiche del team ViaBTC sono qui elencate:
https://btc.com/stats/pool/ViaBTC

Credo che gli ultimi 10 blocchi minati da ViaBTC siano dal numero:
436'645
al numero:
436'493
che sono un numero di blocchi pari a (faccio la differenza):
152
Quindi un rate pari a (dieci blocchi minati da ViaBTC rispetto a tutti i blocchi minati nello stesso lasso di tempo):
10/152
.0657--> 6.6%

Quindi il Rate è del 6.6% in questo momento (ultime 21.5 ore) vuol dire che con questi numeri se è seolo ViaBTC ad opporsi quasi sicuramente segwit passerà (e anche in fretta) in quanto necessita del 95% dei blocchi minati che abbiano adottato segwit.

Il test si farà comunque su 2016 blocchi che sono 10-15 volte il test maccheronico che ho fatto io.

Su blockchain.info si hanno dati più precisi:
https://blockchain.info/pools?timespan=4days

Il rate di Via è di 7.5% negli ultimi 4 giorni dove pare ci sia un margine di incertezza solo su 0.5% dei blocchi che vengono taggati come sconosciuti. Inoltre ho letto che Via quando ha adottato un altro protocollo (Bitcoin Unlimited) che porta a un hard fork ha diminuito il numero di blocchi minati del 50% pare per via della defezione di membri del pool che non ci sono più stati, comunque è una notizia non confermata.

[gbianchi]

Per rafforzare il concetto dico che ho letto che il gruppo di minatori che si oppone (o almeno la leadership dice questo) ha una percentuale tra il 4 e il 15%, quindi basta che durante l'anno cali un po' il suo hash rate e segwit passa.

Non ho capito se la potenza di calcolo di questo gruppo sia in mano a una singola società o se sia un pool di minatori con una società come rappresentante, comunque il gruppo si potrebbe disfare magari magari momentaneamente proprio per fare passare segwit come anche potrebbero arrivare nuovi miners contrari.

Le statistiche del team ViaBTC sono qui elencate:
https://btc.com/stats/pool/ViaBTC

Credo che gli ultimi 10 blocchi minati da ViaBTC siano dal numero:
436'645
al numero:
436'493
che sono un numero di blocchi pari a (faccio la differenza):
152
Quindi un rate pari a (dieci blocchi minati da ViaBTC rispetto a tutti i blocchi minati nello stesso lasso di tempo):
10/152
.0657--> 6.6%

Quindi il Rate è del 6.6% in questo momento (ultime 21.5 ore) vuol dire che con questi numeri se è seolo ViaBTC ad opporsi quasi sicuramente segwit passerà (e anche in fretta) in quanto necessita del 95% dei blocchi minati che abbiano adottato segwit.

Il test si farà comunque su 2016 blocchi che sono 10-15 volte il test maccheronico che ho fatto io.

Su blockchain.info si hanno dati più precisi:
https://blockchain.info/pools?timespan=4days

Il rate di Via è di 7.5% negli ultimi 4 giorni dove pare ci sia un margine di incertezza solo su 0.5% dei blocchi che vengono taggati come sconosciuti. Inoltre ho letto che Via quando ha adottato un altro protocollo (Bitcoin Unlimited) che porta a un hard fork ha diminuito il numero di blocchi minati del 50% pare per via della defezione di membri del pool che non ci sono più stati, comunque è una notizia non confermata.

si infatti supponiamo (ovviamente non e' cosi' ma e' per semplificare il ragionamento)
che l'hash-power sia costante e i due gruppi abbiano esattamente io 90% e il 10% del'hash-power.

se tu vai a fare le rilevazioni statistiche che stai facendo sui blocchi prodotti,
risultera' a volte che ci sia un 7% vs 93% di blocchi minati, a volte un 11% vs un 89% ecc.
Solo la media della produzione dei blocchi di lungo periodo tendera' a 10% - 90%

Tutto cio' rientra nella normale varianza statistica

Ovviamente il primo assunto non e' vero, quindi anche le proporzioni di hash power
variano, avendo come effetto di incidere ulteriormente nella percentuale dei
blocchi minati da ciascun gruppo.

In pratica in ogni momento noi non abbiamo la proprorzione precisa degli hash-power,
ma solo la loro misura indiretta (e a volte anche molto errata) ricavata da statistiche
sui blocchi minati !

[Sandro kensan]

Tutto cio' rientra nella normale varianza statistica

Teoria della probabilità o comunque nozioni base del corso di statistica

[bittaitaliana]

premetto che quando usate certi paroloni non capisco una randa (quindi ho capito il 10% del thread) ma mik chiedo, perchè fare i blocchi solo da 2 mb? Che senso ha fare un fork e raddoppiare solo ? tempo xx mesi e ci troviamo di nuovo con i blocchi saturi

[gbianchi]

premetto che quando usate certi paroloni non capisco una randa (quindi ho capito il 10% del thread) ma mik chiedo, perchè fare i blocchi solo da 2 mb? Che senso ha fare un fork e raddoppiare solo ? tempo xx mesi e ci troviamo di nuovo con i blocchi saturi

cazzo bitta ne parliamo tutti da mesi e mesi

comunque con questo soft fork non modificano davvero la dimensione del blocco,
ma ci mettono meno roba dentro, in modo che in un blocco da 1 mega (quindi resta uguale)
diventa equivalente a un blocco di circa 1.6 mega di adesso(circa!!!)

Per fare questo non serve un hard fork.

[gbianchi]

io ho messo il mio full node in 0.13.1

non servira' a un cazzo, ma chissa'.

[bittaitaliana]

premetto che quando usate certi paroloni non capisco una randa (quindi ho capito il 10% del thread) ma mik chiedo, perchè fare i blocchi solo da 2 mb? Che senso ha fare un fork e raddoppiare solo ? tempo xx mesi e ci troviamo di nuovo con i blocchi saturi

cazzo bitta ne parliamo tutti da mesi e mesi

comunque con questo soft fork non modificano davvero la dimensione del blocco,
ma ci mettono meno roba dentro, in modo che in un blocco da 1 mega (quindi resta uguale)
diventa equivalente a un blocco di circa 1.6 mega di adesso(circa!!!)

Per fare questo non serve un hard fork.

si, ma quando parlate voi, a me serve un traduttore, ogni 5 parole devo andare a vedere su google il significato 
non ti incazzare, ma spiegami anche sta cosa, quindi si continua ad utilizzare un solo bitcoin ? Nel senso, io avevo capito che con un hard fork ci sarebbero state due chanin diverse, quindi il btc rimaneva una cosa, il nuovo con blocchi più grandi altra cosa, con altro nome (come nel caso di ETH e ETC), con il soft fork cosa cambia?

[Sandro kensan]

si, ma quando parlate voi, a me serve un traduttore, ogni 5 parole devo andare a vedere su google il significato 
non ti incazzare, ma spiegami anche sta cosa, quindi si continua ad utilizzare un solo bitcoin ? Nel senso, io avevo capito che con un hard fork ci sarebbero state due chanin diverse, quindi il btc rimaneva una cosa, il nuovo con blocchi più grandi altra cosa, con altro nome (come nel caso di ETH e ETC), con il soft fork cosa cambia?

Bianchi è più bravo di me e ti spiegherà meglio. Intanto quel che ho capito io è che nel soft fork non si dividono le blockchain in due (quindi niente ETH e ETC), si aspetta che il 95% dei minatori siano d'accordo e poi si fa lo switch.

Poi con i blocchi che possono essere dal 60% al 100% più grandi significa che non ci sarà più da aspettare perché la nostra transazione abbia una conferma e questo per diverso tempo a venire.

E poi?

Poi ci sono molte idee che sono state discusse a Milano nella conferenza sui bitcoin che si possono realizzare quando questo softfork sarà attivo. L'idea è quella di una seconda rete sopra questa attuale dei bitcoin che porterebbe a risolvere (così ho letto ma sono completamente all'oscuro) il problema del block size. Si parla di una blockchain parallela dove scaricare i Megabyte che non ci stanno in quella attuale o di altri metodi per ridurre il peso della blockchain. Insomma pare che non sarà un problema. Le idee che hanno sono tante e pare che possano coesistere ed esserci vari (?) secondi layer (ma ho ben capito?).

[Jack Liver]

a questo link https://coin.dance/blocks potrete monitorare il numero di blocchi emessi con il supporto al segwit per ora è al 13.30%

[arulbero]

si, ma quando parlate voi, a me serve un traduttore, ogni 5 parole devo andare a vedere su google il significato  
non ti incazzare, ma spiegami anche sta cosa, quindi si continua ad utilizzare un solo bitcoin ? Nel senso, io avevo
capito che con un hard fork ci sarebbero state due chanin diverse, quindi il btc rimaneva una cosa, il nuovo con
blocchi più grandi altra cosa, con altro nome (come nel caso di ETH e ETC), con il soft fork cosa cambia?

Provo un po' a semplificare riassumendo quello che ho capito io.

Premessa:  fork significa innanzitutto "divisione a causa del cambio di una regola nel protocollo bitcoin ", la questione è capire di che tipo di divisione si tratta

La differenza tra hard fork e soft fork si può sintetizzare nella seguente espressione:

Soft forks make previously valid (or non standard***) things invalid, hard forks make previously invalid things valid.

I soft fork rendono non valide situazioni valide (o non standard) in precedenza, gli hard fork rendono valide cose che prima non erano valide.


Esempio:

soft fork:
se diminuissimo la dimensione dei blocchi a mezzo mega, questo sarebbe un soft fork, in quanto non sarebbe più possibile minare un blocco da 1 mega come si faceva in precedenza;  in questo caso si passerebbe da una regola più permissiva (blocchi fino a 1 mega) a una meno permissiva (blocchi fino a 1/2 mega) --> si rendono non valide situazioni che prima erano consentite (ad esempio la generazione di un blocco da 750 kb)

NB: si parla di soft fork poichè la divisione si crea soltanto a livello software, divisione tra chi ha software aggiornato e chi invece mantiene il software pre-fork (ma non avviene alcuna divisione della blockchain)

                                      soft fork : vecchi client - nuovi client

chi mantiene un client vecchio (pre-soft fork, tipo Core 0.12.0 invece di Core 0.13.1 ad esempio) non si accorge nemmeno del cambio di regole; infatti se il vecchio client supporta e riconosce blocchi fino a 1 mega mentre i miner minano blocchi solo fino a 1/2 mega, questi nuovi blocchi (nuovi nel senso minati con le nuove regole) sono perfettamente validi anche agli occhi dei nuovi client, poichè se accetti un blocco fino a 1 mega a maggior ragione consideri valido un blocco da 200kb; se con il vecchio client provi a minare dei nuovi blocchi, quando ti capita di minare un blocco minore di 1/2 mega questo verrà accettato dal resto della rete, quando mini un blocco da 750 kb inspiegabilmente la rete lo rifiuterà

chi ha un client aggiornato semplicemente evita di minare un blocco maggiore di 1/2 mega, e considera non valido un blocco da 750kb se gli arriva poichè conosce esplicitamente la nuova regola (ovviamente continua a considerare sempre validi tutti i blocchi pre-fork, le regole non si cambiano a posteriori).


                                              
                                     hard fork:  la blockchain si divide in 2 rami diversi
 
se aumentassimo invece la dimensione dei blocchi a due mega, questo sarebbe un hard fork, in quanto avremmo una situazione fino ad ora non valida (blocchi fino a due mega) che d'ora in poi diventa consentita.

Qual è il problema dell'hard fork? A differenza del soft fork, dove uno può decidere di mantenere il vecchio client senza apprezzabili controindicazioni, con un hard fork non è più possibile mantenere il vecchio client senza conseguenze, poichè questo ha delle regole di funzionamento più restrittive rispetto alle nuove; dopo il primo blocco minato maggiore di 1 mega, si creerebbe una suddivisione della blockchain (hard fork), in quanto i nuovi client e i vecchi client lavorerebbero con regole incompatibili. Di fatto si creano due rami, due set di regole diverse cioè due monete diverse da una.  

L'idea di base del soft fork invece è quella di nascondere le modifiche ai vecchi client, in modo che questi vecchi programmi siano in grado di leggere ancora i nuovi dati (blocchi) senza neanche accorgersi delle modifiche;


Azzardo un paragone informatico:

BitCoin Core   --  Word

blocchi        --  documenti

se si immagina Bitcoin Core come fosse Word, un hard fork consiste nel creare una nuova versione del programma che realizza documenti in un formato illeggibile dalla versione precedente (di fatto si hanno due tipi di documenti, ad  esempio .doc e .docx <---hard fork);
un soft fork invece consiste nel creare una nuova versione del programma che realizza documenti leggibili anche dalla versione precedente (quindi stesso formato) ma con qualche caratteristica/tag in più che può essere sfruttata a dovere solo dal nuovo software ma non pregiudica l'utilizzo da parte di quello vecchio. In questo caso non ci sono due formati di documenti (no hard fork), ma semplicemente due versioni di programma che creano e leggono lo stesso formato di documento (soft fork).


                                     il soft fork di Segregated Witness (segwit)

Cosa succederà (se succederà) con il soft fork di segwit? I blocchi saranno sempre di 1 mega* (*solo per le vecchie versioni di Core per retrocompatibilità) ma si usa un "trucco" per inserire delle transazioni apparentemente "alleggerite" (con una parte di byte - la firma "witness" - "segregata" che viene allocata "altrove", cioè in un nuovo campo separato della transazione). Si tratta di un trucco poichè i vecchi client non capiranno esattamente che c'è solo una parte della transazione e non tutta (loro non scaricano quel campo nuovo, il nuovo "tag" delle transazioni witness) e soprattutto poichè la reale dimensione dei blocchi aumenterà per i nuovi client, anche se essa verrà calcolata in un nuovo modo; questo fatto ha contribuito a suscitare molte polemiche, si tratta infatti di un soft fork che si propone di realizzare qualcosa che dovrebbe poter essere fatto in teoria solo con un hard fork, e cioè rendere valide situazioni - come i blocchi più grandi - in precedenza non permesse. Si riesce a fare ciò poichè una parte delle transazioni - le firme segregate - non viene considerata più come il resto delle transazioni, e il loro peso in byte viene scontato del 100% per i vecchi client, che neanche le scaricano, e del 75% per i nuovi client, per i quali alla fine il conto virtuale rimane di 1 mega a blocco, ma si tratta appunto solo di un calcolo virtuale.  


Più tecnicamente il nuovo tipo di transazioni appariranno, almeno ai vecchi nodi, transazioni del tipo "ANYONE CAN SPEND"; infatti i vecchi nodi non riusciranno più a interpretare i nuovi comandi che vincolano i bitcoin nel campo scriptPubKeys e di conseguenza questi btc appariranno a loro non vincolati a nessun indirizzo; questo fatto si rende necessario poichè questi vecchi nodi dovranno accettare e considerare valide anche le nuove transazioni (presenti nei blocchi futuri della blockchain) che poi spenderanno questi bitcoin, e poichè essi non saranno più in grado di vedere le firme segregate in un altro campo, l'unico modo affinchè possano considerare regolare (anche se non standard) una transazione che spenda questi bitcoin consiste nel non considerarli vincolati affatto (cioè nel considerarli già svincolati in partenza quindi):

from the perspective of Bitcoin nodes that don't use Segregated Witness (lets call them “old nodes”), some newly created outputs might soon use a strange type of scriptPubKeys. Strange, because these scriptPubKeys can hardly be considered a lock at all. Commonly referred to as an “Anyone can spend,” these scriptPubKeys basically proclaim they don't require a signature. Additionally, they will include some meaningless text(questa è la "nuova" feature incomprensibile ai vecchi nodi).

Old nodes will consider these transactions crazy. They will think that anyone can create a new scriptSig, unlocking these outputs, meaning they're highly insecure. But at the same time, old nodes won't mind either. After all, it's not their bitcoin that's being messed around with, and other people are free to do with their bitcoin as they please. The meaningless text will be considered weird, but fine too. So they'll confirm the transactions as valid.

both old nodes and new nodes will consider transactions containing signatures in the Segregated Witness valid. Old nodes validate them because from their perspective these transactions don't require a signature at all (and they don't see one), and new nodes validate them because the required signature is in the Segregated Witness.


However, Segregated Witness-enabled nodes (lets call them “new nodes”) will notice something else. They will see the otherwise meaningless text in the scriptPubKey, but not consider it meaningless at all. Instead, new nodes will recognize this piece of text as another – very special – type of output.

Much like typical outputs, this new type of output will require one or several signatures to unlock the bitcoin. But unlike typical outputs, this new type of output will not require the signature to be included in the scriptSig of a subsequent transaction. Instead, it will require the signature to be included in a completely new part of the transaction: the Segregated Witness.

This Segregated Witness is basically an “add-on” that carries signatures and some additional data. Importantly, Segregated Witnesses are completely ignored by old nodes, but recognized by new nodes.

Per essere pignoli cosa succederà a chi non aggiornerà il suo wallet/client? Quando questi dovesse ricevere una transazione  del nuovo tipo (diciamo "alleggerita") il suo vecchio client la etichetterà come 'non standard' (le transazioni*** possono essere valide, non valide, non standard; non standard significa: non capisco bene cosa sia anche se non viola nessuna regola da me conosciuta). Poichè le transazioni non standard non possono essere create nè inoltrate, di fatto il suo client non la accetterà quando la vedrà per la prima volta nello stato di transazione non confermata, mentre quando la rivedrà all'interno di un blocco minato le accetterà (così funzionano le transazioni non standard, non si facilita il loro uso ma neanche si rifiutano in toto).

Quindi chi non aggiorna non vedrà subito (dal suo client) la transazione non confermata ma dovrà
aspettare che questa abbia almento una conferma (sia inclusa in un blocco) per vederla apparire nel suo programma.

fonti:
https://bitcoincore.org/en/2016/01/26/segwit-benefits/
https://bitcoinmagazine.com/articles/segregated-witness-officially-introduced-with-release-of-bitcoin-core-1477611260


***

There are more than two possible states, invalid or valid. Transactions can also be 'non-standard' meaning nodes will not create, relay, or mine them. But if they happen to (somehow) show up in a block, they'll accept them.  In effect, a non-standard transaction is one doing something that a node knows it doesn't fully understand, but still doesn't break the rules... so it won't facilitate it but it also won't reject it.

The community developed softforks in modern times take the form of only making things invalid which were already non-standard. So no transactions by users who do not upgrade will be made invalid.

EDIT: se vi serve solo sapere come comportarvi in questo soft fork e come/quando aggiornare (sia che siate un miner, un full node, o un semplice utente) queste sono le istruzioni: https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/

[bittaitaliana]

Arulbero non ho capito se hai scritto tu quel msg oppure se lo hai tradotto dal sito indicato sotto , ma comunque sia ti ringrazio se lo hai trdotto, ma se lo hai scritto tu dovresti metterti a scrivere libri sul bitcoin per principianti, perchè finalmente ho capito tutto 

[picchio]

Dove vengono memorizzate le informazioni che non compaiono in blockchain legate al segwit?

[arulbero]

Arulbero non ho capito se hai scritto tu quel msg oppure se lo hai tradotto dal sito indicato sotto , ma comunque sia ti ringrazio se lo hai trdotto, ma se lo hai scritto tu dovresti metterti a scrivere libri sul bitcoin per principianti, perchè finalmente ho capito tutto  

Ho preso alcune cose dai link indicati e poi ho rielaborato, se hai capito lo scopo è stato raggiunto. D'altronde per deformazione professionale tendo a rielaborare i concetti, semplificarli e spiegarli a qualcuno per capire meglio anch'io (così fanno di solito quelli che fanno il mio mestiere )

Dove vengono memorizzate le informazioni che non compaiono in blockchain legate al segwit?

Bisogna scendere proprio nei dettagli dell'implementazione del BIP 141/142 e nel come è fatta una transazione.

Ogni transazione contiene due componenti principali.
La prima sblocca i bitcoin che erano vincolati in transazioni precedenti (UTXO : Unspent Transaction Output), e per fare questo si usano dei dati detti "input".  Gli input includono uno o più script, cioè delle istruzioni su come sbloccare gli UTXO, questi script si chiamano "scriptSig".
L'altra parte della transazione consiste in uno o più nuovi "lucchetti" detti output, i quali ribloccano la stessa quantità (o meno) di bitcoin; gli output includono script detti "scriptPubKeys".

Le istruzioni per sbloccare i bitcoin lavorano su una firma e sulla chiave pubblica relativi all'indirizzo mittente,
le istruzioni sul blocco dei bitcoin (i lucchetti) vincolano i bitcoin all'indirizzo del destinatario.
In questo modo i bitcoin effettivamente si muovono dagli input agli output all'interno di una singola transazione (vengono svincolati e rivincolati allo stesso tempo), e così "passano" istantaneamente da una transazione all'altra (e da un address all'altro, cioè da un vincolo a un altro).

Che differenza c'è tra una transazione normale e una transazione segwit?

In sostanza si operano  due cambiamenti nella transazione.

1) la firma (con la chiave pubblica del mittente) viene spostata dal campo "scriptSig" a un nuovo campo "witness" (che è sempre un campo della transazione!); questo vuol dire "segregated witness", firma separata (segregata in un campo della transazione che non verrà incluso nell'hash della transazione, cioè non impatterà sulla txid)

2) il testo del campo "scriptPubKey" viene modificato in modo che abbia due significati diversi per un vecchio nodo e per un nuovo nodo (ecco il soft fork!); NB: in quel campo rimane sempre la condizione che blocca i bitcoin (i bitcoin vengono bloccati con l'indirizzo del ricevente, ovvero i fondi vengono vincolati alla chiave pubblica che genera l'indirizzo del ricevente);
in questo caso la condizione di blocco diventa per il vecchio nodo un "non vincolo", cioè un generico "ANYONE CAN SPEND" (un output solo apparentemente non vincolato a nessun indirizzo e quindi spendibile da chiunque) poichè il vecchio nodo non legge i nuovi indirizzi/script "pay-to-witness-public-key-hash" P2WPKH (per ulteriori dettagli vedi in fondo al post ***), mentre per i nuovi nodi che conoscono i nuovi indirizzi e il nuovo modo di interpretare quei dati si tratta sempre di una transazione che manda dei bitcoin a un indirizzo preciso

Standard Transaction to Bitcoin address (pay-to-pubkey-hash) P2PKH

scriptSig: <sig> <pubKey>
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Witness Transaction (pay-to-witness-public-key-hash) P2WPKH

The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):

    witness:      <signature> <pubkey>   <-- in questo campo vengono trasferiti la firma e la chiave pubblica  del mittente
    scriptSig:    (empty)                           <-- questo campo viene svuotato della firma e della chiave pubblica del mittente
    scriptPubKey: 0 <20-byte-key-hash>          <-- il significato di questo campo viene spiegato in fondo al post
                  (0x0014{20-byte-key-hash})

The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program.

The signature is verified as

    <signature> <pubkey> CHECKSIG

Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness.

I vecchi client non vedono proprio il nuovo campo "witness" (essi scaricano i blocchi depurati dal campo "witness"), i nuovi sì. Quando si fa l'hash della transazione però per creare il suo ID (txid), il campo "witness" non viene incluso (questo fatto sistema la questione della malleabilità).

Quindi nella blockchain quel campo (la firma) in realtà c'è (anche se un nodo a cui non interessa fare una validazione completa può fare il pruning di quel campo), sicuramente non c'è però (non viene considerata) nell'hash della transazione (txid).
Quest'ultimo fatto di per sè renderebbe la parte "witness" l'unica parte della blockchain potenzialmente modificabile, in quanto svincolata dalla txid e di conseguenza dall'hash del blocco che a sua volta dipende dall'hash delle transazioni che contiene; per ovviare a questo fatto viene costruito un altro Merkle Tree e di conseguenza ricavato un Merkle Root relativo solo ai campi "witness" di tutte le transazioni del blocco, e quest'ultimo dato viene infine inserito nel campo di input della coinbase del blocco (in questo modo cambia l'ID solo di quella transazione ma questo è sufficiente per modificare l'hash del blocco,  di conseguenza la presenza di ogni campo witness del blocco viene fissata per sempre anche nell'hash del blocco stesso, ma ripeto non nell'hash della transazione.)

In sostanza le firme vengono collegate (dal punto di vista della verifica della consistenza della blockchain) per sempre al blocco tramite il suo hash, mentre rimangono scollegate dalla txid della transazione a cui appartengono, e questo porta diversi vantaggi dal punto di vista tecnico (ad esempio finora per ricostruire il database degli UTXO bisogna identificare gli input delle transazioni facendo riferimento a una txid che dipende a sua volta dalla firma, ma la firma dovrebbe servire solo ad autorizzare una transazione, non a identificarla!  Con le transazioni witness la firma manterrà solo la sua funzione specifica e non creerà ulteriore lavoro inutile per identificare gli input).

Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.
Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.

Quale sarà allora la dimensione di ogni blocco?

Esso potrà contenere delle transazioni purchè sia rispettata questa disequazione:

lo spazio occupato dalla parte "standard" delle transazioni (senza contare il campo witness) + 1/4 dello spazio occupato dal campo witness delle stesse transazioni <= 1 Mega

Since old nodes will only download the witness-stripped block, they only enforce the 1 MB block size limit rule on that data. New nodes, which understand the full block with witness data, are therefore free to replace this limit with a new one, allowing for larger block sizes. Segregated witness therefore takes advantage of this opportunity to raise the block size limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).

In questo modo quindi la dimensione del blocco può (e lo farà) superare tranquillamente 1 Mega per i nuovi client (si stima possa arrivare a 1,5/2 Mega effettivi?) mentre i vecchi nodi scaricheranno sempre meno di 1 Mega (poichè essi non vedono il "witness").
Il fatto di considerare solo 1/4 del peso del witness (cioè delle firme) mira a favorire l'uso del sigwit, pochè esso porta molti vantaggi (ad esempio il fatto che la ID di una transazione non dipenda più da "scriptSig" rende più facile ricostruire l'insieme degli UTXO mentre finora bisognava scaricare anche le firme solo per ricostruire le txid; l'elenco completo dei vari vantaggi si trova qui https://bitcoincore.org/en/2016/01/26/segwit-benefits/)

The Unspent Transaction Output (UTXO) database is maintained by each validating Bitcoin node in order to determine whether new transactions are valid or fraudulent. For efficient operation of the network, this database needs to be very quick to query and modify, and should ideally be able to fit in main memory (RAM), so keeping the database’s size in bytes as small as possible is valuable.
Segwit improves the situation here by making signature data, which does not impact the UTXO set size, cost 75% less than data that does impact the UTXO set size. This is expected to encourage users to favour the use of transactions that minimise impact on the UTXO set in order to minimise fees, and to encourage developers to design smart contracts and new features in a way that will also minimise the impact on the UTXO set.
Because segwit is a soft-forking change and does not increase the base blocksize, the worst case growth rate of the UTXO set stays the same.

In futuro quindi potremo finalmente liberarci di giga di firme non più necessarie (solo quelle nel campo witness però! non quelle tradizionali che sono legate alle txid e quindi sono necessarie per ricostruire il database degli UTXO), come afferma lo stesso Pieter Wuille, il promotore di questo soft fork:

We all know how bitcoin transactions work. Every bitcoin transaction gets inputs, which refer to previous outputs being spent. Every input has the txid and the signature to prove that it is allowed, plus an amount and script in every output. What this presentation will mostly be about is the question of whether all of this data is equally important.

In particular, we are going to be talking about signatures. It's important to realize here that signatures are really only needed for fully-validating nodes. As a light-weight client, you are not validating signatures, even though they are part of the transactions you still have to download them. If you are using a full-node that is syncing historical data, you don't actually validate all of the signatures in there. Currently there is a mechanism in there using checkpoints, which we want to deprecate soon, but the result will still be that we're not validating all signatures from years ago in deep history.

These signatures are only needed at time of validation. They don't go into the UTXO set, the database of all unspent coins. These unspent transaction outputs don't enter into the UTXO set. This is a significant cost on the resources of both keeping a node running but also the speed of propagation and access to the UTXO set needs to be fast. Of all the data in a transaction, signatures don't go into the UTXO set, even though they account for 60% of the blockchain data. Segregated witness is about ignoring this whenever possible.

Where does the name witness come from? For now, it's motsly a word to refer to the scriptSig in inputs or signatures inside transactions. Later I will extend this meaning. The reason for this name is because signatures are not part of the transaction. They don't describe what the transaction is doing. The only thing they are doing is proving that the transaction is authorized by the previous owners of the coins. There are usually multiple possible valid signature for the same transaction. We don't really care what the signature is, all we care about is that at least one signature for that existed. Such an example of where something exists is known as a witness.

Wouldn't it be nice to just drop the signatures? The reason why we can't do this is because the signature is part of the transaction hash. If we would just drop the sig from the transaction, the block wouldn't validate, you wouldn't be able to prove an output spend came from that transaction, so that's not something we could do. But let's simplify the problem. What if we could redesign Bitcoin from scratch? What if you're designing an altcoin, there's really no reason why you would want to do this in Bitcoin. This is actually something we did in sidechain alpha.

You would mark the signature data as special. You are indicated by green color on this slide. Everything but the green part goes into the hash of a transaction. The signature doesn't. It's just a piece of data that's still there, but we don't consider it part of the transaction.

What are the advantages of this? It allows you to drop the signatures from relay whenever you are relaying to a node that is not actually doing full-validation at the time. It also allows us to effectively prune this data from history, maybe we're fine with not all nodes in the network actually maintaining these gigabytes of signatures that are buried under years of proof-of-work now.

fonti:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618
https://bitcoinmagazine.com/articles/segregated-witness-part-why-you-should-care-about-a-nitty-gritty-technical-trick-1450827675
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Examples
https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki



***

Example

The following public key,
    0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A 299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
 
when encoded as a P2PKH template, would become:   <--  normale transazione

    scriptPubKey:  DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG

With the corresponding version 1 Bitcoin address being:

    16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM    
 


When the same public key is encoded as P2WPKH, the scriptPubKey becomes:  <--   transazione con firma separata (segwit)

      scriptPubKey: OP_0 <010966776006953D5567439E5E39F86A0D273BEE>    

Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:

   p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm

scriptPubKey: OP_0 <010966776006953D5567439E5E39F86A0D273BEE>  

scriptPubKey: 0 <20-byte-key-hash>
                  (0x0014{20-byte-key-hash})

It's a data push that contains the witness program hash, prepended by OP_0.

Old nodes will evaluate this as a script that just pushes two data items onto the stack (a 0 and a hash). That's obviously spendable by all, as the requirement is having a non-zero item as last element on the stack.

The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items