Solo mining per flotte in hosting: cosa aspettarsi

Questa guida è scritta per due tipi di lettori: hosting e gestori di flotte che fanno funzionare macchine di altri e devono decidere se, e come, offrire il solo mining; e operatori con flotte proprie che stanno valutando il solo rispetto a un pool proporzionale. Chi mina in casa con uno o due dispositivi trova la matematica generale in Mining Variance & Poisson Math; qui il tema sono le flotte, la cassa, le regole per i clienti, il monitoraggio e la scelta tra Bitcoin e Bitcoin Cash.

La prima metà riguarda i numeri: cosa deve aspettarsi una flotta su ciascuna chain e perché la media inganna. La seconda metà, dalla sezione sull’offerta del solo ai clienti in poi, è operativa: regole, prezzi, monitoraggio, il giorno in cui arriva un blocco e tre profili di flotta calcolati.

Punti chiave

• Il ricavo atteso per terahash è quasi uguale su BTC e BCH. Nello snapshot qui sotto, 1 PH/s valeva circa 39,7 USD al giorno su BTC e 39,5 USD al giorno su BCH.
• La distribuzione no. Un blocco BCH richiede circa 269 volte meno lavoro di un blocco BTC e vale circa 269 volte meno, quindi la stessa flotta trova blocchi BCH circa 269 volte più spesso.
• Il tempo atteso è una media, non un calendario. Dopo un tempo atteso c’è ancora circa il 37% di probabilità di nessun blocco; dopo tre tempi attesi, circa il 5%.
• Solo contro FPPS cambia i tempi, non la media. La differenza nel ricavo atteso è lo scarto di fee: 1% in solo contro fee FPPS che sulla maggior parte dei grandi pool stanno tra circa il 2% e il 4%.
• È la cassa a decidere la dimensione della quota. Per essere sicura al 95% di almeno un blocco, una flotta deve poter reggere circa tre tempi attesi.
• Sono gli share accettati, non i blocchi, a dirti che la flotta funziona. Settimane senza blocchi sono normali; settimane con share accettati in calo no.
• Per gli hosting, il problema dei ticket si risolve prima del passaggio. Una dichiarazione scritta e una dashboard che mostra i blocchi attesi accanto a quelli trovati trasformano un rischio di assistenza in un prodotto.

Lo snapshot usato in questa guida

Tutti i numeri che seguono vengono da questo snapshot. I dati di rete cambiano ogni giorno: per i valori attuali usa il calcolatore live e il report mensile sulle probabilità.

La difficoltà è il dato che conta di più, ed è letta direttamente dalla chain. Le cifre di hashrate di rete pubblicate dagli explorer sono stime ricavate dai tempi dei blocchi, e fonti diverse divergono di qualche punto percentuale; il tempo atteso della tua flotta non dipende da esse.

L’unica formula dietro a tutto

Il tempo atteso perché una flotta trovi un blocco è:

Tempo atteso = difficoltà × 2³² ÷ il tuo hashrate

Per le flotte contano due dettagli:

• Usa l’hashrate effettivo, non quello di targa. Fermi macchina, share stale e latenza di rete riducono il lavoro che arriva davvero al pool. Una flotta con uptime del 97% ha il 97% della probabilità di targa, e il suo tempo atteso è circa il 3% più lungo.
• Difficoltà e hashrate di rete sono misure diverse. La difficoltà è fissata dal protocollo in base ai tempi dei blocchi passati; l’hashrate di rete è una stima di quanto lavoro si sta facendo adesso. Chain con lo stesso algoritmo possono avere difficoltà molto diverse, ed è esattamente il caso di BTC e BCH.

Per un approfondimento sul modello di probabilità, con simulazioni, vedi Mining Variance & Poisson Math.

Stesso ricavo atteso, distribuzione molto diversa

Ecco 1 PH/s di hashrate effettivo su ciascuna chain, nello snapshot:

I due ricavi attesi sono entro circa mezzo punto percentuale l’uno dall’altro. Non è una coincidenza né una legge: le stesse macchine SHA-256 possono minare entrambe le chain, e gli operatori tendono a spostarsi tra le due finché il ricavo per hash non si equivale più o meno. Quando prezzi o difficoltà si muovono, lo scarto si riapre per un po’.

