Bitcoin Forum

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.


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

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.

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.

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

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 !

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

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.

io ho messo il mio full node in 0.13.1

non servira' a un cazzo, ma chissa'.

si, ma quando parlate voi, a me serve un traduttore, ogni 5 parole devo andare a vedere su google il significato  ;D
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?).

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

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


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


***


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/

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  ;D

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

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





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





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



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


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


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:



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



***

molto utili le domande sotto (3) che spiegano in soldoni alla gente cosa cambia per loro (senza entrare nel tecnico)

al volo per i non anglofoni (non io) sarebbero da tradurre, pero va bene cosi.. ottimo lavoro

News su segwit:


La frase più importante è che "al momento il 90.27 della potenza di calcolo è in supporto a Bitcoin core con la loro segwit mentre il rimanente 10% supporta proposte come La Unlimited e la Classic."

fonte: https://cointelegraph.com/news/13-of-nodes-support-segwit-release-bitgo-runs-core-0131

non è detto però che tutti quelli che supportano Bitcoin Core passeranno automaticamente al segwit potrebbero semplicemente decidere di non aggiornare all'ultima versione, sarebbe un modo semplice per dire stiamo bene così.

Certamente, oppure potrebbero passare al Classic o all'Unlimited.

Comunque adesso siamo a 13.7% per il segwit e mi pare che quella che era in seconda posizione (8MB) sia calata dal 12% di qualche giorno fa al 10%.

https://coin.dance/blocks

...e segwit partirà il 15 novenbre.

Le proposte alternative a segwit stanno crollando di giorno in giorno:

SegWit
13.70%
Unlimited
  9.70%
8 MB
  9.60%
Classic
  2.10%

Fino a diversi giorni fa 8MB era testa a testa con segwit.

quelli sono tutti hard-fork però non vanno presi alla leggera non ci molto esperienze con gli hard-fork che comunque ebbero il loro momento mesi fa, qui c'è qualche considerazione su un semplice aumento a 2MB:



https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#size-bump

Riguardo al quel problema in particolare, è già fixato da quasi un anno su tutti i fork alternativi.
Anche se il blocco è 20 MB (per fare un esempio), un blocco con una transazione oltre a 1 MB non viene mai accettato.
Su unlimited la soluzione presa sarà un'altra, i blocchi ricevuti verranno verificati in contemporanea, e quindi quello che si risolverà più velocemente avrà la meglio.

https://bitcoin.org NON è un sito di informazioni imparziale.

hanno cambiato anche il nome del sito in Bitcoin Core è palese che supportino il client core rispetto agli altri  ;D

https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/


entrambe le soluzioni mi suscitano qualche dubbio ad esempio sapendo che il limite alla transazione è 1 MB nulla gli impedirebbe di farne 20 differenti 1 MB ciascuna e comunque raggiungerebbero lo scopo di spammare e rallentare il network.

la seconda soluzione sembrerebbe la più sensata ma sarebbe discriminatoria non solo per le transazioni ma perché alla fine i mining pool con più risorse sarebbero poi quelli a decidere quali transazioni favorire e quali no.

Sono in molti oramai a pensare che un hard fork non si può prendere alla leggera ed è per questo che i core vogliono evitarlo con segwit. Dal fatto che in "pochi" abbiano abbracciato i vari hard fork e dal fatto che le loro percentuali calino appena presentato il soft fork, se ne può dedurre che pure i miners sono contenti di questa possibilità rappresentata da segwit.

Questo non cambia dalla situazione attuale.
Il problema poi delle transazioni, non è legato al fatto che qualcuno prepari la transazione, perchè il miner può sempre decidere giustamente di ignorarle, o ignorarle tutte.
Il problema c'era se un miner malevolo cercasse di fare questa cosa ... ma un miner difficilmente è in grado di fare 20 blocchi da 1MB ;)

@Sandro kensan
L'argomento hard fork, fuori dalle sezioni italiane, su bitcointalk, su r/bitcoin, sulla mailing list ecc ... è bandito.
Chi ne parlava subiva un sano https://en.wikipedia.org/wiki/Character_assassination, venendo cancellati commenti pro (o direttamente i suoi), e lasciati solo giusto i troll.

Al di la della validità tecnica di una soluzione o l'altra, non penso che l'opinione generale rimasta sia il risultato di qualcosa di sano.

Questa non l'ho capita. Non capisco come sia legato alla soluzione di bitcoin unlimite (o segwit anche), rimane tutto uguale.
I miner e miningpool comunque hanno sempre interesse ad aggiungere quante più tx possibili, sempre che non vadano a creare un rischio per il loro guadagno (ad esempio, rischio di creare blocchi orfani)

Questo non lo sapevo, io seguo solo la sezione italiana. Forse per questo che Via ha issato come bandiera proprio l'ostilità verso i core.

Beh guarda, è successo di tutto fuori da qui, personalmente quanto di più schifoso si potesse vedere, almeno per quanto mi riguarda :)

Via potrebbe essere uno, altri miner/pool potrebbero avere il timore a dare la loro opinione.

Comunque ti ringrazio per il lavoro di mantenere un posto in cui ci si possa confrontare :)

boh a parte che nella nostra sezione ne parliamo,

ad esempio qui ne parlano tranquillamente

