ok grazie,


in che senso, cioè non c'è un target di difficoltà? Si provano hash per 10 minuti e si pubblica la più bassa che si è trovata?

su questo punto continuo a non capire cosa intendi. La difficoltà D del blocco è proporzionale a T * H, dove T è il tempo medio per trovare il blocco (10 min) e H l'hashrate complessiva della rete. Come calcoli la porzione di hashrate da scontare per le transazioni?

e che incentivo avrebbe? Perché dovrebbe preferire di usare così la propria potenza di calcolo piuttosto che per fare direttamente mining del blocco (anche in pool)?


su questi punti ci devo tornare quando mi è chiaro come funziona lo "sconto" sulla hash del blocco (vedi sopra)

Semplificando: se ci vogliono "mediamente" 1000 hash per minare un blocco e tu hai una transazione con un hash che vale 10 hai l'1% delle revenue e il miner basta che trovi un hash che vale 990, si prende il 99% delle fee e delle revenue.
Se ci sono 100 transazioni che valgono 10 mini il blocco senza nessuna specifica sull'hash perché la somma dei calcoli fatti equivale ai 1000 hash della difficoltà. Non prendi nulla ma mini il blocco. Ovviamente le 100 transazioni devono stare nel blocco (non superare il MByte o quello che sarà)
Il calcolo matematico/statistico non lo so fare ma credo sia possibile farlo.
Il problema maggiore credo sia che attualmente la difficoltà sta a 475,705,205,062, in ogni blocco ci sono meno di 2000 transazioni quindi per minarne uno bisognerebbe avere una difficoltà media di 475705205062/2000.=237.852.602 che è comunque una difficoltà elevatissima.
Mi sa che il contributo che puo' dare un utente è pari ad una goccia nell'oceano ... e tutto questo porterebbe ad un aumento della difficoltà dove gli utenti avrebbero sempre poco potere. D'altronde esistono già le mining pool che aggregano hashrate.

provo a riformulare: supponiamo che il target del blocco al momento sia: 0000000000FFFFFFF... (10 zeri esadecimali iniziali); la transazione trova una hash con 6 zeri iniziali, quindi contribuisce per circa lo 0,0015% al PoW del blocco (2^-16); 2000 transazioni con lo stesso valore medio della hash arriverebbero al 3% dell'hash del blocco. Ho capito bene? Ma ha senso sommare i PoW calcolati su problemi diversi e indipendenti tra loro?

Non so se il calcolo che hai fatto sia corretto dal punto di vista statistico. La probabilità mi ha insegnato che è un casino essere sicuri dei calcoli (per me), ma ammettiamo che sia corretto in quanto "fila". Direi che hai capito cosa intendo.
Se ha senso? Io direi di si in quanto l'algoritmo sarebbe lo stesso e il lavoro è lavoro sia che lo compia in italiano sia che lo compia un cinese (che paga meno l'energia ma questo è un altro discorso). Ovviamente va calcolato due volte l'hash sha256, forse qualche differenza la troviamo per il calcolo del primo hash in quanto le lunghezze dei dati non credo possano essere uguali e quindi presumo influisca sulla velocità di calcolo. Al massimo si fa in modo che siano almeno simili e non significativi, per il secondo hash direi che i calcoli da fare sono gli stessi.
Magari si cambia algoritmo in modo da rendere inutili gli asics e si da un peso diverso ai due calcoli, mi sembra piu' pericoloso come approccio.

ma ho capito bene o le coin sono tutte preminate e distribuite dai dev? Magari domani me lo guardo meglio, ora è meglio se vado a dormire

Vero. Questo era uno dei difetti, forse si puo' risolvere con la data (non ricordo se una transazione ha la data, forse si...) e poi non si accettano transazioni con date troppo diverse.

EDIT: mia cazzata: Se la transazione è nel blocco non la annulli a meno di riscrivere la chain per intero.
EDIT 2: Diciamo che considerando la data il problema è minore...

infatti, il problema è proprio quello: il meccanismo che rende proibitivo alterare la blockchain sta nel pow del blocco. Se con hash delle transazioni abbastanza piccole vinci un bonus sulla hash del blocco in cui le includi, tutto quello che devi fare è macinare con calma le hash di 6 transazioni, una delle quali fa double spending, le altre anche fittizie da 1 satoshi, e distribuendole in 6 blocchi consecutivi puoi cancellare una vecchia transazione anche dopo che aveva avuto 6 conferme!

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

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.

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.