
Lazarus Pool ha iniziato a pagare i miner che erano stati esclusi dalla divisione della coinbase per alcuni blocchi XBT precedenti. La pool definisce questi pagamenti "risarcimenti" . Non si tratta di un bonus né di un nuovo blocco dei prelievi di XBT a livello di rete. Sono compensi differiti per le ricompense di mining che avrebbero dovuto essere corrisposte direttamente ai miner al momento del ritrovamento dei blocchi originali.
La coda pubblica è abbastanza grande da meritare attenzione: circa 366.7 XBT risultavano ancora in coda su 332 record al nostro ultimo controllo. Ma la storia importante non è solo il totale. È come una limitazione del gateway abbia trasformato un sistema di pagamento diretto da coinbase in un problema temporaneo per il pool, come Lazarus lo stia risolvendo e cosa i miner dovrebbero verificare prima di indirizzare ulteriore hashrate di BLAKE2b verso qualsiasi pool di DATUM.
Cos'è un risarcimento XBT?
Nella configurazione standard di DATUM di Lazarus, la base di monete del blocco viene suddivisa tra i miner idonei. Ciò consente a un miner di ricevere un output on-chain direttamente dal blocco, anziché attendere che il pool lo contenga per poi prelevare il saldo.
Alcune versioni precedenti del gateway non sempre costruivano correttamente quella divisione completa. Lazarus identifica due casi interessati:
- Coinbase parziale: Il blocco ha pagato parte della produzione prevista dai minatori, ma non tutta.
- Coinbase solo per pool: Il blocco ha pagato la produzione del pool ma non ha incluso pagamenti diretti ai minatori.
Le quote dei minatori sono state comunque registrate. Una volta che l'output della coinbase controllata dal pool diventa spendibile, Lazarus firma una transazione on-chain separata che paga i minatori omessi. Questa transazione successiva è la compensazione.
Questa distinzione è importante. Le azioni sottostanti non sono state cancellate e il risarcimento non è un airdrop discrezionale. Si tratta di un pagamento di un importo che i registri del pool attribuiscono già al miner.