https://bitcointalk.org/index.php?topic=941331.0 (ed ho fatto una ricerca di un secondo)

dire che e' bannato come argomento in bitcointalk mi sembra se non altro eccessivo....

EDIT: effettivamente e' un thread bloccato a molti mesi fa... ma quale sarebbe l'obiettivo di
bandire questo genere di discussione ? e allora perche' non lo bandiscono anche nella sezione italiana ?

Perchè gli admin non sanno leggere l'italiano, e in generale comunque la comunità italiana vale poco o nulla rispetto al resto del mondo, quindi nemmeno perderci tempo.
Per avere informazione non filtrata:
https://www.reddit.com/r/btc
https://bitco.in/forum/

ah siamo in pieno gombloddo !

comunque ho dato una letta superficiale a quei forum, e ho trovato
diverse discussione del livello "secondo me sono gli USA"... per evitarmi tante letture inutili,
mi indichi dove ci sono dei seri confronti tecnici (con riferimenti ai BIP) tra le varie soluzioni ?

Sezione Bitcoin Protocol:
https://bitco.in/forum/forums/bitcoin-protocol.4/

E la sottosezione più attiva
https://bitco.in/forum/forums/bitcoin-unlimited.15/

per me stavamo bene cosi

comunque mi pare che non stia avendo troppo successo questo soft fork, siamo solo al 12.9% dei blocchi.

nel primo caso intendevo che un ipotetico client che supporti i blocchi da 20 MB che si premunisse con qualche spam filter che impedisca a una singola transazione di superare 1 MB comunque non impedirebbe allo spammer di realizzarne 20 diverse TX aggirando i limiti e riempiendo il blocco e con questo mi allaccio alla seconda risposta le vittime principali sarebbero i nodi che non hanno risorse sufficienti, un grosso pool che si affida a server con load balancing e linee dedicate nell'ordine dei gigabit non avrebbe problemi nell'elaborare e trasmettere i blocchi che poi potrebbero essere confermati solo da altri mining pool con risorse simili.

Fixed  ;)

(avevi scritto due volte la stessa cosa)

Ciao!

Grazie per la segnalazione, corretto!  :)

A che punto siamo? (Per favore in parole semplici perchè non sono molto ferrato...)

Grazie

Non siamo ancora all'inizio, l'inizio è il 15 di novembre.

Per i numeri di segwit vedi il grafico qui:

https://coin.dance/blocks

non ho capito bene cosa intendano con "explicit mining pool support", (le barre in alto)
pero' subito dopo se si guada il grafico a torta emerge che l'87% dei blocchi sono minati su core
e e 11% su unlimited... insomma le prima barre sopra sono un po' forvianti.

Anche guardando i full node (https://bitnodes.21.co/)  sono quasi tutti core 0.13.0 o 0.13.1
insomma... vedremo dopo il 15 cosa succede, ma secondo me i blocchi minati segwit saranno molti
di piu' dell'11%.

Al momento l'87% dell'hash rate è legato all'utilizzo di Bitcoin Core in una delle sue versioni (ma solo l'11% circa della potenza computazionale  - pool BitFury 7,5% e BitClub 3,1% -  lavora con la versione 0.13.1 con supporto esplicito a segwit), mentre le altre pool utilizzano Unlimited (11,6%:  ViaBTC 8,8%, Bitcoin.com 1,9%) o Xt (1,1% : altre pool), cioè sono manifestamente contro segwit.

In "mezzo" ci sono alcune pool tipo BW Pool(9,2% - sostiene solo 8 mega, vedi blocco 438097) ed altre che probabilmente utilizzano ancora Bitcoin Core ma non è chiaro se sono propense a supportare segwit.

Occhio che quasi tutti i grafici a torta si riferiscono ai blocchi minati nell'ultima settimana tranne uno che tratta le percentuali relative solo ai blocchi minati oggi.

La questione è capire quanti di coloro che detengono il 76% (87% - 11%) di potenza computazionale circa e che stanno ancora usando vecchie versioni di Core lo fanno perchè sono contrari al soft fork e quanti invece hanno intenzione di upgradare alla attuale versione in un futuro prossimo.

Da quel poco che ho capito io ogni blocco minato ha una stringa che nel caso di aderenza esplicita al protocollo segwit riporta la stringa segwit tra slash (barre):

\X%XH$g/BitFury/SEGWIT/

Penso sia una stringa volontaria in cui ogni uno ci mette quel che vuole, una cosa tipo l'user agent dei browser.

Riguardo a quello che ha detto arulbero credo che il fatto di appoggiare una opzione alternativa a segwit non voglia dire essere "contro", fatta eccezione per VIABTC.

avevo fatto un search su vari pool e qualcosa fuori sulle intenzioni è saltato fuori ad esempio quelli di Antpool a maggio dicevano che non avrebbe supportato il segwit senza il blocco a 8 MB basterebbero loro a far saltare tutto.


Antpool Will Not Run SegWit Without Bitcoin Block Size Increase Hard Fork

https://bitcoinmagazine.com/articles/antpool-will-not-run-segwit-without-block-size-increase-hard-fork-1464028753

