gbianchi (OP)
Legendary
Offline
Activity: 3178
Merit: 2726
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 07, 2015, 01:09:44 PM Last edit: December 07, 2015, 01:28:26 PM by 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
Legendary
Offline
Activity: 1120
Merit: 1000
https://cryptoworld.io
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 10:18:04 AM |
|
|
|
|
|
Sampey
Legendary
Offline
Activity: 2632
Merit: 1040
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 06:01:01 PM |
|
|
|
|
|
gbianchi (OP)
Legendary
Offline
Activity: 3178
Merit: 2726
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:10:16 PM |
|
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
Legendary
Offline
Activity: 2506
Merit: 1120
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 08, 2015, 11:51:27 PM |
|
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?
|
Waves mi piaceva ora non più.
|
|
|
gbianchi (OP)
Legendary
Offline
Activity: 3178
Merit: 2726
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2015, 12:18:04 AM Last edit: December 09, 2015, 08:10:17 AM by 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
Legendary
Offline
Activity: 1316
Merit: 1481
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2015, 10:31:32 AM |
|
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
Legendary
Offline
Activity: 1526
Merit: 1010
▇ ▅ ▃ ▇ ▅ █
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2015, 10:01:48 AM |
|
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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
Sampey
Legendary
Offline
Activity: 2632
Merit: 1040
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2015, 10:18:51 AM |
|
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 ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
acquafredda
Legendary
Offline
Activity: 1316
Merit: 1481
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2015, 10:45:05 AM |
|
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
Legendary
Offline
Activity: 1008
Merit: 1001
In Cryptography We Trust
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 11, 2015, 12:50:11 PM |
|
Qualcuno è riuscito a capire se dal workshop di weekend scorso è venuto fuori qualcosa di concreto?
|
|
|
|
gbianchi (OP)
Legendary
Offline
Activity: 3178
Merit: 2726
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2015, 01:48:56 PM |
|
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-coolVi 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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 337
Merit: 250
HTML5/Node.js/PHP developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2015, 03:51:33 PM |
|
ci vorrà ancora un bel po' per riempire i blocchi da 1mb, qualche mese si può aspettare
|
|
|
|
Sampey
Legendary
Offline
Activity: 2632
Merit: 1040
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2015, 04:03:26 PM |
|
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-sizeDando 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-transactionsNon 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
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 21, 2015, 02:40:35 PM Last edit: December 24, 2015, 01:04:47 PM by arulbero |
|
|
|
|
|
gbianchi (OP)
Legendary
Offline
Activity: 3178
Merit: 2726
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 21, 2015, 02:56:03 PM |
|
boh speriamo che ci siano davvero i vantaggi che dicono... quando facevo il programmatore, questa mi avrebbe puzzato tantissimo da pezza ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) EDIT: o meglio che i vantaggi superino gli svantaggi.
|
|
|
|
Sampey
Legendary
Offline
Activity: 2632
Merit: 1040
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 21, 2015, 03:09:15 PM |
|
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 (OP)
Legendary
Offline
Activity: 3178
Merit: 2726
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 21, 2015, 03:16:36 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) ma scherzo eh, non so i dettagli.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 21, 2015, 03:22:12 PM |
|
boh speriamo che ci siano davvero i vantaggi che dicono... quando facevo il programmatore, questa mi avrebbe puzzato tantissimo da pezza ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Legendary
Offline
Activity: 2632
Merit: 1040
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 21, 2015, 03:24:22 PM |
|
Il problema che cercherò di sviscerare è il seguente "Come fa un client chainless a capire se i blocchi che gli stanno arrivando sono merda?"
|
|
|
|
|