Topic: Mining pow sulle transazioni (Read 3580 times)

ottima soluzione in merito

Grazie della segnalazione. Per ora ho dato un'occhiata veloce al thread e ho visto uno scontro piuttosto acceso, per il fatto che il sistema non sarebbe puramente distribuito ma richiederebbe degli elementi centralizzati. Dovrei comunque approfondire meglio.

Ciao, non ho seguito la discussione (avevo letto qualcosa nel thread da cui è originata ma non ho poi avuto tempo) quindi chiedo scusa se non c'entra nulla o se è stato già segnalato:

https://bitcointalksearch.org/topic/dagcoin-a-cryptocurrency-without-blocks-1177633

(un progetto di criptocurrency con PoW sulle singole transazioni)

Hai ragione, è che le sparo quando mi maturano ... non serve aprire altri 3d.

non so, bisogna capire come verrebbe percepito dal miner il fatto di non avere un incentivo diretto ad includere transazioni nel suo blocco, ma doversi affidare al lavoro degli altri "concorrenti". Mi sembra una questione distinta da quella di cui si discuteva, comunque.

E se per evitare che i miner inseriscano transazioni fasulle per far credere che il blocco e' stretto (tanto se lo minano loro e le fee le recuperano) si proponesse che le fee del blocco x vadano a chi mina il blocco x+1?

ok me lo guardo con calma appena ho tempo, grazie

I blocchi sono reali, hai i link per verificare. Se sei interessato a p2pool prova a vedere https://en.bitcoin.it/wiki/P2Pool io non lo uso dal 2013 ...

mi sa che non ho capito: parli di una catena a difficoltà ridotta usata solo internamente, ma quella transazione e quel blocco sono veri, cioè stanno nella blockchain, quindi hanno risolto un pow reale, non uno fittizio usato nella pool. Mi sono perso qualcosa

a) p2pool è uno dei progetti che mi ha affascinato maggiormente, in poche parole è una pool p2p che crea una catena a difficoltà ridotta e tutti concorrono a minare il blocco, il pow dimostrato serve solo all'interno della pool per decidere la distribuzione del premio e delle fee che ricevi appena uno dei peer mina il blocco, se hai visto sono delle transazioni di generazione con decine di address che prendono piccole quantità.
Ti segno qualche link ...
Una transazione: https://blockchain.info/it/tx/f332f4c26f43439789f37b6c7d2849c79128a0d1609e1b12fa26ac608a6839de
Pool:
https://blockchain.info/it/blocks/P2Pool
Un blocco
https://blockchain.info/block-height/460239
il blocco:
https://blockchain.info/it/block/0000000000000000016f72d06a779ea328fde4adb5479e2ffaa5dce5adce7358

b) ho trovato qualcosa ma non sembra esattamente il discorso di questo 3d ...

ammetto di non saperne nulla...

Potrebbe essere una nuova forma di mining pool ... condiviso. Oppure due farm che si alleano. O tutti insieme appassionatamente ...
Considera che per ricalcolare l'hash devi cambiare qualcosa e ad un certo punto cambi riferimento al blocco al posto del nonce e continui ... 

Non c'entra forse nulla
a) ... ai tempi bazzicavo p2pool e mi piaceva come concetto.
b) qualche tempo fa devo aver visto qualcosa su miniblocchi che alla fine magari e' simile a questo, appena riesco provo a cercare

Direi anch'io, altrimenti è come abbassare la soglia del 50%+1 per il rischio double spending

secondo me il problema è che con n=1 il guadagno per il miner sarebbe, come hai indicato fin dall'inizio tra gli svantaggi, "una goccia nel mare", per cui il criterio preferenziale di scelta delle transazioni da includere nel blocco rimarrebbero le fee, come ora. A meno di casi rari di utenti con hashpower molto alta.

