Topic: Scaling Bitcoin (Read 2669 times)

Nella seconda parte dell'articolo l'autore spiega che l'uso del "Segregated Witness" avrebbe i seguenti vantaggi:

1) maggiore spazio per le transazioni senza violare le regole del consenso (non cambierebbe nulla per i vecchi nodi)

2) eliminazione del problema della "Transaction Malleability"

3) l'introduzione del concetto di versione degli scriptSig nel Segregated Witness consentirebbe una maggiore libertà nel programmare questo script (se ho capito bene): ad esempio si potrebbe sostituire l'attuale metodo di firma con le "Schnorr signatures" (più efficienti) sempre senza modificare le regole del consenso

4) un miglioramento per la sicurezza dei client SVP

EDIT:
Parte 3 (e ultima dell'articolo)
https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-soft-fork-might-establish-a-block-size-truce-or-not-1451423607

EDIT2:
Altro articolo sull'argomento, pubblicato sempre su bitcoinmagazine
https://bitcoinmagazine.com/articles/segregated-witness-the-right-answer-to-the-wrong-question-1451312467

beh, se vuoi la mia opinione, non bisogna nascondersi dietro ad un dito:

ci sono una marea di problemi che stanno sopravvenendo: dimensione blocco, pesantezza dei full node, potere dei miner e/o delle minig-pool, utilizzo prevalentemente speculativo
di bitcoin VS l'ottica iniziale di moneta di scambio per beni  ecc. ecc. potrei proseguire per decine di capi piu' o meno importanti.

Per tornare sul tuo tema, io ho un full node. Ora uso una macchina con 32 giga di ram, un quad core abbastanza tosto, dischi sas molto performanti,
e la trovo spesso con bitcoin-qt che utilizza piu' di 7 giga di ram, uso dei processori (per validazioni e cazzi vari) al 90% per non parlare della banda internet.

Io fortunatamente ho a disposizione le risorse aziendali, e quindi per ora posso ancora permettermelo, ma presto (max un anno) con questo ritmo di crescita
dovro' dismetterlo, considerando che lo faccio come studio personale e che non e' previsto nessuna ricompensa per un full-node (che secondo me puo' essere
considerata una grave carenza di disegno)

Insomma, ci sono un sacco di problemi.

Nel fratempo, i ragazzi dello sviluppo stanno facendo il possibile, mettono pezze, cercano nuove soluzioni e scappatoie, usando tutta la loro intelligenza
e la loro voglia di fare al meglio.

Nello stesso frattempo, il  restante 99% degli utenti, come e' sempre stato e sara' sempre nella natura umana, se ne fotte
e si limita a fare speculazioni dalla mattina alla sera, senza una minima visione strategica, poi se un giorno si spacca tutto, passeranno
a succhiare qualche altra risorsa da qualche altra parte.

Quindi cosa succedera' ?  succedera' che  come tutte le cose tecnologiche date in pasto alle masse,
si raggiungera' forse un equilibrio, che non sara' l'equilibiro piu' fico, ma probabilmente sara' rappezzato, bieco, ingiusto e  in mano ai piu' avidi.
E sara' cosi' perche questo e' lo specchio della nostra natura.


EDIT: come ho sempre sostenuto, non mi aspetto un miracolo da bitcoin, nel senso che il punto di arrivo sara' per forza quello, essendo quella la natura umana.
Quello che mi aspetto, e' che nel tragitto per arrivare a questo nuovo equilibrio, ci saranno tanti scossoni all'equilibrio attuale
da poterla considerare  una vera rivoluzione.

Rimango ancora un po' OT, ma secondo me è fondamentale capire non solo la tecnica ma anche le implicazioni "politiche" che soggiacciono a certe scelte tecniche (e questo credo è comunque anche il senso di questo thread).

L'impiego dei client leggeri sembrerebbe da una parte rendere più "democratico" l'accesso alla rete (anche chi ha scarse risorse computazionali può collegarsi alla rete) ma d'altra parte questo utilizzo "al risparmio" va nella direzione di modificare i rapporti di forza tra minatori e nodi nel meccanismo di gestione delle regole.

Se infatti in una rete a forte prevalenza di full node il "potere" è concentrato nei nodi a scapito dei minatori, (vedere a riguardo l'ottimo articolo di HostFat  http://www.rischiocalcolato.it/2015/07/bitcoin-oirgini-crisi-transazioni.html da cui ricavo la seguente citazione):



nel caso di una presenza importante di client leggeri il "potere" verrebbe spostato sui minatori (fonte: https://en.bitcoin.it/wiki/Full_node):



Come si situano allora i client Core con pruning attivato?
In che senso sono a metà strada, vanno nella direzione di dare maggior potere ai nodi o ai minatori?

Tutto questo discorso mi fa riflettere sulla relazione "tecnica - economia".
Certo che già è difficile capire se una proposta come il "Segregated Witness" ad esempio sia più o meno valida dal punto di vista tecnico, ma riuscire anche a cogliere le conseguenze politico-economiche di questa proposta per poter esprimere poi un parere assennato mi sembra quasi impossibile!

tecnicamente no, perche' in certi casi serve  un full "node"

e' una sorta di via di mezzo, molto piu' leggero, ma avendo solo 500 MB (regolabili) circa di
blockchain non puo' fare ogni tipo di validazione.

supponi che ti arriva una TX che fa riferimento ad altre TX che sono in un pezzo
di blockchain di cui tu non hai una storia, non sai come gestirla, se validarla o no in pratica.

invece il fatto che non si puo' usare il wallet e' solo una limitazione temporanea, ovviamente.

Se si usa Bitcoin Core con il pruning attivato tecnicamente si può considerare ancora un "full node"?

Avevo inoltre letto che con quella opzione attivata non si può usare il wallet (ma dovrebbero risolvere la cosa nella 0.12)

Veramente  nel nuovo core, con il parametro -prune, (per ora disabilitato di default)
in realta' ci sono gli header + una parte (piccola) della blockchain
che e' sufficente per quasi tutte le verifiche , se poi si trova in
un caso che non sa gestire, chiede agli amichetti full come fare.

No probabilmente mi sono espresso di cazzo.
Per correttezza avrei dovuto dire che ci troveremmo 3 tipi di client
- Full Header + Merkel
- Full Solo Blocchi Header (Nuovi Client)
- Chainless

Non ti riferivi ai client SPV?

EDIT: io mi riferivo a questo http://bitcoin.stackexchange.com/questions/32529
Forse lì c'è una risposta alla mia domanda, adesso devo capire cos'è questo "Bloom filter".

Guarda, io credo che Chainless voglia dire SENZA NIENTE, cioè è solo un client, parla con un webservice che gli fornisce i dati.
Sul webservice cè un full node

Leggendo la domanda di Sampey mi sono accorto che io non conosco bene nemmeno il funzionamento dei client "chainless" attuali. Ho provato allora a dare un'occhiata al paper originale di Nakamoto  -->  https://bitcoin.org/bitcoin.pdf  nel quale c'è una breve sezione al riguardo:


e questo wiki https://en.bitcoin.it/wiki/Thin_Client_Security


Riassumo quello che ho capito sul funzionamento attuale di questi client:

a) essi scaricano solo gli header dei blocchi (non i blocchi interi); l'header di ciascun blocco è costituito dall'hash dell'header del blocco precedente + nonce + Merkle Root (che è il punto finale del Merkle Tree, ovvero di un albero di hash creato a partire dagli ID delle transazioni presenti nel blocco (le foglie dell'albero), che vengono raggruppati a due a due, e a ciascuna di queste coppie di ID viene applicata la funzione hash e questa procedura si reitera raggruppando i risultati ottenuti nel passo precedente a due a due fino a ottenere il Merkle Root)