Quello che non si equivale è la forma del reddito. In questo snapshot un blocco BTC richiede circa 269 volte più lavoro di un blocco BCH e vale circa 269 volte di più. Stessa media, esperienza opposta: su BTC una flotta di medie dimensioni aspetta anni per un pagamento molto grande; su BCH la stessa flotta ne incassa molti piccoli.

Cosa deve aspettarsi una flotta

La tabella mostra il tempo atteso per blocco, l’attesa mediana, il tempo entro cui arriva un blocco nel 95% dei casi e la probabilità di almeno un blocco entro 30 giorni ed entro un anno.

Bitcoin (BTC), difficoltà 132,76 T

Bitcoin Cash (BCH), difficoltà 494,00 G

Ne seguono direttamente due letture. Su BTC, sotto i 50 PH/s circa, il solo resta una scommessa a lungo termine anche per una flotta professionale: a 10 PH/s la probabilità di non trovare nessun blocco in un anno intero è ancora circa il 57%. Su BCH, da circa 1 PH/s in su, il solo smette di essere una lotteria e diventa un reddito irregolare.

Perché la media inganna

Il tempo di attesa di un blocco segue una distribuzione esponenziale, e questo ha conseguenze che sorprendono quasi tutti la prima volta.

La mediana è più corta della media. Metà delle attese finisce prima di circa 0,69 volte il tempo atteso. Poche attese molto lunghe tirano su la media.

I lunghi periodi senza blocchi sono normali. Questa è la probabilità di non aver ancora trovato un blocco dopo un certo multiplo del tempo atteso:

Una flotta da 1 PH/s su BCH ha un tempo atteso di 24,6 giorni. Restare 50 giorni senza blocchi, il doppio del tempo atteso, capita in circa un caso su sette. Non è un segnale che qualcosa non vada.

Il mining non ha memoria. Ogni hash è un tentativo indipendente. Dopo tre mesi senza blocchi, la probabilità di trovarne uno domani è esattamente quella del primo giorno. A nessuno spetta mai un blocco, e una serie fortunata non consuma la fortuna futura.

Quanti blocchi in un mese: flotte su BCH

Per flotte abbastanza grandi da trovare diversi blocchi BCH al mese, la domanda utile diventa quanto oscilla il conteggio mensile. Il numero di blocchi in un periodo segue una distribuzione di Poisson, la cui dispersione relativa si riduce al crescere del numero atteso.

A 1 PH/s, circa tre mesi su dieci si chiudono senza alcun blocco. A 10 PH/s, un mese con soli sette blocchi e un mese con diciotto sono entrambi normali. A 100 PH/s il risultato mensile resta entro circa il 15% dalla media in nove mesi su dieci.

La cassa: il vero limite del solo

Hosting ed elettricità si pagano ogni mese in valuta. Il ricavo del solo arriva a blocchi. Lo scarto tra i due è il rischio pratico del solo per una flotta, e si può dimensionare.

Regola pratica dalla distribuzione esponenziale: per essere sicura al 95% di almeno un blocco, una flotta deve poter operare per circa tre tempi attesi senza ricavi dalla quota solo. Per il 99%, circa 4,6 tempi attesi.

Due esempi nello snapshot:

• 1 PH/s su BCH: tempo atteso 24,6 giorni, quindi circa 2,4 mesi di autonomia per una sicurezza del 95%. Gestibile per la maggior parte degli operatori.
• 10 PH/s su BTC: tempo atteso 21,7 mesi, quindi circa 5,4 anni di autonomia per una sicurezza del 95%. Non gestibile come piano di reddito; solo come allocazione deliberata a lungo termine.

Un esempio con ipotesi dichiarate: una flotta a 15 J/TH assorbe circa 15 kW per PH/s, cioè 360 kWh al giorno. A 0,07 USD per kWh sono circa 25 USD al giorno, circa 770 USD al mese, per PH/s. Rispetto ai circa 39,5 USD al giorno di ricavo atteso nello snapshot il margine medio è positivo, ma su BCH a 1 PH/s circa tre mesi su dieci non portano blocchi, e su BTC quasi tutti. Sostituisci efficienza e tariffa con le tue; la struttura del ragionamento resta la stessa.

Solo contro FPPS: cosa compra la fee

In valore atteso, solo e un pool Full Pay Per Share pagano quasi la stessa cosa, perché entrambi pagano il sussidio del blocco più le fee di transazione in proporzione al tuo lavoro. Le differenze sono:

