You got PM

Do you accept only btc?

Dopo aver calcolato la distribuzione teorica dei tempi di produzione dei blocchi :  
https://bitcointalk.org/index.php?topic=1665779.msg16858506#msg16858506 mi sono un po' appassionato alla cosa e stavo cercando di verificare come nella storia della blockchain siano andate effettivamente le cose.

Cosa voglio fare? In sostanza aggiornare i dati di questo post --> https://www.reddit.com/r/Bitcoin/comments/1vkp1x/what_is_the_longest_time_between_blocks_in_the/ di due anni fa, dove si dà questa tabella:

21445-21446     23574
74637-74638     24676
19725-19726     24907
15047-15048     25376
19564-19565     25996
21388-21389     28124
20348-20349     29325
20363-20364     30013
20431-20432     30425
16489-16490     30682
27-28                 30884
19721-19722     37536
21437-21438     38219
19723-19724     47127
20188-20189     60203
16591-16592     73782
14-15                 87157
16563-16564     90390
15323-15324     90532
0-1                    463160

A sinistra il numero dei blocchi, nella colonna di destra l'intervallo di tempo tra le apparizioni di due blocchi consecutivi (in secondi).
Ovviamente i dati riguardanti blocchi così vecchi sono poco significativi, nei primi tempi non c'era quasi nessuno che minava, ecc.

Il più delle volte il retarget ha aumentato la difficoltà poichè la capacità computazionale della rete è stata quasi sempre tale da permettere di minare un blocco in media in meno di 10 minuti.  Se si va qui -> http://www.wolframalpha.com/input/?i=seconds+between+January+3,+2009+and+November+21,+2016 si può notare che la blockchain ha una vita (in secondi) di 2.487x10^8s, mentre ha una vita in blocchi di 439943. Quindi il valor medio reale finora è 248,7 milioni di secondi / 439944 = 565 secondi, tempo medio reale per minare un blocco finora, ovvero ben 35 secondi di media in meno rispetto al valor medio prefissato.

Ora che dati guardare? Il timestamp dei blocchi non è per niente affidabile, i miner possono scriverci quello che vogliono, quindi il meglio che si possa fare è affidarsi a un servizio esterno che sia sempre o quasi up e che registri in modo autonomo il tempo di arrivo di ogni blocco  (non esiste un tempo univoco in un sistema decentralizzato - per questo esiste la blockchain - ma almeno l'intervallo di tempo tra due arrivi in un punto preciso della rete ha più senso del timestamp dell'header dei blocchi).

Ho scritto allora un piccolo script in python che funziona appoggiandosi alla API di blockcypher --> https://www.blockcypher.com/dev/bitcoin/

