Scaling Bitcoin

[gbianchi]

La notizia gira un po' dovunque da giorni, comunque per chi non lo sapesse,
e' in corso "Scaling Bitcoin"  una conferenza alla quale partecipano dev, miners
e gente del mondo bitcoin.

L'argomento e' discutere (e spero decidere) in merito alla strada migliore
per far scalare bitcoin per poter gestire gli ordini di grandezza
necessari in futuro.

http://www.coindesk.com/hard-fork-developers-scaling-bitcoin/

[Scaccomatt0]

vi consiglio di dare un'occhiata alle presentazioni che trovate qui
https://scalingbitcoin.org/hongkong2015/#presentations

o il video della conferenza:
https://www.youtube.com/watch?v=fst1IK_mrng

[Sampey]

Tra un poco si mettevano le mani addosso

https://www.youtube.com/watch?v=F41670Wx9Vk

[gbianchi]

non riesco a decidermi se e' una figata o una super pezza (anche se propendo piu' per la seconda ....)

The segregated witness solution

Segregated witness is perhaps best described as a novel workaround to the block size issue that affects how certain network variables are counted toward block size.

In bitcoin, transactions include one or more input fields showing where the funds come from, one or more output fields indicating where they’re going and a signature that validates that the owner had the ability to execute the transaction.

"Now signatures go into the 'from' field," Lightning Network developer Tadge Dryja explained. "[In segregated witness] the signature is separate."

More specifically, segregated witness takes the signature out of the transaction and puts the data into a Merkle tree in the coinbase component of the transaction, or the input of a generated transaction. This change would make transactions appear smaller to current nodes on the network, so that more could be included in a bitcoin block, even if blocks are still limited to 1MB by protocol rules.

“If the signatures would add 0.75MB [of capacity] to a block to a 1MB block, it would now be equivalent to 4MB,” developer Doug Roark said, echoing the description put forth by Maxwell and Wuille.

Dryja noted that a soft fork would mean parties running older versions of Bitcoin Core could still use bitcoin, even if it would appear to them as if users were sending money without signatures.

“Nodes today only see the transaction Merkle root and the transaction data, which today includes the signature,” David Vorick, CEO of distributed storage startup Nebulous, explained. “If segregated witness were to be implemented, today’s nodes would not see the transaction signature data, because it would be in a storage area that they don’t recognize.”

Older nodes that have not updated their software would still however be able to monitor the network, though it would appear as if certain parties are behaving abnormally.

"[In a soft fork] nothing changes, my coins are still the same, which is different than everyone must upgrade their software or it stops working," Dryja said. "Things start looking really weird, but they can ignore these transactions."

[picchio]

non riesco a decidermi se e' una figata o una super pezza (anche se propendo piu' per la seconda ....)

The segregated witness solution

Segregated witness is perhaps best described as a novel workaround to the block size issue that affects how certain network variables are counted toward block size.

In bitcoin, transactions include one or more input fields showing where the funds come from, one or more output fields indicating where they’re going and a signature that validates that the owner had the ability to execute the transaction.

"Now signatures go into the 'from' field," Lightning Network developer Tadge Dryja explained. "[In segregated witness] the signature is separate."

More specifically, segregated witness takes the signature out of the transaction and puts the data into a Merkle tree in the coinbase component of the transaction, or the input of a generated transaction. This change would make transactions appear smaller to current nodes on the network, so that more could be included in a bitcoin block, even if blocks are still limited to 1MB by protocol rules.

“If the signatures would add 0.75MB [of capacity] to a block to a 1MB block, it would now be equivalent to 4MB,” developer Doug Roark said, echoing the description put forth by Maxwell and Wuille.

Dryja noted that a soft fork would mean parties running older versions of Bitcoin Core could still use bitcoin, even if it would appear to them as if users were sending money without signatures.

“Nodes today only see the transaction Merkle root and the transaction data, which today includes the signature,” David Vorick, CEO of distributed storage startup Nebulous, explained. “If segregated witness were to be implemented, today’s nodes would not see the transaction signature data, because it would be in a storage area that they don’t recognize.”

Older nodes that have not updated their software would still however be able to monitor the network, though it would appear as if certain parties are behaving abnormally.

"[In a soft fork] nothing changes, my coins are still the same, which is different than everyone must upgrade their software or it stops working," Dryja said. "Things start looking really weird, but they can ignore these transactions."

Io ho capito che il blocco rimane di 1MByte ma uno stratagemma sulle firme delle transizioni lo rendono equivalente ad un blocco da 4MByte, chi sa spiegare meglio la cosa?

[gbianchi]

non riesco a decidermi se e' una figata o una super pezza (anche se propendo piu' per la seconda ....)

The segregated witness solution

Segregated witness is perhaps best described as a novel workaround to the block size issue that affects how certain network variables are counted toward block size.

In bitcoin, transactions include one or more input fields showing where the funds come from, one or more output fields indicating where they’re going and a signature that validates that the owner had the ability to execute the transaction.