• La fee. La maggior parte delle fee FPPS pubblicate dai grandi pool sta tra circa il 2% e il 4%, con almeno un pool legato a un exchange che dichiara meno (fonte: comparativa dei pool di Simple Mining, aggiornata al 23 set 2026). Rispetto a una fee FPPS del 2-4%, una fee solo dell’1% trattiene circa 1-3 punti percentuali in più del ricavo atteso.
• Cosa paga la fee più alta. Un pool FPPS si fa carico della varianza al posto tuo e paga ogni giorno, blocco o non blocco. È un’assicurazione, e per molti operatori vale il suo prezzo.
• Le fee di transazione. L’FPPS paga una stima delle fee medie; il solo incassa le fee reali dei blocchi che trovi. Su molti blocchi i due convergono; blocco per blocco differiscono.

Il solo ha senso economico quando una flotta può assorbire la varianza alla dimensione che sceglie, e quando i punti percentuali in più, o la preferenza di essere pagati direttamente dalla blockchain, contano per l’operatore.

La strategia della quota

Un modo pratico di usare il solo non è spostare un’intera flotta, ma mettere da parte una quota, dimensionata perché da sola raggiunga un ritmo prevedibile, e tenere il resto su un pool proporzionale.

Un esempio calcolato. Una flotta da 10 PH/s mette 1 PH/s in solo su BCH e 9 PH/s su FPPS. La quota ha un tempo atteso di circa 25 giorni e trova in media circa 15 blocchi all’anno. Circa il 90% del reddito della flotta resta giornaliero e prevedibile; la quota aggiunge un reddito BCH a blocchi con un rendimento atteso leggermente migliore.

Come dimensionare la quota. Parti dalla regola dell’autonomia: scegli la quota più grande di cui puoi finanziare comodamente tre tempi attesi senza ricavi dal solo, e su cui un trimestre negativo non cambi le tue decisioni.

Lasciala stare. Spostare la quota dentro dopo una settimana fortunata, o fuori dopo un mese senza blocchi, non cambia le probabilità, perché il mining non ha memoria. Cambia solo quanto tempo la quota passa a minare. Decidi una volta, metti la decisione per iscritto e rivedila a scadenze fisse, non dopo ogni risultato.

La difficoltà si muove: BTC e BCH si comportano diversamente

• Bitcoin ricalcola la difficoltà ogni 2.016 blocchi, circa ogni due settimane, e la tiene fissa nel frattempo. Tra un aggiustamento e l’altro, il tuo tempo atteso è stabile.
• Bitcoin Cash usa ASERT (aserti3-2d), che ricalcola la difficoltà a ogni blocco con un tempo di dimezzamento di due giorni (specifica; la nostra spiegazione: ASERT explained). Quando arriva o se ne va hashrate, la difficoltà di BCH segue nel giro di pochi giorni.

Per le grandi flotte su BCH c’è una conseguenza da pianificare: il tuo hashrate fa parte della rete. Nello snapshot, 100 PH/s sarebbero circa il 3% dell’hashrate di rete stimato di BCH, quindi spostarli su BCH farebbe salire la difficoltà più o meno della stessa quota nel giro di pochi giorni, allungando di conseguenza il tuo tempo atteso. Su BTC gli stessi 100 PH/s sono circa lo 0,01% della rete e non hanno effetti visibili.

Cinque letture sbagliate che fanno pensare a un guasto

1. Nessun blocco da settimane, quindi una macchina è guasta. Controlla prima gli share accettati. Se gli share inviati dalla flotta corrispondono al suo hashrate, la flotta funziona, e il periodo senza blocchi è statistica.
2. Abbiamo aspettato così tanto che un blocco ci spetta. Il mining non ha memoria. La probabilità di un blocco domani non dipende da quanto hai aspettato.
3. Il nostro best share era enorme, quindi ci siamo andati vicino. Il best share è lo share di difficoltà più alta che il tuo miner abbia mai prodotto: misura quanto era raro quell’hash. Non significa che sei andato vicino a un blocco e non predice il prossimo. Approfondimento in Best Share Explained.
4. Un solo pool con più hashrate dà probabilità migliori. In solo, l’hashrate degli altri miner non ti aiuta: le tue probabilità dipendono solo dal tuo hashrate effettivo e dalla difficoltà. In un solo pool contano uptime, latenza e template di blocco corretti.
5. Un mese decide se la strategia funziona. A 1 PH/s su BCH, un singolo mese può andare da zero a tre blocchi senza che succeda nulla di anomalo. Giudica una quota solo su periodi di diversi tempi attesi, mai su uno.

