HostFat (OP)
Moderator
Legendary
 Offline
Activity: 4242
Merit: 1203
I support freedom of choice
|
 |
June 04, 2015, 09:45:41 PM
Last edit: August 21, 2016, 03:12:21 PM by HostFat |
|
|
|
|
|
|
jkoin
|
|
June 05, 2015, 07:30:42 AM |
|
Comunque a me 1 mb sembra poco e 20 mb sembrano troppi (al momento). Se fosse per me cablerei nell'algoritmo questa regola:
Impostazione iniziale --> Dimensione massima blocchi = 1MB;
Ad ogni nuovo anno il sistema aumenta la dimensione massima di un altro mega. A partire da quest'anno, cosi si forza il network a non crescre troppo velocemente ma di diffondersi lentamente ma inesorabilmente, e si da il tempo all'evoluzione tecnologica dei sistemi di storage di continuare a crescre più velocemente delle richieste di spazio della blockchain...cosi continuerà ad essere gestibile da molti un full node...
|
|
|
|
|
HostFat (OP)
Moderator
Legendary
Offline
Activity: 4242
Merit: 1203
I support freedom of choice
|
|
June 05, 2015, 07:39:30 AM |
|
Se dovessi pagare 1 euro per ogni transazione Bitcoin, 2 mega ti sembrerebbero troppi o troppo pochi?
In base a cosa dici che è tanto o poco un valore?
|
|
|
|
|
jkoin
|
|
June 05, 2015, 08:40:41 AM |
|
Se dovessi pagare 1 euro per ogni transazione Bitcoin, 2 mega ti sembrerebbero troppi o troppo pochi?
In base a cosa dici che è tanto o poco un valore?
E' una questione di dimensionamento e di accontentare sia chi preme per avere blocchi grandi sia chi vorrebbe mantenere blocchi piccoli. Se guardi il grafico delle transazioni totali delle rete bitcoin siamo ancora a circa 100 mila al giorno (in lento ma costante aumento e ben presto un mega sarà poco) a fronte di un potenziale massimo di circa 700 mila (con un mega di max attuale). Direi che passare subito a 20Mb sarebbe sovradimensionare, aumentare di 1Mb all'anno potrebbe essere la scelta giusta per rendere continuativo e senza intoppi il lento ma inesorabile aumento delle transazioni e della diffusione del network. Poi maggiore è la dimensione della blockchain minore è la decentralizzazione, tuttavia sappaiamo che di anno in anno il costo dello storage diminuisce quindi un incremento lineare di anno in anno potrebbe essere il giusto compromesso. Inoltre un pattern di aumento della dimensione massima dei blocchi cablato nell'algoritmo ci eviterebbe futuri hard-fork quando anche i 20Mb saranno pochi. Un hard fork sarà necessario facciamo in modo che sia uno solo: mettendo nell'algoritmo un aumento prestabilito allo scoccare di ogni anno. |
|
|
|
|
HostFat (OP)
Moderator
Legendary
Offline
Activity: 4242
Merit: 1203
I support freedom of choice
|
|
June 05, 2015, 09:29:43 AM |
|
Se dovessi pagare 1 euro per ogni transazione Bitcoin, 2 mega ti sembrerebbero troppi o troppo pochi?
In base a cosa dici che è tanto o poco un valore?
Se guardi il grafico delle transazioni totali delle rete bitcoin siamo ancora a circa 100 mila al giorno (in lento ma costante aumento e ben presto un mega sarà poco) a fronte di un potenziale massimo di circa 700 mila (con un mega di max attuale). Direi che passare subito a 20Mb sarebbe sovradimensionare, aumentare di 1Mb all'anno potrebbe essere la scelta giusta per rendere continuativo e senza intoppi il lento ma inesorabile aumento delle transazioni e della diffusione del network. Attualmente il limite è un 1 MB, ma che non è mai stato raggiunto, quindi, 20 mega, che problema ci sarebbe? Sarebbero per lo più vuoti, ma pronti a riempirsi nel caso ce ne fosse bisogno per un eventuale ondata di utenza imprevista. Poi maggiore è la dimensione della blockchain minore è la decentralizzazione, tuttavia sappaiamo che di anno in anno il costo dello storage diminuisce quindi un incremento lineare di anno in anno potrebbe essere il giusto compromesso. Le due affermazioni si annullano. Quanto aumenta la centralizzazione e quanto calano i costi? Qui si tratta di numeri direi, che non vedo. Inoltre un pattern di aumento della dimensione massima dei blocchi cablato nell'algoritmo ci eviterebbe futuri hard-fork quando anche i 20Mb saranno pochi. Un hard fork sarà necessario facciamo in modo che sia uno solo: mettendo nell'algoritmo un aumento prestabilito allo scoccare di ogni anno.
Su questo in generale mi trovo ben più d'accordo. |
|
|
|
|
jkoin
|
|
June 05, 2015, 09:54:47 AM |
|
Poi maggiore è la dimensione della blockchain minore è la decentralizzazione, tuttavia sappaiamo che di anno in anno il costo dello storage diminuisce quindi un incremento lineare di anno in anno potrebbe essere il giusto compromesso. Le due affermazioni si annullano. Quanto aumenta la centralizzazione e quanto calano i costi? Qui si tratta di numeri direi, che non vedo. Be falli tu i numeri, 1 Mb all'anno è buttata li tanto per buttarla, possiamo anche fare 2Mb all'anno o qualsiasi altro numero possa aver senso dopo un'analisi accurata (che ora non ho fatto ho solo espresso un concetto). Scegli tu il pattern, il concetto che voglio far passare è che la dimensione massima può essere ragionevolmente aumentata ogni anno dato che ogni anno cala il costo dello storage. Sul "quanto" aumentarla si può ovviamente discutere... |
|
|
|
|
HostFat (OP)
Moderator
Legendary
Offline
Activity: 4242
Merit: 1203
I support freedom of choice
|
|
June 05, 2015, 10:24:49 AM |
|
Qua ci sono un po' di dati raccolti da Gavin http://gavinandresen.ninja/ |
|
|
|
alch1mista
Sr. Member
Offline
Activity: 455
Merit: 251
blockchain longa, vita brevis
|
|
June 05, 2015, 11:58:22 AM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
mi sembra l'opzione migliore, anche se certamente quello che non può essere contenuto in blocchi di dimensione massima bassa (1 mb o poco più) potrebbe essere gestito attraverso gli scambi off chain e le altcoin.
che poi non sarebbe male avere un mercato più competitivo di alt, fatta eccezione per le scamcoin pump&dump.
|
Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. |
|
|
picchio
Legendary
Offline
Activity: 2506
Merit: 1120
|
|
June 05, 2015, 12:34:13 PM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
...
Stavo pensando ad una cosa simile, come per la difficoltà, un qualcosa che si adatta alle esigenze della rete nei giorni/mesi precedenti. |
Waves mi piaceva ora non più.
|
|
|
|
FaSan
|
|
June 05, 2015, 03:17:47 PM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
...
Stavo pensando ad una cosa simile, come per la difficoltà, un qualcosa che si adatta alle esigenze della rete nei giorni/mesi precedenti. L' hardfork ci sarebbe comunque inquanto i vecchi client non accetterebbero la dimensione dinamica. Quindi non cambia nulla. Non sono un fan di Andresen, ma sinceramente a me non me pò fregar di meno della dimensione del blocco. FaSan |
|
|
|
|
picchio
Legendary
Offline
Activity: 2506
Merit: 1120
|
|
June 05, 2015, 04:15:14 PM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
...
Stavo pensando ad una cosa simile, come per la difficoltà, un qualcosa che si adatta alle esigenze della rete nei giorni/mesi precedenti. L' hardfork ci sarebbe comunque inquanto i vecchi client non accetterebbero la dimensione dinamica. Quindi non cambia nulla. FaSan Ce ne sarebbe uno solo e non uno ad ogni cambio di dimensione del blocco. Non sono un fan di Andresen, ma sinceramente a me non me pò fregar di meno della dimensione del blocco.
Io non ho opinioni in merito. A mio avviso BTC non puo' e non deve contenere tutte le transazioni del mondo, non ha senso che io autentichi o sappia che Tizio ha comprato il pane a Caio in Giappone il tal giorno alla tal ora ... però potrebbe essere utile poter memorizzare qualche dato in più ... se non crea problemi di sicurezza. |
Waves mi piaceva ora non più.
|
|
|
alch1mista
Sr. Member
Offline
Activity: 455
Merit: 251
blockchain longa, vita brevis
|
|
June 05, 2015, 04:40:43 PM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
...
Stavo pensando ad una cosa simile, come per la difficoltà, un qualcosa che si adatta alle esigenze della rete nei giorni/mesi precedenti. L' hardfork ci sarebbe comunque inquanto i vecchi client non accetterebbero la dimensione dinamica. Quindi non cambia nulla. FaSan Purtroppo pecchi in attenzione: si parla infatti di non dover incorrere nuovamente in un hard fork. Qualcosa cambia: una volta introdotta la funzione, non ci sarà bisogno di hard fork successivi (fatta eccezione per questioni che vanno oltre la dimensione del blocco). |
Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. |
|
|
|
FaSan
|
|
June 05, 2015, 04:43:04 PM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
...
Stavo pensando ad una cosa simile, come per la difficoltà, un qualcosa che si adatta alle esigenze della rete nei giorni/mesi precedenti. L' hardfork ci sarebbe comunque inquanto i vecchi client non accetterebbero la dimensione dinamica. Quindi non cambia nulla. FaSan Ce ne sarebbe uno solo e non uno ad ogni cambio di dimensione del blocco. Non sono un fan di Andresen, ma sinceramente a me non me pò fregar di meno della dimensione del blocco.
Io non ho opinioni in merito. A mio avviso BTC non puo' e non deve contenere tutte le transazioni del mondo, non ha senso che io autentichi o sappia che Tizio ha comprato il pane a Caio in Giappone il tal giorno alla tal ora ... però potrebbe essere utile poter memorizzare qualche dato in più ... se non crea problemi di sicurezza. Ma non credo sia proprio quello il problema. Il punto è che bisognerebbe ingrandire anche la grandezza delle singole TX. Oggi comporre una TX con migliaia di piccole, spesso provenienti dal mining, può essere un problema. Alzare la grandezza delle TX significa ridurre la quantità di TX per singolo blocco, morale il blocco và allargato. Ne và da se che quando non ci sono TX grandi, ci saranno più TX standard. Se il problema è lo spazio disco e la banda, ci sono svariati client lite che scaricano solo gli header, mi sembra più che accettabile per un uso basilare da utente medio. Poi alla fine, vogliamo tanto il p2p e la decentralizzazione, poi ci scoccia scaricare il db completo. E' proprio vero che nn si riuscirà mai a far contenti tutti  FaSan |
|
|
|
|
|
FaSan
|
|
June 05, 2015, 04:45:31 PM |
|
Per non dover incorrere nuovamente in hard fork si può pensare una dimensione dinamica del blocco tipo
media della dimensione degli ultimi x blocchi * coefficiente = max dimensione blocco
...
Stavo pensando ad una cosa simile, come per la difficoltà, un qualcosa che si adatta alle esigenze della rete nei giorni/mesi precedenti. L' hardfork ci sarebbe comunque inquanto i vecchi client non accetterebbero la dimensione dinamica. Quindi non cambia nulla. FaSan Purtroppo pecchi in attenzione: si parla infatti di non dover incorrere nuovamente in un hard fork. Qualcosa cambia: una volta introdotta la funzione, non ci sarà bisogno di hard fork successivi (fatta eccezione per questioni che vanno oltre la dimensione del blocco). Hai ragione, se intendevi per le successive espansioni. Per quanto riguarda questa, con un anno di anticipo sicuramente sarà indolore. FaSan |
|
|
|
|
acquafredda
Legendary
Offline
Activity: 1316
Merit: 1481
|
|
June 13, 2015, 03:32:48 PM |
|
Please note that Bitcoin XT does not currently change anything about block size limits, although a future version might.
Bitcoin XT is more experimental than Bitcoin Core, and has a strong emphasis on supporting the needs of app developers and merchants. By running it you not only provide additional services to the network but help build confidence in the implementations, contributing towards consensus for inclusion in a future version of Bitcoin Core. Si fa un gran parlare di Bitcoin XT sulla sezione internazionale. Davvero c'era bisogno di questo nuovo client? |
|
|
|
|
acquafredda
Legendary
Offline
Activity: 1316
Merit: 1481
|
|
June 14, 2015, 11:19:08 AM |
|
Please note that Bitcoin XT does not currently change anything about block size limits, although a future version might.
Bitcoin XT is more experimental than Bitcoin Core, and has a strong emphasis on supporting the needs of app developers and merchants. By running it you not only provide additional services to the network but help build confidence in the implementations, contributing towards consensus for inclusion in a future version of Bitcoin Core. Si fa un gran parlare di Bitcoin XT sulla sezione internazionale. Davvero c'era bisogno di questo nuovo client? Avevo ricercato nella sezione discussioni avanzate e sviluppo e non c'era... scusa host |
|
|
|
|
alch1mista
Sr. Member
Offline
Activity: 455
Merit: 251
blockchain longa, vita brevis
|
|
June 15, 2015, 05:36:11 PM |
|
Questa discussione andrebbe spostata nella sezione "Alt-Currencies".
[/troll]
|
Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. |
|
|
|
gabridome
|
|
June 16, 2015, 11:36:01 AM |
|
Questa discussione andrebbe spostata nella sezione "Alt-Currencies".
ACK |
|
|
|
|
|
|
xeryan
Sr. Member
Offline
Activity: 337
Merit: 250
HTML5/Node.js/PHP developer
|
|
June 23, 2015, 05:31:38 AM |
|
Addio full nodini
|
|
|
|
|
|