Ma se fosse così non si tratterebbe di un dato utile, io penso voglia dire che il 10,6% attuale dei blocchi minati sta votando per segwit. Se quella non fosse la percentuale di voto che cosa si dovrebbe confrontare con la famosa soglia del 95%?

Comunque il dato ufficiale, l'unico che conta, si troverà qui:

https://chainquery.com/bitcoin-api/getblockchaininfo  (oppure "bitcoin-cli  getblockchaininfo" se avete installato Core sul pc)

nel campo segwit dopo il 15 novembre



Eppure guardando alle indicazioni di voto dei blocchi minati da Antpool non c'è il supporto agli 8 mega.

Una domanda banale: per votare il supporto al blocco di 8 mega bisogna per forza utilizzare Bitcoin Unlimited, per segwit BitCoin Core 0.13.1, e così via? Oppure uno può minare con il client che preferisce e modificare la versione di un blocco per votare in piena libertà sui vari fork a prescindere dal software che sta usando?

Non so precisamente con che cosa si confronterà il dato del 95% ma mi è chiaro che il programma bitcoincore in qualsiasi versione sia mette dei dati (versione di bitcoincore oppure la stringa segwit tra slash o altro) sui blocchi minati, tali dati sono tutti volontari come l'useragent e se uno vuole li può cambiare.

In pratica uno può usare segwit per minare e poi può mettere la stringa o altro tipo di dato che si riferiscono all'unlimited. Questo è già stato minacciato e sicuramente c'è chi lo fa in quanto è una libertà di tutti i programmi open source e liberi di modificare il sorgente come uno vuole e di compilarselo oppure di usare "estensioni" o programmini che cambiano la versione del core un una versione fake: basta cambiare un numero o una stringa all'interno del codice.