b) quando un client riveve un pagamento su un proprio indirizzo, per controllare la validità di quel pagamento deve per forza affidarsi a dei full node (i quali invece hanno a disposizione tutta la blockchain). Interroga quindi questi full node, e dopo aver scelto quello che possiede la catena più lunga (con la difficoltà complessiva maggiore), ottiene da questi solo la parte del Merkle Tree necessaria (in combinazione con l'ID della transazione di cui sta controllando la validità) a risalire al Merkle Root.
In questo modo quindi il client verifica solo che la catena più lunga contiene un blocco che effettivamente contiene a sua volta quella determinata transazione (ma non controlla la "storia" che ha preceduto quella transazione, si fida del fatto cioè che questo controllo sia stato fatto in maniera corretta dal full node che ha scaricato e vagliato l'intera blockchain pezzo per pezzo)

c) a questo punto il client calcola, a partire da quel blocco, il numero di conferme che ha quella determinata transazione.


Domande:

1)  come fa un client "chainless" ad accorgersi che è stato effettuato un pagamento verso un proprio indirizzo? Dal momento che non possiede le transazioni presenti nella blockchain, come fa a ricavare solo dagli header dei blocchi il messaggio: "attenzione, nel blocco x generato ieri alle yy:zz c'è una transazione che ti riguarda?"

2) il problema di questi client leggeri consiste solo nel controllo della validità dei pagamenti in ricezione? Il controllo sulla validità dei pagamenti effettuati invece dagli indirizzi del proprio client è un problema solo di chi riceve il pagamento e dei full node più in generale?

Un client che ha solo gli header dei blocchi dovrebbe comunque riuscire a capire da solo se questi sono validi o meno

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

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.

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.

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

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.

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

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à)

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

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.