Come verificare che la flotta funzioni senza aspettare i blocchi

• Share accettati rispetto a quelli attesi. Il lavoro accettato deve seguire l’hashrate della flotta nell’arco di ore e giorni. Uno scarto costante è un problema di configurazione o di hardware; l’assenza di blocchi no.
• Share rifiutati e stale. Qualche punto percentuale è comune; un aumento improvviso di solito indica latenza di rete, una porta sbagliata o una macchina instabile. La soglia esatta è una regola pratica che dipende da hardware e connessione, non una costante del protocollo.
• Uptime per macchina. Sono l’hashrate effettivo, non quello di targa, a fissare le probabilità. Una macchina ferma un giorno a settimana perde circa il 14% della sua probabilità.
• Statistiche lato pool tramite API. Le flotte dovrebbero leggere hashrate, worker e blocchi trovati via codice, non a occhio. Per SoloFury, gli endpoint pubblici sono documentati su solofury.com/api-docs.

Offrire il solo ai clienti in hosting: il punto di vista del provider

Gli hosting che hanno valutato il solo e hanno detto no di solito danno la stessa ragione: un cliente alle prime armi potrebbe sceglierlo senza capire la varianza, non vedere pagamenti per settimane e aprire un ticket convinto che le macchine siano guaste. La preoccupazione è fondata, ed è anche risolvibile, perché tutto ciò che il cliente fraintenderebbe è prevedibile e si può spiegare prima del passaggio invece che dopo.

A chi è adatto il solo, e a chi no. Il solo è adatto ai clienti che capiscono che la ricompensa arriva a blocchi, che possono finanziare l’autonomia, e che sono abbastanza grandi su BCH da vedere blocchi con regolarità oppure scelgono deliberatamente una scommessa a lungo termine su BTC. Non è adatto a un cliente al primo acquisto il cui piano dipende da un pagamento ogni giorno. La regola più pulita è tenere il solo fuori dall’elenco predefinito e renderlo un’opzione su richiesta, per i clienti che lo chiedono o che superano una soglia di dimensione.

La dichiarazione che previene i ticket. Prima di puntare la prima macchina sul solo, il cliente conferma per iscritto un breve elenco di fatti, in linguaggio semplice:

• il tempo atteso per blocco con il suo hashrate sulla chain scelta, e la data dello snapshot da cui è calcolato;
• che dopo un tempo atteso c’è ancora circa il 37% di probabilità di nessun blocco, e dopo tre circa il 5%;
• che la metrica che dimostra che le macchine funzionano sono gli share accettati, non i blocchi trovati;
• di aver accantonato i costi operativi per almeno tre tempi attesi;
• come viene fissata la data di revisione, e che i risultati recenti non sono un motivo per cambiare la quota.

Lo scopo è dare al cliente un numero con cui confrontarsi invece di una sensazione, prima del primo periodo senza blocchi e non durante.

Rendere visibile il periodo senza blocchi. Un cliente che vede su una dashboard gli share accettati che seguono il suo hashrate, il numero di blocchi attesi finora e i blocchi effettivamente trovati, può rispondere da solo alla domanda c’è qualcosa che non va. È la misura più efficace che un provider possa aggiungere per prevenire i ticket, e si può costruire dall’API pubblica del pool.

Modelli di prezzo e dove si inserisce il solo

Tariffa fissa per kilowattora. Il cliente paga energia e gestione, tiene l’intera ricompensa e sceglie il pool. Il solo si inserisce senza alcuna modifica: il ricavo del provider non dipende da quando arrivano i blocchi.

Quota sui ricavi. Il provider trattiene una percentuale di ciò che le macchine minano. Alcuni provider la incassano a livello di pool, con un’integrazione con un pool proporzionale che divide i pagamenti giornalieri. Con un solo pool quel meccanismo oggi non esiste: la coinbase paga il miner e la fee del pool, e non c’è una terza uscita per il provider. Un provider a quota sui ricavi può comunque offrire il solo in due modi: fatturando la sua quota dai blocchi trovati, che sono pubblici on-chain e nell’API del pool, oppure applicando una tariffa fissa alla quota solo. In entrambi i casi l’accordo va messo nel contratto prima del primo blocco, non discusso dopo.

