Topic: È Partito il soft fork per l'aumento del block size - page 2. (Read 7096 times)

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.

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 ?

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


 

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.

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.

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.

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

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

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.

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.

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/

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

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

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

https://coin.dance/blocks

cosa intendono con "locked in"?

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

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 .

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)

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.

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.