Bitcoin Forum
May 05, 2024, 06:38:51 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Velocizzare le conferme  (Read 3356 times)
inaltoasinistra (OP)
Full Member
***
Offline Offline

Activity: 142
Merit: 104


View Profile
February 15, 2015, 02:06:57 PM
Last edit: February 15, 2015, 02:19:13 PM by inaltoasinistra
 #1

Buongiorno,
ho una proposta che potrebbe portare a velocizzare le conferme senza stravolgere – troppo – la blockchain. Come effetto collaterale positivo si avrebbe anche una riduzione della varianza sul guadagno da mining e sui blocchi orfani.

I blocchi da 10'* vengono scomposti in miniblocchi da 10/N'*, facendo però in modo (dopo un certo periodo) che sia possibile ricomporre i miniblocchi in blocchi standard, perdendo solo la PoW dei blocchi eliminati (che non è un problema se i blocchi sono abbastanza in profondità).

I primi N blocchi vengono creati con le regole attuali (a differenza della difficoltà, che sarà divisa per N).
Il blocco N+1 (12 in questo caso) è un riassunto degli ultimi N-1 blocchi: riprende tutte le transazioni degli N-1 blocchi nello stesso ordine (le transazioni coinbase vengono unite) e viene usato come hash del blocco precedente l'hash dell'ultimo blocco riassuntivo. La somma della dimensione dei blocchi intermedi dovrà essere minore uguale del MAXBLOCKSIZE.
Esempio con N=4:


Quando la difficoltà dei blocchi intermedi può essere eliminata senza compromettere la sicurezza della rete la blockchain può essere compressa in questo modo:


La difficoltà del singolo blocco sarà solo una frazione di quella attuale, quindi per mantenere lo stesso livello di sicurezza si dovranno attendere N volte le conferme che si aspettano attualmente. Questa tecnica non aumenta la sicurezza su un intervallo di tempo, solo diminuisce l'attesa per la prima conferma di N volte fornendo 1/N di sicurezza, che per moltissime transazioni potrebbe essere sufficiente.

Contro: forse un uso CPU più alto.

(sorgente diagrammi: https://mega.co.nz/#!NhIR2BpD!3nXiGeZEoi5P7SKica9WXoUFp9CnqVR_TZL8ac_aMmM )

Transactions must be included in a block to be properly completed. When you send a transaction, it is broadcast to miners. Miners can then optionally include it in their next blocks. Miners will be more inclined to include your transaction if it has a higher transaction fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
February 16, 2015, 02:16:53 PM
 #2

Non ho capito benissimo il concetto..

Hai diviso i blocchi attuali in un numero.. mettiamo che sia 10 (invece che 12 che viene piu semplice). Quindi ogni nuovo mini-blocco sarebbe come tempo medio di 1 minuto.

La prima domanda che mi sorge è, questi mini-blocchi verrebbero mandati in blockchain ogni volta che ne viene trovato uno, oppure solo quando trovi il decimo, quindi il superblocco?
Perchè se si... allora tantovale non cambiare nulla e metter il blocktime a 1 minuto.... se invece non vengono mandati, ho altre domande  Grin
Micio
Legendary
*
Offline Offline

Activity: 1061
Merit: 1283



View Profile
February 16, 2015, 03:53:35 PM
 #3

Neanche io ho capito benissimo il concetto, forse ho capito che a ogni miniblocco corrisponde a una "miniconferma" di 1/10 per ogni miniblocco. Se così fosse io direi che potrebbe risultare più pericoloso per il sistema quando un utente arriva a 9/10 miniconferme e poi il blocco annulla la transazione.
davvo
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
February 16, 2015, 03:59:49 PM
 #4

Neanche io ho capito benissimo il concetto, forse ho capito che a ogni miniblocco corrisponde a una "miniconferma" di 1/10 per ogni miniblocco. Se così fosse io direi che potrebbe risultare più pericoloso per il sistema quando un utente arriva a 9/10 miniconferme e poi il blocco viene dichiarato orfano.

Esatto, questa era una delle domande di dopo  Grin

L'altra era, se vengono mandati in blockchain solo i superblocchi, significherebbe che i "mini" blocchi sarebbero solo nel miner (infatti ogni miner avrebbe la sua serie di miniblocchi).
Quindi non ci sarebbe un sistema di conferme, perchè appunto la blockchain non conoscerebbe questi mini-blocchi.

Mentre, in caso di miniblocchi mandati in chain, allora le conferme sarebbero di a 9/10 ma con il rischio di poi vedere il blocco grosso orfano...
Quindi tantovale a quel punto metter il tempo a 1 minuto sempre.... e ignorare questi mini-blocchi.


Non ho quindi davvero capito che benefici porterebbe il sistema...
Micio
Legendary
*
Offline Offline

Activity: 1061
Merit: 1283



View Profile
February 16, 2015, 04:29:45 PM
 #5

Neanche io ho capito benissimo il concetto, forse ho capito che a ogni miniblocco corrisponde a una "miniconferma" di 1/10 per ogni miniblocco. Se così fosse io direi che potrebbe risultare più pericoloso per il sistema quando un utente arriva a 9/10 miniconferme e poi il blocco viene dichiarato orfano.

Esatto, questa era una delle domande di dopo  Grin

L'altra era, se vengono mandati in blockchain solo i superblocchi, significherebbe che i "mini" blocchi sarebbero solo nel miner (infatti ogni miner avrebbe la sua serie di miniblocchi).
Quindi non ci sarebbe un sistema di conferme, perchè appunto la blockchain non conoscerebbe questi mini-blocchi.

Mentre, in caso di miniblocchi mandati in chain, allora le conferme sarebbero di a 9/10 ma con il rischio di poi vedere il blocco grosso orfano...
Quindi tantovale a quel punto metter il tempo a 1 minuto sempre.... e ignorare questi mini-blocchi.


Non ho quindi davvero capito che benefici porterebbe il sistema...

Inoltre le pool non dovrebbero confermare anche i miniblocchi oltre i blocchi (?)
picchio
Legendary
*
Offline Offline

Activity: 2506
Merit: 1120



View Profile
February 16, 2015, 07:01:44 PM
 #6

Ammetto di non aver letto approfonditamente, la sensazione e' stata quella di simile a p2pool che e' geniale ma non ha ovviamente valore probatorio, inoltre direi che se si cambiano i 10 minuti allora non si chiamano piu' BTC.
EDIT: i 10 minuti credo siano stati scelti con una sorta di ragionamento che riguarda la possibilità che la transizione sia distribuita a tutti i nodi della rete ...

Waves mi piaceva ora non più.
Micio
Legendary
*
Offline Offline

Activity: 1061
Merit: 1283



View Profile
February 16, 2015, 07:19:20 PM
 #7

Ammetto di non aver letto approfonditamente, la sensazione e' stata quella di simile a p2pool che e' geniale ma non ha ovviamente valore probatorio, inoltre direi che se si cambiano i 10 minuti allora non si chiamano piu' BTC.
EDIT: i 10 minuti credo siano stati scelti con una sorta di ragionamento che riguarda la possibilità che la transizione sia distribuita a tutti i nodi della rete ...

A me piace che qualche italiano tiri fuori qualche idea carina e mi piace anche l'idea di un metodo alternativo ai 10 minuti d'attesa. L'idea dei miniblocchi è da studiare, magari qualcosa di bello la tiriamo fuori.
inaltoasinistra (OP)
Full Member
***
Offline Offline

Activity: 142
Merit: 104


View Profile
March 22, 2015, 03:19:06 PM
Last edit: March 22, 2015, 03:30:44 PM by inaltoasinistra
 #8

Non ho capito benissimo il concetto..

Hai diviso i blocchi attuali in un numero.. mettiamo che sia 10 (invece che 12 che viene piu semplice). Quindi ogni nuovo mini-blocco sarebbe come tempo medio di 1 minuto.

La prima domanda che mi sorge è, questi mini-blocchi verrebbero mandati in blockchain ogni volta che ne viene trovato uno, oppure solo quando trovi il decimo, quindi il superblocco?
Perchè se si... allora tantovale non cambiare nulla e metter il blocktime a 1 minuto.... se invece non vengono mandati, ho altre domande  Grin
I miniblocchi vengono propagati come avviene ora per i blocchi. Rimangono quindi gli svantaggi dell'abbassamento del tempo fra i blocchi (spreco di potenza della rete e centralizzazione del mining. Due gravi svantaggi). Il vantaggio è solo di poter comprimere la blockchain eliminanco N-1/N header di tutti i blocchi. Vantaggio modesto.

Dopo aver studiato boccio la mia idea O:-)