Selezione del pool gestita. Alcuni provider scelgono il pool al posto del cliente. In quel modello il solo può essere offerto come opzione esplicita con la sua dichiarazione, oppure escluso; quello che non funziona è passare un cliente al solo senza la spiegazione sopra.

Configurazione della flotta per il solo

• Un indirizzo di pagamento per cliente, worker nominati per macchina. Nella maggior parte dei solo pool lo username è l’indirizzo di pagamento, e un suffisso identifica il worker. Le statistiche per cliente vengono così da sole, e un blocco trovato da qualsiasi macchina di quel cliente paga quel cliente.
• Porte ad alta difficoltà per le macchine industriali. Il traffico di share di un rack di miner di classe S21/S23 è molto più alto di quello dei dispositivi domestici. Usa le porte ad alta difficoltà o Stratum V2 del pool dove disponibili, e una difficoltà iniziale fissa per l’impianto; riduce il traffico di rete senza cambiare le probabilità.
• Regione più vicina. Gli share stale sono lavoro che arriva troppo tardi per contare. Punta le macchine sulla regione del pool con la latenza più bassa dal sito e misura il tasso di stale dopo il passaggio.
• Pool di riserva. La maggior parte dei firmware supporta un pool secondario. Configurare come riserva l’account del cliente su un pool proporzionale mantiene produttivo l’hashrate durante un eventuale fermo del solo pool, e tiene il cliente informato che la riserva è stata usata.
• Formati di connessione diversi per firmware. I firmware Stratum V2 differiscono nel chiedere host e porta oppure un URL completo con la chiave di autorità del pool. Controlla la documentazione del pool per ciascun firmware prima di configurare un intero rack.

Cosa monitorare, per cliente

L’indicatore di fortuna che molti pool mostrano confronta il lavoro fatto dall’ultimo blocco con il lavoro atteso per blocco. Un valore sotto il 100% significa che l’attesa in corso è più lunga della media; descrive il passato, non è una previsione, e le definizioni cambiano da pool a pool.

Il giorno in cui arriva un blocco

1. Conferma on-chain, non solo nel pool. Controlla l’altezza del blocco su un explorer indipendente e verifica che la coinbase paghi l’indirizzo del cliente.
2. Aspetta la maturità. Le ricompense della coinbase diventano spendibili dopo 100 conferme, una regola di consenso sia su BTC sia su BCH: circa 17 ore a dieci minuti per blocco.
3. Attenzione agli orfani. Raramente un blocco trovato perde la gara con un altro blocco alla stessa altezza e non entra nella chain definitiva. Se dopo qualche conferma l’altezza non è più nella chain principale, la ricompensa non è spendibile; è una proprietà del protocollo, non del pool.
4. Registralo. Altezza, hash, orario, indirizzo, ricompensa e uscita della fee, per la contabilità del cliente e per un’eventuale fattura sulla quota dei ricavi.
5. Spiega al cliente cosa succede ora, compreso che il prossimo blocco non è né più né meno probabile di prima. La nostra guida ai passi dopo una vincita è in You Found a Block, Now What?.

Tre profili di flotta calcolati

Tutte le cifre usano lo snapshot all’inizio di questa guida.

Profilo A: un cliente da 2 PH/s che vuole provare il solo. Il provider consiglia BCH per l’intera allocazione oppure, più prudentemente, una quota da 500 TH/s. A 2 PH/s su BCH il tempo atteso è di circa 12 giorni, circa 30 blocchi all’anno, e in una finestra di 30 giorni arrivano da zero a cinque blocchi in nove casi su dieci; un mese senza blocchi capita circa una volta su undici. A 500 TH/s il tempo atteso è di circa 49 giorni e un mese senza blocchi capita più della metà delle volte: è il numero da mettere nella dichiarazione.

Profilo B: un operatore da 30 PH/s che vuole il solo come seconda fonte di reddito. Il dieci per cento della flotta, 3 PH/s, va in solo su BCH: tempo atteso circa 8 giorni, circa 45 blocchi all’anno, da uno a sette blocchi in un mese tipico, e una finestra di 90 giorni senza blocchi è praticamente impossibile se le macchine funzionano. Gli altri 27 PH/s restano su FPPS. Se il provider applica una quota sui ricavi, la quota da 3 PH/s si fattura dai blocchi registrati on-chain.