Perché la scissione di Coinbase è fallita?
La spiegazione tecnica più chiara si trova nella documentazione del pacchetto StartOS di DATUM BLAKE2b . Le versioni del gateway fino alla 1.0.0:52 hanno ereditato le classi di dimensioni coinbase progettate per altri hardware di mining. Gli ASIC BLAKE2b potevano rientrare in una classe da 750 byte che consentiva solo circa 17 uscite di pagamento.
Quel limite massimo era ben al di sotto del numero di minatori che Lazarus avrebbe potuto dover pagare in un singolo blocco. La documentazione del pacchetto descrive una finestra di pagamento di Lazarus di circa 440 minatori. Quando la coinbase costruita non poteva contenere l'intero elenco di pagamento, o quando un miner utilizzava il percorso di lavoro solo per il pool, il pool riceveva il valore che altrimenti sarebbe stato suddiviso direttamente.
La documentazione attuale del pacchetto afferma che la build 1.0.0:53 ha spostato il mining di BLAKE2b sul percorso di pagamento completo, supportando una coinbase fino a 32,000 byte e fino a 1,024 output. Lazarus ha anche pubblicato un avviso relativo alla unsplit-coinbase di BLAKE2b che spiega il comportamento interessato.
I miner dovrebbero continuare a utilizzare la versione attualmente raccomandata dal pool, anziché considerare come definitiva una singola versione indicata in un articolo. Il software del gateway e i requisiti del pool possono subire modifiche.
Cosa mostra la coda pubblica
| Metrico | Istantanea all'altezza di 979,900 | Cosa significa |
|---|---|---|
| Riparazioni in coda | 332 record / 366.71809716 XBT | In attesa che gli output della loro coinbase madre giungano a maturazione. |
| Già pagato | 46 record / 70.72911462 XBT | Trasmissione e registrazione effettuate dal tracker al termine dell'operazione. |
| fallito | Record 0 | Nessun guasto al tracker al momento del controllo |
| Prima/ultima scadenza in coda | 980,119 / 986,289 | La coda si svuota progressivamente, non in un'unica transazione di pagamento. |
| Spese di custodia registrate | 0.29017851 XBT | L'adeguamento è legato ai gateway obsoleti interessati, non a una commissione per ogni miner. |
Il tracker espone anche il blocco originale, l'altezza di scadenza, l'importo del pagamento, lo stato e l'ID della transazione per ogni record. Ciò è utile a livello operativo: i miner possono verificare una rivendicazione sulla blockchain invece di affidarsi solo a un annuncio su Discord o al saldo di un pool interno.
I 332 record in coda erano programmati per essere elaborati a partire dal blocco 980,119 fino al 986,289, per un totale di 6,170 blocchi. Considerando l'obiettivo di dieci minuti della rete, si tratta di circa 43 giorni. La tempistica effettiva dipende dalla produzione dei blocchi.
Lazarus è l'unico pool XBT esposto a questo rischio?
Lazarus è l'unico pool XBT che abbiamo trovato a pubblicare una coda di compensazione quantificata con singoli record, importi, scadenze e ID di transazione. Ciò non significa che il problema del gateway sottostante fosse esclusivo di Lazarus. Altri pool DATUM documentano la stessa modalità di errore di capacità del coinbase, ma prevengono, riportano o liquidano i pagamenti mancati in modi diversi.
| Piscina | Schema di pagamento standard | Gestione documentata | Stato delle prove |
|---|---|---|---|
| Lazarus | DATUM/TIDES, pagato in coinbase | Transazione di compensazione on-chain separata dopo la scadenza dell'output del pool interessato | Coda di compensazione attiva confermata |
| Piscina Omega | DATUM, pagato in coinbase | Si avverte che le versioni di ratum-gateway precedenti alla 0.1.23 potrebbero limitare la suddivisione a circa 17 uscite, lasciando all'operatore il compito di gestire manualmente le rimanenti. | Stesso rischio tecnico documentato; nessun totale di coda pubblico trovato |
| B2Pool | TIDES, normalmente pagato in coinbase | Se non è possibile recuperare la ripartizione del pagamento, quel blocco paga l'indirizzo del pool e viene successivamente saldato dal portafoglio del pool. | Progetto di ripiego pubblicato; nessun backlog pubblico trovato |
| Piscina rabbiosa | DATUM/PPLNS, pagato in coinbase | Afferma che il suo gateway gestisce 50-60+ pagamenti mentre i gateway standard ne gestiscono circa 10; le porzioni non pagate vengono trasferite ai blocchi successivi e il lavoro NoSplit può essere rifiutato invece di essere pagato erroneamente | Problema di capacità riconosciuto; gestito in modo diverso rispetto a Lazarus |
| AlphaPool | DATUM/TIDES, pagato in coinbase | Richiede blockmaxweight=740000 per riservare spazio per l'elenco dei pagamenti; i suoi blocchi pubblicati mostrano grandi suddivisioni multi-output |
Non è stato riscontrato alcun arretrato di lavori di ripristino pubblici |
| Bitcoin Xor | DATUM/TIDES, pagato in coinbase | Supporta i gateway RATU o CONVOY mantenuti e pubblica i registri dei pagamenti di coinbase | Non è stato trovato alcun avviso pubblico di ripristino |