No, bisogna usare solo i bit indicanti la versione del blocco (la seconda colonna dei dati che trovi in fondo alla pagina di https://coin.dance/blocks) mentre la terza colonna, la coin base text, è una stringa inutile (se ho ben capito).

Da qui:
https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/
Per ulteriori dettagli sul bip 9:  https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki (https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki)

In pratica per segnalare il fatto che un miner è pronto ad accettare e supportare il soft fork esso deve segnalarlo impostando la versione del blocco. Probabilmente non ha molto senso segnalare che si è pronti a supportare i futuri blocchi costruiti con le nuove regole se si usa ancora un software vecchio (anche se ci sono ulteriori 2 settimane di tempo tra il raggiungimento del quorum (stato LOCKED-IN) e l'attivazione vera e propria (stato ACTIVE) per aggiornare il software).

Hai ragione comunque su un fatto: la percentuale del 10,6% fornita da coindance si basa attualmente solo sulla stringa nella coinbase, poichè prima dello stato STARTED (che si avrà il 15 novembre) non è possibile segnalare attraverso il version bit la propria adesione al fork. Infatti se guardi alla versione dei blocchi che coindance indica supportare segwit, essa è uguale alla versione degli altri (0x20000000)

Comunque ho scoperto anche che la votazione segue un periodo di retarget pari a quello della difficoltà, ogni 2016 blocchi (quindi ci saranno al massimo in un anno 26 periodi di 2016 blocchi ciascuno (2 settimane circa), ovvero 26 votazioni possibili per raggiungere il quorum di attivazione del 95%).


C'è da fare però una precisazione: quali software supportano il bip 9, cioè seguono il metodo del version bit per il soft fork?

Da questa pagina :   https://coin.dance/nodes

risultano solo Bitcoin Core (non so quali versioni, ovviamente sicuramente l'ultima) e Bitcoin XT, mentre gli altri non risultano da quella pagina supportare il nuovo metodo


NB: questo nuovo metodo di effettuare il soft fork (che segue le regole del bip9) è diverso dal precedente 950/1000.

Il vecchio metodo, detto IsSuperMajority, funzionava così:

C'e' qualcosa che impedisce che si facciano due votazioni in contemporanea o sovrapposte in parte?

Si possono fare fino a 29 votazioni in contemporanea per 29 soft forks diversi, sommando i vari bit partendo dalla versione 0x20000000 che è quella "liscia" (che non segnala il supporto a nessun fork):

Quindi vengono esaminati solo gli ultimi 1000 blocchi. Mi pare anche di capire che la finestra temporale di 26*2016 blocchi è fissa e cioè ha una precisa data di inizio e una precisa data di fine: è così? In pratica è una finestra temporale che dipende dai tempi di dimezzamento del premio.

Poi sai dirmi a partire dal 15 di novembre che numero si raggiungerà per chi adotterà il segwit?

“segwit” soft fork uses bit ?, i.e. 0x? + 0x20000000

No, gli ultimi 1000 blocchi riguardano solo il vecchio metodo, detto IsSuperMajority. Ho rieditato il mio post per segnalare meglio che era il vecchio metodo 950/1000, il nuovo (bip 9) è 1916/2016 blocchi! Il vecchio era a finestra mobile, il nuovo a finestra fissa, il vecchio metodo proponeva un soft fork senza scadenza, con il nuovo metodo la proposta ha una scadenza precisa.


No, dipende dal tempo, c'è una data ben precisa di inizio e di fine (mentre il numero 26 è solo una mia stima banale che ho ricavato, ma se la potenza computazionale dovesse crescere magari ci sta anche qualche votazione in più!)

Inserisci l'unix timestamp qui
http://www.unixtimestamp.com/  e otterrai data iniziale e finale. Ovviamente la data del 15 novembre non è esattamente la data dell'inizio della votazione, bisogna aspettare il primo retarget dopo il 15 novembre (qui https://bitcoincore.org/en/segwit_adoption/ si parla addirittura di 20 novembre).



Questo non lo so  ;)
Forse adesso lo so:


quindi poichè mi pare di aver capito che il bit 0 è il primo da destra, il bit 1 dovrebbe essere il secondo,  quindi:

segwit soft fork uses bit 1, i.e. 0x2 + 0x20000000 =  0x20000002
0    0    1    0    0    …    0    0    0    0    0    0    0    0    1    0

Ho fatto un po' di confusione con i tuoi quote e non ho letto dovutamente. Comunque il primo timestamp dice:
2016-11-15T00:00:00+00:00
Quindi è il 15 di novembre con l'orario di Greenwich, l'altro timestamp è dopo un anno.

Non parte direttamente il 15 Nov, ma al primo retarget dopo quella data. Quindi potrebbe parte il 17-18-19 Novembre, questo perché non si può sapere con esattezza la data precisa di un retarget della difficulty.
Quindi hanno scelto di stare un po larghi, giusto per dare qualche giorno in più a chi volesse (ai miner) di aggiornare il client.


Il secondo timestamp è la deadline, i dev core pensano che un anno possa bastare per l'attivazione di segwit.

Ho provato a fare il calcolo preciso.

Se X è una variabile casuale binomiale che misura il numero di successi (i successi intesi come blocchi minati con flag segwit), si può considerare ogni finestra temporale come una sequenza di 2016 prove identiche e indipendenti dove in ogni prova la probabilità di successo è data dall'hash power di segwit.

-------------------------------------------------------------------------------------------------
Supponiamo per iniziare che l'hash power a favore di segwit sia esattamente del 95%.

Quindi P(X>=1916) = 49%  (andare qui -> http://stattrek.com/online-calculator/binomial.aspx e fare i calcoli)

Quindi adesso cambio variabile casuale, e indico con Y il numero di successi (in questo caso i successi intesi come raggiungimento/superamento della quota 95%) all'interno di una sequenza di 26 votazioni.

P(Y>=1) = 99,99999% (praticamente 100%. Dopo sole 10 votazioni la probabilità di attivazione del fork P(Y>=1) = 99,88% !)

--------------------------------------------------------------------------------------------------------------------------------------------
Supponiamo ora che l'hash power sia del 94%

Quindi P(X>=1916) = 2,5%

Quindi P(Y>=1) = 48,3%  (quindi già con solo l'1% di hash power in meno, le probabilità di attivazione si dimezzano)

--------------------------------------------------------------------------------------------------------------------------------------------
Supponiamo ora che l'hash power sia del 93%

Quindi P(X>=1916) = 0,01%

Quindi P(Y>=1) = 0,27%  (neanche 3 possibilità su 1000)
-------------------------------------------------------------------------------------------------------------------------------------------

Conclusione: la lunghezza della finestra temporale (2016 blocchi sono tanti) e il numero esiguo di "tornate" elettorali (26 retarget in un anno) limitano moltissimo le possibilità che a decidere il fork sia una fluttuazione statistica; se il fork verrà attivato è solo se effettivamente ci sarà il 95% di hash power a supporto di segwit.

giusto per completezza, credo che nel calcolo ci siano due inesattezze:

1) dai per scontato che un hashpower del 95% porta ad una probabilita' del 95% di minare un blocco, mentre la probabilita' di minare
un blocco e' a sua volta un processo di poisson con le sue possibili varianze.

2) l'hashpower varia durante tutto il periodo di voto, non e' mai costante, quindi applicare il modello a distribuzione binomiale
e' una semplificazione non indifferente

credo comunque che anche considerando queste sottigliezze, la la conclusione sia esatta, in particolare il fatto che la finestra non sia "sliding"
ma siano tornate elettorali discrete riduce di sicuro la possibilita' di un risultato da fluttuazione (io pensavo che si usasse una finestra sliding)

Sul punto 2 ti dò ragione, l'hashpower non è costante ma di più non si può fare (a meno di non modellizzare esplicitamente una fluttuazione pure di quella percentuale nel tempo)

Sul punto 1 forse si potrebbe fare di più, ma mi risulta abbastanza complicato.  Chiaramente la probabilità di minare un blocco da parte dell'intera rete è un processo di Poisson continuo che si può descrivere con una distribuzione esponenziale di parametro 1/600 (in media 1 successo ogni 600 secondi):

quindi P(di minare un blocco entro t secondi) = 1 - e^(-1/600*t); facendo due calcoli si ottiene:

(minuti)   secondi            probabilità
   -              1                 0,001665279
   -             10                0,016528546
   -             20                0,0327839
   -             30                0,048770575
   1            60                0,095162582
   2            120              0,181269247
   3            180              0,259181779
   4            240              0,329679954
   5            300              0,39346934
   6            360              0,451188364
   7            420              0,503414696
   8            480              0,550671036
   9            540              0,59343034
  10           600              0,632120559
  20           1200            0,864664717
  40           2400            0,981684361
  60           3600            0,997521248
 120          7200            0,999993856

Si può così notare che c'è solo un 63% di probabilità che la rete mini un blocco entro 10 minuti (10 minuti è anche il tempo medio), mentre c'è ancora uno 0,25% di probabilità che ci voglia più di 1 ora.

Ora se supponiamo per semplicità che l'hashrate sia suddiviso in modo costante nel tempo nella proporzione 95% e 5%, la probabilità che sia l'una parte o l'altra a minare il blocco come si calcola? Bisognerebbe tenere conto in questo caso che ci sono 2 variabili aleatorie, calcolare la funzione distribuzione congiunta da cui ricavare le distribuzioni marginali delle due variabili, poichè le due probabilità si influenzano a vicenda. Mi sembra un po' troppo complesso . ;)

non so se avete notato il pool viaBTC è risalito all'8,5% dei blocchi minati questa settimana https://coin.dance/blocks/thisweek


Why We Must Increase the Block Size and Why I Support Bitcoin Unlimited

https://medium.com/@ViaBTC/why-we-must-increase-the-block-size-and-why-i-support-bitcoin-unlimited-90b114b3ef4a#.dh79aso3p

https://coin.dance/blocks

cosa intendono con "locked in"?

https://www.reddit.com/r/Bitcoin/comments/5d1jal/slush_starts_signalling_for_segwit_in_advance/?utm_source=ifttt

Ho visto:

https://coin.dance/blocks

nei blocchi (17/298 in questo momento) slush segnala il suo voto e la sua adozione. Quindi siamo a un +7% (flottante come al solito).

Continuano a supportare segwit BitFury e ckpool/BitClub Network (che non sono più conteggiate da coin.dance).

Probabilmente in totale siamo un po' sotto al 20%.

per chi volesse seguire l'evoluzione ci sono questi altri link :

https://blockchain.info/charts/bip-9-segwit

https://data.bitcoinity.org/bitcoin/block_version/30d?c=block_version&r=hour&t=a

Grazie mille, l'ho segnalato anche sui vari gruppi telegram.


Edit:

Mi hanno segnalato anche questo:  http://api.qbit.ninja/versionstats  qui il grafico https://bitcoincore.org/en/segwit_adoption/

Al momento la situazione è questa:

il primo periodo di retarget è partito ufficialmente con il blocco 439488 (vedere la difficulty del blocco https://blockexplorer.com/block/000000000000000001a4da46f04329a0790734e22172fe14a2c8cf973e8c9d29 che è cambiata rispetto alla precedente, oppure prendere il numero del blocco attuale, dividerlo per 2016 e prendere il resto per sapere da quando è partita questa prima finestra ufficiale)

Nel momento in cui scrivo siamo arrivati al blocco 440098, quindi sono stati minati 610 blocchi, di cui 121 blocchi con segnale di supporto a segwit (19,8%).  (-> https://data.bitcoinity.org/bitcoin/block_version/30d?c=block_version&r=hour&t=a)

Questa è l'unica percentuale che conta (o meglio conterà la percentuale finale che si calcolerà sull'intera finestra di 2016 blocchi), i blocchi prima del 439488 anche se segnalavano il supporto non verranno conteggiati.

Edit: correggo l'errore di considerare i blocchi minati ogni 20 minuti, in realtà sono minati ogni 10:

Adesso è più chiaro. Stimando una tempo medio di 20 10 minuti per blocco generato si hanno 28 14 gg per minare 2016 blocchi.
Visto che il blocco 439488 439487 è stato minato nel tempo UTC Nov 18, 2016 9:22:28 AM allora il 2 dicembre approssimativamente alla stessa ora si concluderà il primo ciclo. Comunque si tenga conto che solo in via approssimata e media c'è un blocco minato ogni 10 minuti.

Da qui al 2 dicembre ci sarà la prima votazione e per passare il segwit necessita del 95% dei blocchi minati che abbiano il segnaling settato a 0x20000002 ovvero il bit 2^1 settato a 1.

Segnalo che BTCC ha le seguenti impostazioni:
Signaling: 0x20000002
CoinBaseText: gEK 9||3
fe#Q/hgj
tu
^/BTCC/

BTC China ha il 10% della potenza di hash.

Presumo che il 95% faccia 1915 blocchi, questo dovrebbe essere l'obiettivo per il segwit.

Ogni 10 minuti in media si mina un blocco, quindi 2016 blocchi corrispondono a circa 2 settimane, il normale periodo per il retarget della difficoltà.

Errorone mio, ho fatto confusione. Adesso ho corretto il post.

Un altro grafico relativo alla segwit adoption:

https://bitcoincore.org/en/segwit_adoption/

EDIT: sabato 19 novembre, SegWit Support (22.2%) secondo coin dance. Il calcolo è fatto sugli ultimi 300 blocchi minati.

Di questo passo la vedo dura raggiungere il 95%. E il problema è che anche gli altri fork hanno tutti percentuali basse. In pratica si rischia uno stallo infinito.

quasi... se il segwit non passa entro l'anno non passa più poi è da capire se eventualmente potrebbe essere riproposto, i vari mining pool hanno visioni diverse ed è difficile anche determinare quale sia la più valida, alla fine se il bitcoin rimanesse così com'è senza segwit of cambi di blocksize potrebbe finire per diventare una sorta di oro digitale, inadeguato ai micropagamenti ma ideale allo scopo della conservazione del valore.

Non è neanche detto che bitcoin sarebbe adeguato per la conservazione del valore ("riserva di valore"), in quanto perdendo la sua proprietà di mezzo di pagamento che oggi gli si attribuisce (o sarebbe più corretto dire: la proprietà di mezzo di pagamento che molti scommettono che avrà in un futuro prossimo, in quanto ad oggi sono ancora pochi che lo accettano come pagamento) potrebbe perdere valore e basta.

Basti pensare, per esempio, che fra tot anni, quando la ricompensa del blocco sarà notevolmente diminuita, saranno solo le fee a ricompensare il lavoro di mantenimento della blockchain da parte dei miner. Se non aumenterà la dimensione dei blocchi, o aumenteranno notevolmente le fee per transazione (che diventeranno quindi una specie di tassa di deposito dei btc, che andrà pagata ai miner al momento della loro movimentazione) o il lavoro dei miner diminuirà di pari passo alla loro retribuzione, rendendo meno sicura la blockchain (e quindi meno sicuri i nostri btc, che per questo perderebbero comunque valore).

Questo è un ottimo articolo segnalato già da HostFat l'altro giorno sulle problematiche relative al mancato aumento di dimensione del blocco (l'autore in questo caso è decisamente pro hard fork, non pro segwit):

https://medium.com/@Iskenderun/artificially-limiting-the-blocksize-to-create-a-fee-market-another-variety-of-lifting-the-21-f972b6e3afd8#.3oqssu2s5


 

l'articolo però non sembra tenere conto di quanto già adesso siano i volumi delle transazioni off chain, facendo una stima tra i volumi da coinmarketcap + localbitcoins dovrebbero essere dalle 10-15 volte superiori a quelli riportati su blockchain.info insomma già c'è un layer di mediazione costruito sulla blockchain che ha superato i limiti del blocco a 1MB.

in futuro potrebbero proprio essere questi servizi a spuntare fuori come funghi ad esempio pensa a XAPO che ti permette di comprare direttamente i bitcoin e poi di usarli attraverso una carta di credito virtuale, di fatto il bitcoin resta la tua riserva valutaria, la carta di credito li renderebbe utilizzabili ovunque e anche se i fee fossero cento volte quelli attuali di 0.15 $ su una TX da qualche migliaio di bitcoin sarebbe quasi irrilevante per il mediatore dover pagare 15 $ e renderebbe gli attuali blocchi da 1MB ricchissimi.

ora so che uno scenario del genere alla fine sarebbe una disgrazia per i principi fondamentali del bitcoin ma cosa potrebbe impedirlo ?

1) Non mi pare corretto calcolare i volumi delle transazioni off chain che avvengono nei vari exchange, vedere per questo il famoso thread di gbianchi sulla riserva frazionaria (altro che difesa del valore del bitcoin, più bitcoin ci sono negli exchange più lievita il limite dei 21 milioni di bitcoin "in circolazione" in questo caso)