Perche' il la transazione minata sarebbe allettante per tutti i miner mentre ora devi minare il blocco intero per avere qualcosa. Certo che con n=1 dovresti broadcastare e i miner dovrebbero includerla nel blocco ricalcolando il tutto e forse non lo faranno volentieri (bo?), forse n=2, 6 divente interessante.


Non vorrei sparare una cazzata ma per transazioni importanti credo che un minimo di conferme uno se le aspetta ... diciamo che se devo ricedere 1000 BTC per un castello mica faccio l'atto dopo dieci minuti ... o no?
Per transazioni minori non e' detto ne valga la pena, comunque se n aumenta il rischio sale ... c'e' da dire che se diventa pratica comune poi risulta piu' facile mantenere la catena piu' lunga ...
Alla fine: direi n=1 è l'unica via praticabile.

Ah, mi ero perso l'ultimo update
Ho letto un po' in fretta, su due piedi direi che legando la transazione alla hash del blocco corrente, il pow della transazione diventerebbe sempre più simile a quello del blocco, quindi effettivamente più sicuro in termini di rischio double spending.
Bisognerebbe però valutare bene come cambia in funzione di "n", che rappresenta un fattore di elasticità in più rispetto al pow puro del blocco. Il caso limite è quando n=1, in quel caso minare il blocco o la transazione sarebbe indifferente, quindi c'è da chiedersi perché si dovrebbe scegliere quest'ultima piuttosto che il mining tradizionale.
All'aumentare di n, si darebbe qualche possibilità in più di partecipare al mining ad utenti non in grado di competere con miner professionisti, ma bisogna stare attenti a non fornire a questi ultimi una "finestra" sufficiente (con un hw abbastanza potente) a perpetrare con successo l'attacco double spending.

Il discorso e' puramente didattico non credo possa dare risvolti utili.

@jack0m ti rispondo senza quotare ... spero si capisca ...

L'utente normale si scorda di poter dare un contributo significativo, come minimo ci vogliono hw dedicati asics per poter fare hash interessanti. Eventualmente potrebbe essere un modo differente per minare. Paga le fee che deve e non riceve premi.

Credo di aver capito ... infatti ...
Il problema ora è che io poteri pianificare un fork se non indico la dipendenza dal blocco precedente (hash), ossia, il calcolo va ricominciato ogni volta che si genera un blocco perdendo eventuali hash bassi trovati e rendendo il sistema poco utile.

Considera comunque che non posso sapere a quanto ammonterà la velocità tra 6 mesi ma comunque non va bene poter dire genericamente il blocco x, va indicato un hash del blocco prima o ...
 
Si potrebbe pensare che la transazione possa essere inserita in uno degli "n" blocchi successivi all'hash a cui fa riferimento (es per 6 blocchi). Consentirebbe di calcolare e broadcastare con relativa calma  ma non di pianificare golpe.

Potrebbe servire per far collaborare varie mining pool in modo trasparente e fiduciario senza rischi. Chiunque potrebbe dare un contributo senza affidarsi ad una mining pool anche se ha potenze relativamente limitate.

In sostanza posso creare una transazione sia inserendo fee che lavorando pow (o entrambi), se ho fretta pago le fee che devo, se voglio guadagnare e non ho fretta posso minare una transazione che tuttiele farm hanno interesse ad includere.

Per il fatto che magari perdo l'hash della vita considera che anche ora non è mica detto che la tua miningpool mini qualcosa per giorni ... e se non continui a produrre non guadagni nulla (almeno una volta era cosi').  Con questo sistema consenti a tutte le mining pool di collaborare tra loro senza conflitti di interessi, dividono fee e revenue ma hanno anche meno lavoro.

Sono combattuto, a tratti sembra una buona idea, a tratti na strunzata ...

Grande! Mai arrendersi