"Now signatures go into the 'from' field," Lightning Network developer Tadge Dryja explained. "[In segregated witness] the signature is separate."

More specifically, segregated witness takes the signature out of the transaction and puts the data into a Merkle tree in the coinbase component of the transaction, or the input of a generated transaction. This change would make transactions appear smaller to current nodes on the network, so that more could be included in a bitcoin block, even if blocks are still limited to 1MB by protocol rules.

“If the signatures would add 0.75MB [of capacity] to a block to a 1MB block, it would now be equivalent to 4MB,” developer Doug Roark said, echoing the description put forth by Maxwell and Wuille.

Dryja noted that a soft fork would mean parties running older versions of Bitcoin Core could still use bitcoin, even if it would appear to them as if users were sending money without signatures.

“Nodes today only see the transaction Merkle root and the transaction data, which today includes the signature,” David Vorick, CEO of distributed storage startup Nebulous, explained. “If segregated witness were to be implemented, today’s nodes would not see the transaction signature data, because it would be in a storage area that they don’t recognize.”

Older nodes that have not updated their software would still however be able to monitor the network, though it would appear as if certain parties are behaving abnormally.

"[In a soft fork] nothing changes, my coins are still the same, which is different than everyone must upgrade their software or it stops working," Dryja said. "Things start looking really weird, but they can ignore these transactions."

Io ho capito che il blocco rimane di 1MByte ma uno stratagemma sulle firme delle transizioni lo rendono equivalente ad un blocco da 4MByte, chi sa spiegare meglio la cosa?

da quel che ho capito, cercando di interpretare piu' a basso livello, vogliono lasciare la parte di transazioni "output" come sono,
ma spostare la "input" (o un sottoinsieme) da qualche altra parte.... in modo che non vengano conteggiate nel famoso mega di spazio.

negli input ci sono tutte le firme e le chiavi pubbliche ... effettivamente sono dati che occupano parecchio spazio in percentuale, penso sia un 70% medio del "peso" della transazione.
ma non ho capito bene che genere di meccanismo vorrebbero fare.... forse un altro albero parallelo...

probabilmente si complichera' l'architettura di  indicizzazione per mantenere una blockchain completa.... boh.
EDIT: Intendo su un client tipo core o in genere su un applicativo che ha necessita di una full blockcahin.

[acquafredda]

Tra un poco si mettevano le mani addosso

https://www.youtube.com/watch?v=F41670Wx9Vk

Quel Roger Ver ha una faccia da schiaffi di dimensioni notevoli e devo essere sincero mi ha disgustato il suo modo di ragionare. Un bulletto sfrontato come ce ne sono tanti. E non mi interessa abbia investito in diverse compagnie del mondo bitcoin

[Anon39]

Tra un poco si mettevano le mani addosso

https://www.youtube.com/watch?v=F41670Wx9Vk

Quel Roger Ver ha una faccia da schiaffi di dimensioni notevoli e devo essere sincero mi ha disgustato il suo modo di ragionare. Un bulletto sfrontato come ce ne sono tanti. E non mi interessa abbia investito in diverse compagnie del mondo bitcoin

quando parli con qualcuno che ti ha derubato non penso sia facile mantenere un tono elegante 

[Sampey]

Qualcuno che mastica bene l'inglese e spiega di cosa stanno discutendo, escluso il fatto che il Ver si lamenta che l'altro sputa mentre parla 

[acquafredda]

Roger Ver vorrebbe l'ammissione del forging of signatures (la falsificazione delle firme) riguardo bonifici partiti con la sua firma falsa. C'è dietro tutta la storia di un contratto poco chiaro: sembra che OKcoin (Star Xu) abbia cercato di modificare retroattivamente il contratto.

Star Xu non lo capisco bene: c'è troppo brusio e il suo inglese ha un tono troppo basso.

Ripeto: Roger Ver sembra fare la star per farsi il bello davanti al businessman cinese. Non credo sia il modo giusto di risolvere la disputa.

Soprattutto la scenetta in cui fa notare che Xu gli sputtacchi in faccia mentre parla è di pessimo gusto.

[Cryptology]

Qualcuno è riuscito a capire se dal workshop di weekend scorso è venuto fuori qualcosa di concreto?

[gbianchi]

Qualcuno è riuscito a capire se dal workshop di weekend scorso è venuto fuori qualcosa di concreto?

anche gavin andersen dice che l'idea "segregate witness"  e' una figata.

http://gavinandresen.ninja/segregated-witness-is-cool

Vi ricordo che lui e' uno di quelli che propongono (proponevano ?) la soluzione XT.

quindi sembra che si vada verso un accordo.

l'unico problema che solleva Gavin e' che per implementarlo ci vorra' qualche mese,
e nel frattempo stiamo col limite da 1 mega tra i coglioni.

speriamo che la situazione non esploda nel frattempo.

[xeryan]

ci vorrà ancora un bel po' per riempire i blocchi da 1mb, qualche mese si può aspettare