2) Non so come funzionano i servizi come XAPO, in pratico io possiedo o no i bitcoin che "acquisto"?
Cioè io compro i bitcoin e poi li deposito presso un conto XAPO che me li custodisce in cambio di una commissione?   
E se anche possiedo i miei bitcoin e XAPO si occupa di venderli per me ogni volta che io ho bisogno di spendere denaro, convertendoli immediatamente in euro presso un exchange, le fee che mi risparmia vengono scaricate sui commercianti come fanno adesso le banche con le carte di debito?
Quindi rinuncio ad alcune prerogative del sistema bitcoin (mi fido di XAPO come fosse una banca, e aggiungo un intermediario nel processo di gestione del mio denaro e di spesa dello stesso) per risparmiare sulle commissioni della blockchain che sono troppo alte per me? 
Forse come sistema può anche funzionare, ma a occhio è molto meno efficiente nel suo complesso. Sicuramente per molte persone può essere un modo per avvicinarsi al mondo bitcoin, visto che c'è qualcuno che ti aiuta a conservarli e a spenderli, ma perchè non aumentare semplicemente la dimensione del blocco per abbassare le fee?  Poi chi vuole usare XAPO lo usi pure, chi è in grado di pagare da solo lo possa fare risparmiando grazie a questa sua "abilità" di gestirsi i soldi da solo.

