Topic: Velocizzare le conferme (Read 3367 times)

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.

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.

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

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


Sarebbero inutili se non venissero inoltrati sì.

Anche se il decimo blocco fosse orfano il decimo blocco che verrà accettato dovrà comunque contenere tutte le transazioni dei miniblocchi per essere valido.

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.

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

Inoltre le pool non dovrebbero confermare anche i miniblocchi oltre i blocchi (?)

Esatto, questa era una delle domande di dopo 

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

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.

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 

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 )