Ho iniziato a scansionare i blocchi dal numero  336257, perchè è da quel momento che verosimilmente blockcypher ha iniziato a registrare il tempo effettivo di arrivo (il numero 336257 corrisponde al 28 dicembre 2014, ore 6.06.50, prima di quella data ci sono solo i classici valori dell'header del blocco).

Al momento ho scansionato 26000 blocchi (6 mesi circa, fino al 22 giugno 2015), questi sono i 20 più lenti:


In particolare  solo lo 0,19% ha superato l'ora, contro lo 0,25% previsto dalla teoria.
     
    L' 1,585% ha superato i 40 minuti, contro il 1,83% previsto dalla teoria.

Ricordo infatti che la distribuzione teorica era:

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




Perchè ne ho scansionati così pochi?
Il problema è che c'è un limite di 200 richieste/ora e 2000 richieste/giorno al loro server  

Per poter fare la scansione degli oltre 100k blocchi che mi mancano ad arrivare a oggi (gli ultimi 2 anni) mi ci vorrebbero almeno 50 giorni! Se però pago un bel po' di soldi mi aumentano il limite, peccato, mi sarebbe piaciuto verificare la distribuzione dei tempi.

Qualcuno conosce delle API fornite da qualche servizio affidabile che permettano quindi un'interrogazione "esterna" (ovviamente in questo caso non ha senso lavorare con la mia personale blockchain in locale, in quanto non vi sono presenti i dati che mi interessano) di queste dimensioni senza far pagare nulla o quasi nulla?

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


 

1. HostFat
2. achow101

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

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.

Quello che gbianchi cercava di dirti è che molti, come il sottoscritto, sono entrati in questo mondo pensando (a questo punto a torto) di entrare in una rete "democratica" dove ogni cpu (intesa come singola persona) potesse dire la sua o in quanto miner o almeno in quanto full node.

La realtà è (o sarebbe meglio dire è sempre stata) che questa rete è una rete costituita per e da *miner, nodi di servizi e commercianti, poiché, come dice Satoshi nel suo paper, la rete bitcoin nasce innanzitutto per risolvere il problema della sicurezza di coloro i quali ricevono pagamenti via internet, cioè vendono i loro servizi/merci in cambio di denaro, per tutelarli dal chargeback. Il concetto di **trustless è riferito soprattutto a loro, non alla maggioranza degli utenti che non hanno un vantaggio economico evidente nel mantenere un full node (i semplici utenti da questo sistema bitcoin possono ricavare vantaggi solo in modo indiretto, ad esempio se parte della diminuzione dei costi dei commercianti dovuti all'eliminazione del chargeback  si riverberasse in un abbassamento dei prezzi dei loro prodotti).

In questo momento delicato in cui nel mondo bitcoin si devono prendere alcune decisioni di indirizzo, si evidenzia ancora di più come il sistema non sia democratico (e magari non ha mai preteso di esserlo ma molti, me compreso, avevano capito che fosse così, e forse nelle sue fasi iniziali realmente lo era, e questo ha generato il fraintendimento).
Io (come gbianchi) ho tenuto in piedi un full node pensando potesse servire alla rete, visto che almeno nel mio caso non c'era alcun interesse economico dietro né ritorno di alcun tipo. In questo periodo in cui si votano dei cambiamenti però constato (anche se avrei dovuto già saperlo) che io con il mio full node non partecipo in alcun modo  al processo di decisione riguardo a nessun soft fork tipo segwit.
Quindi si constata semplicemente che non si tratta di una "democrazia diretta", nulla di più, il "meccanismo di consenso" a cui allude Satoshi non riguarda assolutamente la stragrande maggioranza degli utenti.
Forse solo nel caso degli hard fork i full node possono dire la loro e condizionare direttamente o indirettamente il comportamento dei miner, ma nel caso dei soft fork i full node vengono tranquillamente ignorati, è un fatto tra miner.

Non c'è da meravigliarsi allora che in un vuoto di potere "democratico" del genere i tecnici (i developer) provino a prendere decisioni di politica monetaria, chi altri dovrebbero prenderle queste decisioni? Il libero mercato?

Gli utenti che hanno in mano le azioni (i bitcoin) di questa azienda sono trattati come ne fossero semplicemente i clienti, non possono partecipare a nessuna assemblea, poiché gli azionisti che hanno diritto di voto sono solo i miner (i quali hanno bisogno solo che il sistema funzioni, non sono direttamente interessati alla qualità del sistema, essi sono incentivati alla salvaguardia della rete solo in quanto sono retribuiti in bitcoin ma sono pochi e non hanno le competenze probabilmente per proporre qualcosa di tecnicamente valido).
Mi pare inevitabile che allora chi ha le mani in pasta nel codice di Core abbia il vero potere. E questi developer non sono pagati (almeno ufficialmente) dalla rete, quindi sono fra tutte le figure (miner, full node, clienti, dev.) i meno incentivati (economicamente) a comportarsi bene.
In sostanza non si può dire che un'azienda è una democrazia diretta (se qualcuno lo pensa) solo perché l'azienda cerca di andare incontro ai desideri del mercato cercando di indirizzare il proprio lavoro secondo i desiderata dei clienti, potenziali e non: è il consiglio di amministrazione che decide e solo i miner possono parteciparvi.

Ti assicuro che quanto ho appena scritto non è scontato, moltissimi si sono avvicinati al mondo bitcoin pensando di poter direttamente contribuire e influenzare il corso di sviluppo della moneta e delle norme che la regolano, non sono entrati con lo spirito di un cliente che entra in un'azienda per ammirarne i prodotti e basta, ma volevano parteciparvi direttamente, di qui la delusione negli ultimi tempi di molti.




Personalmente quello che mi preoccupa di più non sono né hard disk né banda, ma RAM, soprattutto in prospettiva in un futuro prossimo --> http://gavinandresen.ninja/utxo-uhoh  .
Ma capisco anche che il "trustless" debba avere un prezzo, se voglio poter controllare qualcosa da solo poi un certo lavoro devo pur farlo, non posso sperare sia gratis.  Se dovessi ricevere molti pagamenti sicuramente me lo metterei su un full node, altrimenti sarebbe solo un hobby.

Nel paper di Satoshi c'è un problema terminologico:  lui si riferiva al termine "nodi" intendendo gli attuali full node + miner. (Quando scriveva queste cose probabilmente lui riassumeva in sé tutte e 4 le figure, miner, full node, utente, developer  )
 
In quel passo allora Nakamoto sosteneva effettivamente che è il voto dei miner che conta o quello degli utenti/full node?  Dal momento che si parla di "votare con la cpu" probabilmente alludeva ai miner e al loro lavoro di assemblaggio dei blocchi.
In che modo invece gli utenti (o perlomeno i full node) potrebbero votare/ fare sentire la propria voce quando si propone un soft fork tipo segwit? Nel caso di un hard fork se scelgono di utilizzare un client software piuttosto che un altro possono dare in questo modo un'indicazione indiretta del tipo di blocchi (e di conseguenza di nuove regole) che sarebbero disposti ad accettare, ma nel caso di un soft fork tipo segwit?
Insomma il meccanismo di consenso a cui si riferiva Satoshi funziona (ed era così previsto sin dall'inizio) solo per i miner? Non mi sembra chiaro.



Rileggendo il paper di Satoshi egli in effetti parla esplicitamente proprio delle categorie che citi tu come principali candidati a essere componenti ("full network node") della rete peer to peer, mentre prevede per i semplici "user" il SVP:


A questo punto allora è un po' un fraintendimento che il sistema bitcoin nasca come mezzo "peer to peer" nel senso di "rendere tutti gli attori economici uguali", in realtà è un sistema in cui i pari sono solo coloro che muovono una quantità di denaro consistente e che quindi hanno interesse/possono permettersi di mantenere un full node, tutti gli altri, i semplici utenti che non muovono un controvalore di decine/centinaia di migliaia di euro in bitcoin all'anno, si accontentano di una verifica di pagamento semplificata che richiede quindi di fidarsi di qualcun altro. Ed è solo a questo punto che il numero di full nodi presenti nella rete diventa importante (più sono meno è facile ingannare l'utente che usa SPV).

Faccio un commento in italiano ai post di hostfat sopraccitati (e al thread su questo forum nella sezione internazionale  https://bitcointalk.org/index.php?topic=1675960.0).

Hostfat in pratica sostiene che i developer di Core, non avendo a differenza dei miner un incentivo chiaro e pubblico che li spinga a lavorare per l'integrità del sistema, costituiscano un'anomalia che va a contraddire il cosiddetto principio "trustless": di fatto noi utenti dobbiamo fidarci di questi sviluppatori e delle non sempre chiare motivazioni che li spingono a proporre modifiche che prevedono l'introduzione di numeri "magici" (cioè calati dall'alto) tipo il 75% di sconto per le transazioni segwit. Questo modo di procedere ricorda molto il caso tradizionale delle banche centrali con le monete fiat.

Sono d'accordo sul fatto che non sia possibile per noi utenti conoscere le vere motivazioni degli sviluppatori di Core (non sto dicendo che siano animati sicuramente da "cattive" intenzioni, ma che credere il contrario richieda appunto un atto di fiducia senza basi). Questo succede perché non è chiaro appunto il loro ruolo economico nel sistema, cioè quali sono i loro incentivi (per i miner invece questi incentivi sono chiari).

Secondo me però c'è anche un'altra componente del mondo bitcoin che mostra la stessa ambiguità, cioè che non ha un ruolo economico ben definito: i full node (e sono guarda caso i full node che i developer hanno tirato in ballo per motivare la loro riluttanza a innalzare il limite di 1 mega).
Il motivo dei toni del dibattito dell'ultimo anno intorno alla questione del limite di 1 mega si possono quindi far risalire anche al fatto che né i developer né i full node hanno un ruolo economico ben definito, essi sono attori economici essenziali del sistema che però non dichiarano esplicitamente quali sono i loro reali incentivi economici (motivazioni), e quindi danno adito a qualunque sospetto, soprattutto nel momento delicato in cui bisogna scegliere se modificare un parametro sensibile come quello che regola la velocità di movimento del denaro nella rete.

Riassumendo: ci sono quattro attori fondamentali nel mondo bitcoin: gli utenti, i miner, i full node, i developer. Di questi ultimi ha già parlato abbondantemente hostfat. Vediamo gli altri.

Il bitcoin nasce per consentire a noi utenti di gestire in modo autonomo e libero il nostro denaro, per poterne disporre insomma a nostro piacimento (il tradizionale denaro fiat invece a conti fatti non è nemmeno realmente di nostra proprietà).

Poiché il denaro contante qual è bitcoin vuol dire essenzialmente fiducia che i nostri token siano validi, fiducia cioè che i miei token certifichino con assoluta sicurezza che io abbia effettivamente ricevuto un credito (precondizione necessaria affinché possano essere riconosciuti a sua volta da qualcun altro e accettati come mezzo di pagamento), il punto chiave è trovare un modo appunto per garantire la validità dei nostri token; con bitcoin per fare questo si implementa un modello "trustless"*, ovvero un modello che a differenza di quanto accade nel tradizionale mondo fiat non si basa sulla fiducia in un'autorità centrale ma distribuisce la fiducia su una numerosa rete di attori; è il sistema decentralizzato nel suo insieme il "garante" del bitcoin)  (*NB:  trustless quindi vuol dire che non è richiesta fiducia in nessuno in particolare, non in nessuno tout court; ma c'è anche chi dà un significato più restrittivo a questo termine, come nel caso dei full node).

Gli utenti finali dovrebbero essere quindi i veri protagonisti, e la loro voce si fa sentire per mezzo delle scelte che fanno: il numero di bitcoin che utilizzano e muovono attraverso le transazioni in rete determinano il valore della rete stessa, in pratica la voce degli utenti si esprime attraverso il libero mercato.

I miner forniscono invece un servizio alla rete mediante la loro attività di assemblaggio dei blocchi e per questo sono remunerati. Da sottolineare che sono remunerati dalla rete, cioè in sostanza dagli utenti, poichè il valore del loro lavoro dipende dal valore che alla rete/i bitcoin viene conferito dagli utenti stessi.
I miner sono incentivati per questo a mantenere l'integrità del sistema e delle regole che lo amministrano (conviene loro che tutto funzioni regolarmente)

Quindi è chiaro il ruolo degli utenti e dei miner.

I full node sono secondo me il punto delicato: chi e soprattutto cosa sono, qual è la loro vera funzione?
In prima battuta essi rappresentano la possibilità di una verifica indipendente della regolarità di ogni transazione bitcoin, e quindi in linea teorica ogni utente, se lo vuole, può essere un full node.  
Se i full node fossero solo questo, il problema del limite della dimensione dei blocchi per molti utenti sarebbe relativo: il fatto che all'aumentare della dimensione crescano le risorse hardware necessarie per verificare la regolarità delle transazioni si potrebbe accettare come inevitabile conseguenza dell'ingrandirsi della rete, un po' come nessuno può gridare alla scandalo perché un codice open source come Linux diventa sempre più grande e complesso da controllare (l'importante è che ci sia la possibilità per chi ha mezzi e motivazione di controllarlo!).  Se però si pensa che trustless voglia dire che io posso non fidarmi di nessuno (versione "forte" del significato di trustless) e fare tutto da solo, blocchi grandi vuol dire che io questa possibilità in prospettiva non ce l'ho più.  Ma non basta.

La natura dei full node è ibrida, non sono solo un modo per consentire al singolo utente di non fidarsi di nessuno e di controllare autonomamente la validità dei token che riceve, essi costituiscono anche la rete stessa di raccolta, filtraggio, verifica e trasmissione ai miner delle transazioni stesse, nonché di ricontrollo a posteriori della validità delle stesse transazioni dopo che i miner le hanno messe nei blocchi.

E qui nasce il problema: passi che il lavoro dei miner ormai sia sempre meno decentralizzato (è il prezzo da pagare per una migliore efficienza del sistema, ma siamo comunque garantiti dall'evidente incentivo economico che essi hanno), ma se con l'aumento della dimensione dei blocchi renderemo meno decentralizzato anche il lavoro di raccolta e verifica delle transazioni (lavoro che si potrebbe appaltare così solo a pochi come già avviene adesso per quello dei miner) avremo alla fine due ordini di problemi:

1) la verifica indipendente da parte del singolo utente diventerà in breve tempo virtualmente impossibile (meno decentralizzazione meno trustless in senso forte)

2) i full node non hanno incentivi economici, quindi come garantirsi che il loro lavoro sia regolare? Se almeno fossero in tanti (versione debole del concetto di trustless, più decentralizzazione più trustless, sarebbe più facile fidarsi, ma se diventeranno pochi e continueranno a rimanere senza incentivi - come i developer! - perché noi dovremmo  fidarci?)  

Già adesso quando la memoria dei full node si riempie (da notare che più transazioni al secondo vuol dire anche molte più verifiche e UTXO che crescono sempre più velocemente, quindi le risorse impiegate crescono molto --> https://www.kaiko.com/analytics/post/an-in-depth-guide-into-how-the-mempool-works) i full node sono costretti a impiegare mezzi come l'impostazione di una soglia minima di fee (altri numeri magici, anche se locali e non collettivi!)

Cioè non c'è solo un problema dei miner che con il blocco piccolo lasciano fuori le transazioni meno generose nei loro confronti, spesso anche i full node stessi, se non riescono a elaborare tutte le transazioni che ricevono, devono scremare con qualche criterio. Anzi direi che mentre dal punto di vista dei miner assemblare blocchi da 1 mega o da 8 mega non cambia molto come lavoro, invece se si consentisse alla rete di crescere così velocemente i full node sarebbero sicuramente messi in difficoltà e quindi diminuirebbero (il principio iniziale della rete era che il lavoro di assemblaggio dei miner fosse pesante perché costituisse un proof of work, mentre il lavoro di controllo e verifica di questo lavoro doveva essere molto leggero, ora anche il lavoro generale di controllo delle transazioni sta diventando sempre più pesante, perché esso dipende dal numero di transazioni al secondo, mentre quello dei miner è sostanzialmente indipendente dal numero di tx al secondo, e si tratta per i full node di lavoro non remunerato!)
 
Questo mi sembra che sia un problema reale, indipendentemente se si è pro o contro Core.

Quindi non solo i developer, ma anche i full node costituiscono in questo momento il punto delicato del sistema.

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 .

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.

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

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

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

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

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?

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.

Grazie per la segnalazione, corretto! 

Il punto 1) non implica automaticamente anche il punto 2)?
Io ho il pieno controllo delle chiavi private se e solo se le posso esportare, cioè se sono in grado di ottenerle in "chiaro", di vederle, copiarle/esportarle, cioè farci quello che voglio. 

Se invece le chiavi sono "nascoste" dentro un wallet che ho sul cellulare ad esempio, ma non posso nemmeno visualizzarle, io non direi che ho il reale controllo delle chiavi private... in quel caso il pieno controllo ce l'ha solo il programma che le gestisce (e che me le nasconde).