non è corretto dal punto di vista tecnico o morale ? perché il modo in cui il bitcoin è stato pensato è noto ma poi la realtà si traduce negli exchange che svolgono un ruolo principale nella mediazione, quello di XAPO era più per fare un esempio di vari potenziali business basati sul Bitcoin sovrapponibili all'uso classico a cui un utente è già abituato e che potrebbero attirarne di nuovi non so poi come operino se lo facciano sulle commissioni, sugli spread o la riserva frazionata.

qui mi allaccio i lightning network a quanto ho letto sarebbero immuni alla riserva frazionaria https://www.reddit.com/r/Bitcoin/comments/56ehi1/fractional_reserve_on_lightning_network/ immagino potrebbero portare anche a HUB/Exchange trasparenti sulle loro riserve.

Ho visto che oggi siamo a un quarto dei voti (25%). I miners pools che hanno aderito sono i soliti ma che adesso lo fanno tutti esplicitamente con una segnalazione 0x20000002. I nomi sono BTC china, ckpool, bitfury, slush.

https://coin.dance/blocks

Ora siamo al 20% nei blocchi effettivamente minati, e al 28.5% della potenza di hash.

La prima votazione è ormai andata, la seconda tornata parte dal blocco 439488+2016 = 441504, cioè tra poco più di 200 blocchi, ovvero tra 1 giorno e mezzo circa.