Ma in questo caso, vedendola dal lato dell'utente normale, diciamo "onesto", quando vuole fare una transazione deve preoccuparsi anche lui (o al limite il client per lui) di decidere in quale esatto blocco inserirla? L'utente normale ovviamente vorrebbe vederla confermata già dal prossimo blocco, e non sarebbe particolarmente entusiasmante doversi prendere un margine di 10 blocchi, cioè quasi 2 ore (ma neanche un'ora, che poi si somma all'ora già necessaria ad ottenere le 6 conferme, rallentando il pagamento).
E comunque c'è sempre il rischio che rimanga in coda (per esempio perché il pc o dispositivo usato non ha molte risorse per calcolare l'hash, e quindi i miner gli danno una priorità più bassa). Allora l'utente dovrebbe rifare la transazione ad ogni nuovo blocco, finché non viene inclusa? Ok, potrebbe essere il client a farlo in automatico, se all'arrivo del blocco si accorge che la transazione manca. Però questo costringerebbe a rimanere collegati online finché non si ha la certezza che la transazione sia stata scritta nel blocco, mentre adesso, una volta che il client ha fatto il broadcast della transazione, posso anche disconnettermi ed essere abbastanza sicuro che continuerà a propagarsi nella rete.
Però se l'utente avesse anche fatto del pow, sarebbe ingiustamente penalizzante doverlo rifare da capo perché il miner non l'ha inclusa nel blocco: considera che la teoria dei giochi dietro al pow si basa sul concetto di incentivo (il reward che ottiene il miner giustifica le risorse consumate per il pow), ma nel caso dell'utente medio con risorse di calcolo ridicole rispetto a quelle dei miner, non avrebbe un vero incentivo a calcolare l'hash sulla transazione, che giustifichi il rischio di doverla ripetere ad ogni blocco. Per cui il sistema, anche se tecnicamente funzionante, tenderebbe a selezionare gli utenti con hw più potente e finirebbe per essere usato poco o nulla dagli utenti con hw ordinario, perché troppo gravoso. Almeno così mi immagino.

E comunque tutto ciò non toglie che, se voglio fare un double spending, posso pianificarlo in anticipo calcolando (sulla base delle mie risorse di calcolo) entro quanti blocchi posso essere ragionevolmente sicuro di aver trovato le hash abbastanza piccole per le 6 transazioni che mi servono. Magari ci vogliono mesi per avere un margine sufficiente, ma rimarrebbe comunque possibile.

Non mi arrendo ...
La rete potrebbe essere sicura se nella transazione ci fosse un riferimento al numero di blocco in modo che la stessa non possa essere inserita in un blocco differente da quello per il quale è stata pensata. Va rifatta la pow ad ogni nuovo blocco o mi preparo una transazione da broadcastare tra 10, 100 blocchi ma solo in quello specifico.
Qualunque miner potrebbe inserirla avendo uno sconto di difficoltà (target piu' basso). A naso direi che la cosa può essere considerata sicura ma il vantaggio sarebbe che in questo modo tutte le pool hanno un vantaggio di includere una transazione con basso hash perchè avrebbero uno sconto (sarebbe più facile minare il blocco). Potrei minare una transazione con un anticipo di 10 blocchi per essere sicuro di broadcastarla per tempo qualora trovassi l'hash fortunato. Dopo minerei una transazione su altri input e, se serve, su altro blocco.
Vedi/vedete qualche controindicazione?

bè grazie e te per la discussione interessante, che mi ha fatto apprezzare ancora di più il meccanismo così accuratamente studiato e ben oliato su cui poggia la blockchain

Non solo, se immagini un sistema che abbia solo transazioni che composte azzerano la difficoltà del blocco puoi immaginare n sacchetti con m(n) granelli, rovesci tutto e ricomponi come vuoi senza problemi, ovvio che qualche granello lo lasci indietro e chiunque potrebbe farlo senza nessuna potenza di calcolo. Sarebbe il caos assoluto. Inutile e pericoloso.
Peccato :-(
EDIT: grazie per avermi dato modo di evolvere il ragionamento con domande pertinenti e che mi hanno permesso di arrivare ad una conclusione che magari mi avrebbe fatto dedicare alla cosa ore e ore ...