Un altro modo di applicare questo algoritmo è mantenere i 10' fra i miniblocchi (quindi non cambiare il comportamento attuale), ma accorciando la catena di header (che il client tiene sempre in RAM).

Neanche io ho capito benissimo il concetto, forse ho capito che a ogni miniblocco corrisponde a una "miniconferma" di 1/10 per ogni miniblocco. Se così fosse io direi che potrebbe risultare più pericoloso per il sistema quando un utente arriva a 9/10 miniconferme e poi il blocco annulla la transazione.
Il blocco non può annullare una conferma di un miniblocco. Per essere considerato valido il blocco dovrà contenere almeno tutte le transazioni dei miniblocchi (nello stesso ordine).


Quindi non ci sarebbe un sistema di conferme, perchè appunto la blockchain non conoscerebbe questi mini-blocchi.
Sarebbero inutili se non venissero inoltrati sì.

Mentre, in caso di miniblocchi mandati in chain, allora le conferme sarebbero di a 9/10 ma con il rischio di poi vedere il blocco grosso orfano...
Quindi tantovale a quel punto metter il tempo a 1 minuto sempre.... e ignorare questi mini-blocchi.
Anche se il decimo blocco fosse orfano il decimo blocco che verrà accettato dovrà comunque contenere tutte le transazioni dei miniblocchi per essere valido.

Fabrizio89
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


View Profile
April 20, 2015, 03:08:52 PM
 #9

Mi pare, ma potrei dire una boiata, che ci siano lavori in corso per velocizzare la propagazione delle transazioni a quanti più nodi possibile, rendendo quindi una transazione sicura già al suo rilascio.
Anon39
Legendary
*
Offline Offline

Activity: 1526
Merit: 1010


▇ ▅ ▃ ▇ ▅ █


View Profile
April 20, 2015, 09:52:28 PM
 #10

Mi pare, ma potrei dire una boiata, che ci siano lavori in corso per velocizzare la propagazione delle transazioni a quanti più nodi possibile, rendendo quindi una transazione sicura già al suo rilascio.
per come stanno le cose ora anche se una transazione viene propagata in tutti i nodi della rete non è sicura finche non riceve almeno una conferma.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!