Questo confronto non deve essere interpretato come un'accusa secondo cui ogni pool di DATUM debba dei soldi ai miner. Dimostra piuttosto che i pool collegati direttamente a Coinbase necessitano di una risposta esplicita alla stessa domanda operativa: cosa succede se un gateway non riesce a gestire o a recuperare l'intera ripartizione dei pagamenti?
I pool PPLNS o FPPS convenzionali sono diversi. Normalmente ricevono la ricompensa per il blocco in un portafoglio controllato dal pool e successivamente pagano i saldi dei miner. Pertanto, una divisione diretta della coinbase troncata non è la loro principale modalità di fallimento; i miner si assumono invece il normale rischio di custodia, prelievo e solvibilità del pool.
Perché le riparazioni richiedono circa 45 giorni
I blocchi interessati sono stati minati durante la precedente finestra di maturazione della coinbase di XBT, composta da 6,480 blocchi, ovvero circa 45 giorni. Lazarus non può spendere l'output della coinbase del pool prima della sua scadenza, quindi non può trasmettere la transazione di compensazione in anticipo.
Questo è distinto dalla nuova regola di ricompensa per il mining di XBT a 180 giorni , che si applica ai nuovi output di coinbase a partire dall'altezza 979,919. I pagamenti di compensazione in coda non riavviano un secondo conto alla rovescia di 45 o 180 giorni per la coinbase quando vengono pagati. Si tratta di normali output di transazione creati dopo che la coinbase principale diventa spendibile.
Per la storia e le implicazioni della precedente regola, si veda la nostra analisi del blocco premio di 45 giorni di XBT.
Chi paga la maggiorazione del 10% per l'affidamento dei figli?
La modifica del 10% è facile da interpretare in modo errato. Lazarus non la descrive come una commissione forfettaria per ogni operazione di compensazione o per ogni utente del pool. Le informazioni e gli elenchi pubblici del pool lo collegano ai miner il cui gateway obsoleto crea una base di monete non divisa o utilizzabile solo all'interno del pool, costringendo quest'ultimo a custodire e successivamente ridistribuire i fondi.
L'API pubblica afferma che la politica si applica a partire dall'altezza 977,665. Il messaggio pratico è semplice: se un miner continua a utilizzare un gateway noto per generare il percorso di pagamento difettoso, il miner può farsi carico di parte dell'onere aggiuntivo di custodia e transazione. I miner che sono stati esclusi a causa della costruzione del blocco da parte di qualcun altro non devono presumere che la stessa detrazione si applichi anche a loro.
Se l'importo previsto e quello indicato dal tracker differiscono, prima di trarre conclusioni, verifica il blocco originale, l'indirizzo di pagamento, la versione del gateway che ha rilevato il blocco e le politiche attuali del pool.
366.7 XBT rappresenta un rischio di mercato?
La coda è significativa per i miner interessati, ma non rappresenta un singolo sblocco di 366.7 XBT. I pagamenti diventano eleggibili blocco per blocco nell'arco di diverse settimane. Con un sussidio nominale di 3.125 XBT per blocco e circa 144 blocchi al giorno, la rete crea circa 450 XBT di ricompense di mining per ogni giorno obiettivo. Il totale in coda è quindi inferiore a un giorno nominale di nuova offerta per i miner.
Quel confronto non dimostra che non ci saranno ripercussioni sui prezzi. La liquidità di XBT può essere scarsa, i destinatari potrebbero vendere per coprire i ritardi nei pagamenti delle bollette elettriche e gli intervalli effettivi tra i blocchi variano. Dimostra però perché descrivere la coda come un imminente crollo una tantum sarebbe fuorviante. I rischi più rilevanti sono la graduale pressione di vendita, la scarsa profondità del book degli ordini e le difficoltà di flusso di cassa già affrontate dai miner interessati.
Cosa dice questo sui pool di mining "non custodiali"
Il sistema di pagamento diretto di Coinbase riduce la custodia del pool durante il normale funzionamento, ma non elimina il rischio software. Il miner, il gateway, il fornitore del template e il sistema di contabilità del pool partecipano tutti alla produzione e all'attribuzione del blocco. Se il gateway crea la coinbase errata, il valore può comunque finire sotto il controllo del pool e creare un obbligo simile a una promessa di pagamento.
La risposta di Lazarus presenta due segnali positivi: la passività è elencata pubblicamente e il processo di liquidazione è visibile on-chain. L'API non ha rilevato alcun errore durante la nostra verifica. Questo è più rassicurante di una promessa vaga.
L'incidente solleva ancora una questione di governance. Un fondo di pagamento diretto necessita di requisiti di versione chiari, avvisi rapidi per modelli errati, riconciliazione indipendente e una politica di recupero pubblicata. Il termine "non custodiale" dovrebbe descrivere il normale flusso di valore, non essere interpretato come una garanzia che la custodia non possa mai sorgere.
Cosa dovrebbero fare ora i minatori di XBT
- Verifica il tuo indirizzo di pagamento. Cerca il dati di compensazione in tempo reale e registrare il blocco originale, l'importo, la durata, lo stato e l'ID della transazione.
- Verifica la configurazione del gateway. Confronta la versione installata con le istruzioni di configurazione attuali di Lazarus e aggiornala se utilizza il percorso di pagamento interessato.
- Non considerare gli XBT in coda come denaro spendibile. Budget per la potenza di calcolo e l'hosting fino a quando la coinbase principale non sarà matura e la transazione di compensazione non sarà confermata.
- Conservare registri e documentazione relativa ai pagamenti. Conservare la versione del gateway, l'indirizzo del miner, la risposta del pool e i dettagli del blocco nel caso in cui l'importo previsto sia diverso.
- Verifica un piano di riserva. I possessori di ASIC BLAKE2b possono mantenere una configurazione Siacoin verificata, in modo che un problema con un pool o un nodo XBT non blocchi l'intera farm.
- Evitate di concentrare tutto l'hashrate. Confronta la quota di partecipazione al pool, la struttura dei pagamenti, i requisiti software e la politica di recupero, non solo la tariffa pubblicizzata.
I nuovi operatori possono utilizzare il nostro Guida alla configurazione del nodo XBT DATUM and Guida al portafoglio Shrike. Per il contesto della selezione del pool, vedere il XBT/BTCGuida mineraria B2L'hardware compatibile è elencato nel Minatori BT BTCCollezione di minatori B2.
Domande frequenti
Lazarus sta bloccando i prelievi in XBT?
No. La coda di compensazione è un processo di liquidazione per i pagamenti storici di coinbase non effettuati. Non si tratta di un blocco dell'intero portafoglio o dell'intera rete.
I minatori hanno perso le loro azioni?
Lazarus afferma che le azioni sono rimaste accreditate. Il problema era che alcuni miner non erano presenti nella divisione iniziale della base di monete on-chain, quindi il pool dovrà pagarli in seguito con l'output del pool a scadenza.
Lazarus può effettuare il pagamento prima della scadenza prevista?
Non dall'output coinbase interessato. Le regole di consenso impediscono che tale output venga speso prima della scadenza.
La richiesta di risarcimento verrà bloccata per altri 180 giorni?
No. Un make-good è un normale output di transazione inviato dopo la scadenza della coinbase principale. Non diventa un nuovo output di coinbase.
Ogni minatore perde il 10%?
No. La modifica è associata ai miner che utilizzano gateway obsoleti che creano un percorso di pagamento non suddiviso errato. Verificare il record esatto e la politica attuale di Lazarus.
Conclusione
La vicenda della coda di risarcimento di Lazarus rappresenta al contempo una storia di successo e un monito. I registri pubblici, i dettagli dei pagamenti precalcolati e la liquidazione on-chain offrono ai miner coinvolti un modo per verificare quanto spetta loro. Allo stesso tempo, l'incidente dimostra che un pool di coinbase diretto può comunque incorrere in un'esposizione temporanea dei diritti di custodia quando il software del gateway calcola il pagamento in modo errato.
Per i miner, il compito immediato è verificare la coda e aggiornare il gateway. Per la più ampia comunità XBT, la lezione a lungo termine è quella di esigere disciplina di versione, contabilità trasparente e procedure di ripristino collaudate da ogni pool che dichiara di avere un design non custodial.
Fonti primarie
- API di ripristino in tempo reale di Lazarus
- Repository del codice sorgente e documentazione di Lazarus Pool
- Avviso di Lazarus BLAKE2b sulla non suddivisione della coinbase
- Documentazione del pacchetto StartOS DATUM BLAKE2b
- Documentazione relativa al gateway RATU e a Prime, inclusa la liquidazione dei blocchi di proprietà.
- Requisiti del gateway Omega Pool e avviso sui pagamenti della vecchia versione
- Politica di pagamento e di liquidazione di riserva di B2Pool coinbase
- Documentazione relativa al gateway DATUM e alla capacità di pagamento di Rabid Pool.
- Requisiti di pagamento e di peso dei blocchi di AlphaPool DATUM
- Documentazione relativa ai pagamenti Bitcoin Xor DATM
- Elenco dei pool XBT.live e avviso del gateway Lazarus
- Analisi di XBT.live delle scadenze a 45 e 180 giorni.
Nota: BT-Miners vende l'hardware di mining indicato nel link sopra. Questo articolo è un'analisi operativa, non una consulenza finanziaria né una garanzia di pagamento da parte del pool, redditività, liquidità o compatibilità del software. Le politiche del pool, le versioni del software e le condizioni della blockchain possono cambiare rapidamente. I dati e le cifre sono stati verificati il 31 ottobre 2026.