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?"

[Anon39]

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

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

[arulbero]

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

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

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:

8.
Simplified Payment Verification
It is possible to verify payments without running a full network node.  A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network   nodes   until   he's   convinced   he   has   the   longest   chain,   and   obtain   the   Merkle   branch linking   the   transaction   to   the   block   it's   timestamped in. He   can't  check   the   transaction   for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable   if   the   network   is   overpowered   by   an   attacker.     While   network   nodes   can   verify transactions   for   themselves,   the   simplified   method   can   be   fooled   by   an   attacker's   fabricated transactions for as long as the attacker can continue to overpower the network.   One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block,   prompting   the   user's   software   to   download   the   full   block   and   alerted   transactions  to confirm the inconsistency.  Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

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

A client verifies the depth D of a block by checking that there are D blocks after it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a block chain reorganization producing a new longer fork which excludes the transaction.

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?

[Sampey]

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

[arulbero]

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

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

[Sampey]

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

[gbianchi]

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

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.

[arulbero]

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

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.

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)

[gbianchi]

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

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.

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)

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.

Full Nodes and “Lite” Nodes

The main objective of a Bitcoin Node is to log transactions on the network and send the details to other nodes. As soon as a majority of Bitcoin Nodes reach consensus over whether a transaction is valid or not, it will be either accepted or rejected by the network. And that decision is then broadcasted to all other Bitcoin nodes and mining pools.

In order to strengthen the Bitcoin network, a lot of Bitcoin Nodes have to be put in place to support the increasing amount of transactions being broadcasted and relayed. But there are two different types of Bitcoin nodes: full nodes and so-called “lite” nodes. Both are equally important, but block pruning might shake things up a bit.

A “full” Bitcoin Node stores a copy of the entire Bitcoin blockchain on its storage device. Full Bitcoin Nodes are a key factor to the Bitcoin network, as they can match incoming transactions against the entire history of the blockchain, rather than just the transactions of the previous 550 blocks. Especially in the event of a double-spend, Full bitcoin Nodes can prevent these transactions from being confirmed, whereas “lite” nodes might not be able to distinguish between the first and subsequent spending of the same coins.

“Lite” Bitcoin Nodes, which only store the previous 550 blocks of data”, are a solution for people with slower internet speeds, or monthly data caps. However, in terms of security, block pruning for Bitcoin Nodes may not be the best idea. On the other hand, having to store less amount of data might bring a ton of new nodes to the Bitcoin network overall. By further decentralizing the Bitcoin network, it only becomes stronger, which would be a positive effect.

[arulbero]

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

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.

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

Le regole del network sono imposte dai nodi, che hanno costi inferiori a quelli dei minatori. Il costo di installazione e gestione dei nodi è proporzionale all’uso che ha il mercato, se il mercato è piccolo, il costo di gestione di questi singoli nodi sarà ancora più basso, viceversa se il mercato si amplia indefinitivamente, può andare ad alzarsi.

Il minatore, che deve sottostare alle regole dei nodi, è un “umile” (ormai si fa per dire) servitore, che rispetta queste regole e in base ad esse emette il blocco, puntando sul fatto che tale venga accettato dalla totalità del network, o comunque da quella maggioranza del network che “da valore ai bitcoin che è andato a creare”.

E’ l’ultima ruota del carro, il suo potere decisionale è molto limitato, ed è del tutto focalizzato nel accontentare il volere del mercato, del cliente … visto che tale è ciò che va a dare valore al premio che riceve.

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

Full nodes enforce the consensus rules no matter what. However, lightweight nodes do not do this. Lightweight nodes do whatever the majority of mining power says. Therefore, if most of the miners got together to increase their block reward, for example, lightweight nodes would blindly go along with it. If this ever happened, the network would split such that lightweight nodes and full nodes would end up on separate networks, using separate currencies. People using lightweight nodes would be unable to transact with people using full nodes

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!

[gbianchi]

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!

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.

[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

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