È Partito il soft fork per l'aumento del block size

[Stemby]

I soft fork rendono non valide situazioni valide (o non standard) in precedenza, gli hard fork rendono non valide cose che prima non erano valide.

Fixed 

(avevi scritto due volte la stessa cosa)

Ciao!

[arulbero]

I soft fork rendono non valide situazioni valide (o non standard) in precedenza, gli hard fork rendono non valide cose che prima non erano valide.

Fixed 

(avevi scritto due volte la stessa cosa)

Ciao!

Grazie per la segnalazione, corretto! 

[il_minatore]

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

Grazie

[Sandro kensan]

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

[gbianchi]

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

[arulbero]

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.

[Sandro kensan]

non ho capito bene cosa intendano con "explicit mining pool support", (le barre in alto)

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.

[Jack Liver]

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

[arulbero]

non ho capito bene cosa intendano con "explicit mining pool support", (le barre in alto)

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.

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

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

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?

[Sandro kensan]

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

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.

[arulbero]

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/

What is version bits BIP9?

The version bits BIP9 system is a way to introduce backward compatible rule changes to the Bitcoin consensus rules, known as a soft fork.

version bits allows miners to signal that they can validate the soft fork rules. It also allows for up to 29 soft forks to be proposed concurrently

....
version bits does not require activation, it’s simply a way for miners to signal readiness for a soft fork by setting bits in the block header nVersion field.
....
The Bitcoin network retargets mining difficulty every 2016 blocks; at this time version bits will look at the window of the previous 2016 blocks to see how many blocks signal for a given soft fork. If 95% of the blocks signal readiness for the soft fork, the state changes from [STARTED] to [LOCKED_IN].
....

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

IsSuperMajority() or ISM for short, is a legacy soft fork trigger that activates new rules once 950 out of 1000 blocks are mined which signal the new block version.

An IsSuperMajority() soft fork will orphan all blocks with previous version after activation. For example, if the current version is 4, and the next soft fork introduces version 5 blocks, then after activation is reached (950/1000 blocks), nodes will reject all version 4 blocks.

Once a version bits soft fork reaches activation, nodes will simply begin enforcing the new rules, and will NOT orphan a non-signalling block unless it violates the new rules.

ISM() looks at the previous 1000 blocks on a rolling basis; version bits looks at the previous 2016 block once each time the mining difficulty retargets.

ISM() soft forks do not expire. version bits soft forks can only activate between the start time and the timeout.

[picchio]

..
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'e' qualcosa che impedisce che si facciano due votazioni in contemporanea o sovrapposte in parte?

[arulbero]

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

When no soft forks are being signalled, miners should set the block version field to 0x20000000.

To signal readiness for soft fork(s), miners should set the relevant version bit(s) together with 0x20000000. This should only be done after the soft fork’s start time.

The bits should be unset if either the soft fork activates, or reached [FAILED] state.

For example:

“alice” soft fork uses bit 0, i.e. 0x1 + 0x20000000
0    0    1    0    0    …    0    0    0    0    0    0    0    0    0    1

“bob” soft fork uses bit, 1, i.e. 0x2 + 0x20000000
0    0    1    0    0    …    0    0    0    0    0    0    0    0    1    0

To signal both soft forks at once, use 0x20000003 (i.e. 0x1 + 0x2 + 0x20000000*)
0    0    1    0    0    …    0    0    0    0    0    0    0    0    1    1

note if one is activated before the other, you must unset the relevant bit and continue signalling the other. IF one fails to activate and the timeout expires, you should also unset the bit.

[Sandro kensan]

ISM() looks at the previous 1000 blocks on a rolling basis; version bits looks at the previous 2016 block once each time the mining difficulty retargets.

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

[arulbero]

ISM() looks at the previous 1000 blocks on a rolling basis; version bits looks at the previous 2016 block once each time the mining difficulty retargets.

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.

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.

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.

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ù!)

"segwit": {
            "status": "defined",
            "startTime": 1479168000,
            "timeout": 1510704000

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

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

Questo non lo so  
Forse adesso lo so:

Activation for the segwit soft fork is being managed using BIP9 versionbits. Segwit’s version bit is bit 1, and nodes will begin tracking which blocks signal support for segwit at the beginning of the first retarget period after segwit’s start date of 15 November 2016. If 95% of blocks within a 2,016-block retarget period (about two weeks) signal support for segwit, the soft fork will be locked in. After another 2,016 blocks, segwit will activate.

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

[Sandro kensan]

"segwit": {
            "status": "defined",
            "startTime": 1479168000,
            "timeout": 1510704000

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.

[redsn0w]

"segwit": {
            "status": "defined",
            "startTime": 1479168000,
            "timeout": 1510704000

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.

[arulbero]

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

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.

[gbianchi]

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)

[arulbero]

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

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 .