[Sampey]

ci vorrà ancora un bel po' per riempire i blocchi da 1mb, qualche mese si può aspettare

Non saprei,

Dato questo grafico
https://blockchain.info/it/charts/avg-block-size

Dando per buona l'assenza di spam attack, e quindi considerando reale e crescente con questa costanza il valore indicato in questo grafico 
https://blockchain.info/it/charts/n-transactions

Non credo che ci sia così tanto tempo per fare modifiche.
Che poi, paraculatamente parlando, ci mettono poco a rilasciare una versione da 2 MB in attesa che si renda efficace la modifica realmente scalabile (se realtamente scalabile sarà)

[arulbero]

Un altro articolo che spiega il meccanismo:
Parte 1:
https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618

EDIT:

Parte 2:
https://bitcoinmagazine.com/articles/segregated-witness-part-why-you-should-care-about-a-nitty-gritty-technical-trick-1450827675

[gbianchi]

Un altro articolo che spiega il meccanismo:

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618

boh speriamo che ci siano davvero i vantaggi che dicono...
quando facevo il programmatore, questa mi avrebbe puzzato tantissimo da pezza

penso che a livello client andra' fatto un altro DB per indicizzare il nuovo merkle tree,
altre complicazioni, piu' roba che si puo' spaccare o non essere sincronizzata...

sperem

EDIT: o meglio che i vantaggi superino gli svantaggi.

[Sampey]

Ho visto la presentazione e devo ancora togliermi dei dubbi ma fondalmentalmente stiamo parlando di una soluzione che prevede lo split della struttura blockchain.
I Full node avranno 2 chain : una contenente la nuova blockchain delle transazioni e una contenente il rispettivo merkel tree di validazione.
I client chainless (Multibit ad esempio) avranno la parte nettizzata del merkel tree atto alla validazione della transazione.

Si parla anche di una riduzione elevata dello spazio occupato nella chain delle transazioni, col risultato che si potranno mettere transazioni in un blocco da 1 MB come se ne avessimo 4 a disposizione (inteso come blocco "old style").

Per un full node cambia poco sotto l'aspetto non tecnico, è come passare a 4MB per blocco (se si considera la somma delle 2 chain).

[gbianchi]

Ho visto la presentazione e devo ancora togliermi dei dubbi ma fondalmentalmente stiamo parlando di una soluzione che prevede lo split della struttura blockchain.
I Full node avranno 2 chain : una contenente la nuova blockchain delle transazioni e una contenente il rispettivo merkel tree di validazione.
I client chainless (Multibit ad esempio) avranno la parte nettizzata del merkel tree atto alla validazione della transazione.

Si parla anche di una riduzione elevata dello spazio occupato nella chain delle transazioni, col risultato che si potranno mettere transazioni in un blocco da 1 MB come se ne avessimo 4 a disposizione (inteso come blocco "old style").

Per un full node cambia poco sotto l'aspetto non tecnico, è come passare a 4MB per blocco (se si considera la somma delle 2 chain).

si questo l'ho capito, mi preoccupa un po' di piu' come lo implementano in pratica...

non sono in grado di valutare, ma non vorrei che per ottenere il risultato equivalente di fare  blocco di 4 MB
senza dover passare il rischio di un hard-fork, poi complicano notevolmente l'implementazione "pratica"

io mi ricordo che nei programmi, quando il numero di if per gestire casi strani ed eccezioni superava
un certo numero, allora era ora di riprogettare tutto

ma scherzo eh, non so i dettagli.

[arulbero]

Un altro articolo che spiega il meccanismo:

https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618

boh speriamo che ci siano davvero i vantaggi che dicono...
quando facevo il programmatore, questa mi avrebbe puzzato tantissimo da pezza

penso che a livello client andra' fatto un altro DB per indicizzare il nuovo merkle tree,
altre complicazioni, piu' roba che si puo' spaccare o non essere sincronizzata...

sperem

EDIT: o meglio che i vantaggi superino gli svantaggi.

Io non sono mai stato un programmatore e quindi non mi addentro nelle questioni tecniche.
Osservo solo che questo tipo di modifica è una specie di ottimizzazione che consente di procrastinare (o evitare per "sempre"?) il momento in cui le dimensioni del blocco dovrebbero essere aumentate.

A me sembra che l'aumento delle dimensioni dei blocchi costituisca un elemento di divisione irrisolvibile nella comunità bitcoin (ma non ne capisco sinceramente il perchè), e per evitare di affrontarlo una volta per tutte si prova una strada alternativa (che magari è anche migliore, forse questa specie di suddivisone in 2 parti della blockchain dal punto di vista logico è addirittura una soluzione più pulita, ma non sono in grado di giudicare).

Rimane il fatto però che prima o poi la questione di fondo andrà affrontata.

[Sampey]

Il problema che cercherò di sviscerare è il seguente
"Come fa un client chainless a capire se i blocchi che gli stanno arrivando sono merda?"