Nel momento in cui scrivo siamo arrivati al blocco 441290, quindi sono stati minati 1803 blocchi, di cui 407 blocchi con segnale di supporto a segwit (22,6%).

EDIT 04/12/2016 : Anche la seconda tornata è iniziata ma è anche già virtualmente finita.

Al momento infatti su 369 blocchi, 87 hanno segnalato la  disponibilità a segwit (solo il 23,58%!) , e 282 no (ricordo che per non far passare segwit bastano 101 blocchi contrari in ciascuna finestra di 2016). La percentuale dei sostenitori proprio non vuole decollare, altro che 95%, questo segwit sembra un grandissimo flop...

Per ora sembra proprio così, al momento siamo al 20.83%. Ma come già detto il problema non è tanto il fallimento del segwit, ma il fatto che anche le altre alternative non hanno avuto un grosso consenso, si rischia seriamente una stagnazione per molto tempo.

Che ne pensate di questo? https://bitcointalk.org/index.php?topic=1703390.0
è vero o è un fake?

An Error Has Occurred!
The topic or board you are looking for appears to be either missing or off limits to you.

mmh, link saltato.
Mi riferivo a questo comunque: http://www.newsbtc.com/2016/12/04/bitcoin-core-developers-work-new-2-mb-hardfork-proposal/

siccome nella vita ho imparato che sono i fatti che contano e non le parole,
e considerando che i miner segwit non l'hanno votato, XT non l'hanno votato, classic non l'hanno votato, unlimited non l'hanno votato...
il messaggio e' chiaro: a loro va bene cosi'.

Io la vedo così: astrattamente parlando utilizzerei sicuramente Unlimited, leggendo questo articolo (https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4#.qb4vzcqws) e quest'altro (https://medium.com/@g.andrew.stone/emergent-consensus-simulations-99604190fa31#.l0l5bdy8i) mi pare evidente che sia il client che attualmente meglio interpreti lo spirito del bitcoin.

Ma mettiamoci adesso per un momento nei panni di un miner: chi mina in questo momento sta guadagnando e i propri profitti sono legati indissolubilmente alla richiesta/giudizio del mercato, e qual è questo giudizio? Al momento l'andamento del prezzo ci dice che nell'ultimo anno la soddisfazione e le aspettative del mercato sono notevolmente cresciute, cioè al mercato così va bene (anche se forse potrebbe andare meglio). La base di utilizzatori bitcoin si sta ampliando, sono più le persone che entrano di quelle che escono, e il prezzo per entrare continua a salire.

Perchè un miner dovrebbe cambiare regole, votando ad esempio per una svolta tecnicamente complessa da decifrare, soprattutto nelle sue implicazioni, come è segwit? Mettendo così a rischio un guadagno al momento sicuro?
A me pare evidente che finchè io faccio soldi minando e il valore del btc continua a essere alto, non mi conviene cambiare, a meno che il mercato stesso (e lui per primo, non certo io!) non mi segnali che qualcosa non va (facendo diminuire il prezzo) e solo allora le cose potrebbero cambiare. Le prospettive sono talmente positive per i miner che nell'ultimo anno la potenza computazionale messa in campo da questi è quadruplicata, una cosa mai vista. Essi aumentano il loro rischio mettendo più soldi in un sistema che conoscono, non rischiano invece cambiando il sistema in qualcosa che non sanno come potrebbe evolvere.
Dal loro punto di vista la situazione attuale è che si aspettano di fare un sacco di soldi (per questo stanno investendo tanto, è il loro mestiere), mentre il nostro di utenti dovrebbe essere quello di manifestare un certo dissenso facendo calare il valore del btc.

Se nella realtà contano i fatti e non le parole:

1) i miner stanno investendo un sacco di soldi, ergo: scommettono su un andamento positivo del bitcoin e non vedono motivi per cambiare (a loro cosa interessa dei blocchi pieni e delle regole del consenso e del p2p? Finchè al mercato va bene, va bene anche a loro)

2) gli utenti a parole sono molto preoccupati: su questo forum e non solo molti sono preoccupatissimi per il futuro del bitcoin, per la decentralizzazione, ecc. ma cosa fanno in pratica? Continuano a holdare o a comprare nuovi bitcoin, cioè a investire sempre di più (altrimenti il prezzo non aumenterebbe). Secondo me chi è veramente preoccupato dovrebbe di logica vendere i propri btc, eppure in una fase di stallo sui vari fork tutti comprano. I "veramente" preoccupati sono solo una minoranza.