Profilo C: un operatore da 150 PH/s che valuta una scommessa su BTC. Su BTC gli interi 150 PH/s hanno un tempo atteso di circa 44 giorni e circa otto blocchi all’anno, ma metà dei mesi si chiude senza blocchi e un periodo di 90 giorni senza blocchi capita circa una volta su otto. Una quota da 20 PH/s su BTC ha un tempo atteso di circa 11 mesi: due probabilità su tre di almeno un blocco nel primo anno, e una su tre di un anno intero senza nulla. È un’allocazione deliberata per un operatore che può sostenerla, non un piano di reddito. Gli stessi 20 PH/s su BCH troverebbero invece un blocco circa ogni 30 ore.

Un registro dei rischi per il solo su scala di flotta

BTC o BCH per una quota solo?

La liquidità fa parte della decisione: BTC e BCH sono entrambi quotati sui principali exchange centralizzati, e conta quando una flotta deve convertire le ricompense per pagare bollette in valuta.

Prima di puntare una flotta sul solo: una checklist

• Metti per iscritto le regole. Dimensione della quota, chain, data di revisione e cosa non conta come motivo per cambiarla.
• Finanzia l’autonomia. Almeno tre tempi attesi di costi operativi per la quota.
• Concorda la lettura con l’hosting o il cliente. Tutti i coinvolti devono sapere che periodi senza blocchi di due tempi attesi sono normali, prima che arrivi il primo.
• Usa un wallet che controlli. Le ricompense del solo vanno all’indirizzo nella configurazione del miner; gli indirizzi di deposito di un exchange possono funzionare ma aggiungono una controparte. Le ricompense diventano spendibili dopo la maturità della coinbase prevista dal protocollo, 100 blocchi.
• Pianifica la contabilità. Un reddito a blocchi può cambiare come e quando le coin minate vengono registrate nella tua giurisdizione. Verifica con un consulente qualificato.
• Imposta il monitoraggio. Share accettati, tassi di rifiutati e stale e uptime per macchina, letti tramite API.

Cosa questa matematica non cattura

• I cambi di difficoltà. Ogni cifra presuppone che la difficoltà dello snapshot resti invariata. Su BTC cambia ogni due settimane; su BCH, di continuo.
• I prezzi. I valori dei blocchi in USD sono uno snapshot, non una previsione.
• Le fee di transazione. I coin per blocco includono una media; i blocchi reali variano.
• I blocchi orfani. Rari, ma un blocco trovato può a volte perdere la gara con un altro blocco alla stessa altezza. Bassa latenza e un nodo ben connesso riducono il rischio.
• Il tuo effetto sulla difficoltà, rilevante su BCH per flotte oltre qualche punto percentuale dell’hashrate di rete.

Come SoloFury gestisce l’hashrate delle flotte

Questa sezione riguarda il nostro servizio; tutto ciò che precede vale per qualsiasi solo pool.

• Pagamenti non-custodial: quando una macchina trova un blocco, la ricompensa viene pagata nella coinbase direttamente all’indirizzo del miner. Non c’è saldo sul pool, non c’è prelievo e non c’è registrazione: l’indirizzo del wallet è lo username.
• Fee dell’1%, pagata come uscita separata della coinbase.
• Porte Stratum V2 ad alta difficoltà per macchine di classe S21/S23: 3343 per BTC e 7343 per BCH. Stratum V1 su ogni coin, con TLS su ogni porta.
• Difficoltà iniziale fissa per gli impianti: imposta la password a d=50000 per ridurre il traffico di share.
• 9 regioni di server, e un’API pubblica di statistiche per ogni coin per il monitoraggio delle flotte.

I dettagli di configurazione sono nella pagina di avvio e nella documentazione API. Le probabilità attuali per qualsiasi hashrate sono nel calcolatore.

Letture correlate

• Mining Variance & Poisson Math: il modello di probabilità completo, con simulazioni.
• Solo Mining vs Pool Mining: fee, metodi di pagamento e confronto delle fee effettive.
• Solo Mining Odds: probabilità per dispositivo e per chain.
• ASERT explained: come reagisce la difficoltà di BCH a ogni blocco.
• You Found a Block, Now What?: cosa succede dopo una vincita, e come verificarla on-chain.