Quindi la sostanza è che nei loro comportamenti concreti sia miner che utenti giudicano molto favorevolemente il bitcoin. Forse noi ci facciamo tanti problemi su libertà, p2p, decentralizzazione, magic number, altcoin varie, ecc. e ci dimentichiamo chi sono i concorrenti di btc e quanto sono messi male: basti pensare ad esempio che in quei paesi in via di sviluppo con monete nazionali ridicole quanto il nostro vituperato bitcoin con blocchi limitati a 1 mega rimanga di gran lunga più appetibile delle loro monete nazionali, ho letto che btc viene pagato anche a +30% del prezzo di mercato.


Vogliamo veramente che si cambi? Auguriamoci allora un btc a 300 dollari (con reward a 12,5 btc, non a 25 come era qualche mese fa), vedrai che ci si muoverà in quel caso, e pure di fretta, ma non a 700/800 dollari * 12,5 btc a blocco ...

si infatti la realta' ci dice come si stanno disponendo le cose:

l'oligarchia di bitcoin (i miner)  stanno spingendo verso la strada che a loro conviene, e questa strada e':
bitcoin deve essere un serbatoio di valore (quindi di maggior prezzo possibile)
con poche transazioni sempre piu' onerose.

quindi ci si allontanera' sempre di piu' dal concetto di valuta, (tipo dollaro)
e si avvicinera' sempre piu' al concetto di bene rifugio (tipo oro)
con un grosso vantaggio rispetto all'oro che il trasporto (transazione)
sara' sempre piu' economico, immadiato, sicuro, senza formalita'
rispetto al trasporto dello stesso valore in oro.

E anche l'utenza diventra' sempre piu' di holder ossia di gente che
lo usa come bene rifugio piuttosto che come valuta.

A proposito mi autocito:

Non darei per scontato quindi che la strada vada per forza verso un concetto di bitcoin come riserva di valore,
penso infatti che:

1) il suo valore rimanga legato comunque alla sua proprietà di mezzo di pagamento, per questo è nato (se fosse poco utilizzato come pagamento alla fine perderebbe interesse,  con la discesa dei compensi per blocchi fra qualche anno e poche transazioni le fee non sarebbero sufficienti per i miner, quindi il sistema non reggerebbe e perderebbe di valore, alla fine i miner stessi voterebbero qualche cambiamento per non perdere soldi)

2) nel mondo ci sia forte richiesta di mezzi di pagamento liberi (vedi adesso India ma anche tanti altri)

3) nel confronto attuale tra le caratteristiche di bitcoin e quelle di molte monete tradizionali al momento bitcoin è già nettamente in vantaggio (nonostante esso sia ancora migliorabile), inoltre btc è la prima criptovaluta della storia, tutto ciò gli dà qualche vantaggio competitivo allo stato attuale (e spiega la lentezza nell'adozione di provvedimenti migliorativi). 
Ma questo vantaggio attuale non può continuare all'infinito, esiste sempre la possibilità di fork, contenziosi o meno, ci sono le altcoin, quindi rischia, se non nel brevissimo, ma nel medio termine di perdere terreno a vantaggio di qualche altra valuta.

beh si parliamo di un sistema dinamico e inoltre ancora estremamente sperimentale...

secondo me date le condizioni attuali Bitcoin si sta orientando come ho scritto sopra,
poi gli equilibri possono variare e le cose cambire... anzi lo faranno di sicuro

quello che vedo e' che per ora la direzione la danno i Miner e la stanno dando verso
l'obiettivo che ho descritto. poi puo' sempre nascere una nuova crypto, o entrare in
campo un'altra forza che  scombina il tavolo, ovvio.

Da quello che ho capito sarà sempre così, i miner sono gli unici in grado di scrivere su quel libro (la blockchain) che è l'unica cosa che conta. Gli utenti la useranno finché sarà sicura. I posteri leggeranno nella blockchain la storia e il resto saranno solo chiacchiere e distintivo :)

Ecco lasciamo tutto cosi sono d accordo con i miner

I miner sono degli "abilitatori" (a nuove funzionalità, nuove regole), e il loro guadagno proviene dal token che creano ... e il valore del token è il risultato di come viene apprezzato sul mercato, nel senso, se alla maggioranza degli utilizzatori piace come funziona Bitcoin.

Ci sono più proposte ora, e i miner non sono sicuri del risultato, temono appunto di fare un azione sbagliata e di uccidere la loro fonte di guadagno ... per questo stanno aspettando.

Diversi miners dicono che si orienteranno come si orienterà la maggioranza.

Litecoin ha adottato il segwit?

https://www.reddit.com/r/litecoin/comments/5i2v64/is_litecoin_implementing_segwit/

Dicono di sì, che lo abbia già adottato o che manchi poco.


EDIT:

Pare che i miners coinvolti nei litecoin siano gli stessi, più o meno, di quelli coinvolti nei bitcoin.

https://bitcoinmagazine.com/articles/which-altcoins-are-implementing-segwit-1481577969

Aaron van Wirdum e Kyle Rorpey sono due giornalisti molto di parte (come sono anch'io del resto ;) ), li considero due propagandisti che distorcono la realtà.
Quindi, sempre secondo il mio parere, di prendere con le pinze ciò che scrivono.

di questo passo degli sforzi per il segwit ne beneficeranno tutte le altcoin con un team decente che sappia aggiornare il codice e non il bitcoin, che beffa  :-\