davideandClaude Sonnet 5
88221b0dbd
Fourth full audit, run against the docs/ specification instead of the code alone, found logical flaws rooted in PLM's small hashrate (~22 TH/s): a minable draw, no distinction between "never broadcast" and "unknown if broadcast", an Electrum client that degrades as the pool address's history grows, and 1-confirmation deposits on a chain where a reorg is rentable. The spec now describes the target behaviour for every finding, marked *Stato:* da implementare (B-nn) with an *Oggi:* line for what the code does now; docs/piano-correzioni.md records the design decisions and the implementation order. No code changed — this is spec-only, per B-nn convention when a bug reveals the spec itself was incomplete. Also documents, as an accepted-but-open risk (LIM-24), that the optional jackpot cap (max_round_pool_sats) isn't tied to the cost of a 51% attack — deferred, not decided. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
6.1 KiB
Piano delle correzioni (revisione del 2026-09-28)
La revisione della specifica del 2026-09-28 (coin e catena, macchina a stati del denaro, operatività, coerenza dei documenti) ha trovato falle logiche nella struttura del software. Questo documento raccoglie le decisioni prese e l'ordine in cui implementarle.
La specifica è già stata aggiornata al comportamento atteso. Ogni
requisito che il codice non soddisfa ancora è marcato
*Stato:* da implementare (B-nn) e dice in una riga cosa fa il codice oggi
(vedi processo-di-modifica.md).
Il dettaglio tecnico di ogni voce, in inglese, è in BUGS.md.
Le decisioni
- Estrazione con commit-reveal. Il vincitore non deve essere calcolabile da chi produce o trasmette i blocchi: la potenza di calcolo di PLM (~22 TH/s) si può affittare. All'apertura il server si impegna su un segreto pubblicandone l'impronta. Alla chiusura si fissano l'elenco dei partecipanti e l'altezza del blocco. Il seme combina segreto, blocco ed elenco, e il segreto viene rivelato dopo. Un minatore non sa chi vincerebbe e quindi non ha motivo di scartare blocchi. L'operatore non può cambiare il segreto dopo averne pubblicato l'impronta. → ciclo-di-vita-del-round.md, B-73
- Nel dubbio non si liberano mai i fondi. Una transazione viene annullata solo con una prova: un rifiuto esplicito della rete, oppure i suoi ingressi spesi da un'altra transazione confermata. Mai per un timeout o per il silenzio di un solo server. → transazioni-e-riconciliazione.md, B-76, B-77, B-78
- Un indirizzo del montepremi per ogni round. Soldi, cronologia e pagamento di un round restano separati da quelli di tutti gli altri round. → B-80
- 6 conferme per i depositi (configurabili). Tutte le altre transazioni restano a 1: il deposito è l'unico ingresso che un utente può spendere due volte, perché il resto lo firma solo il server. → registrazione-e-depositi.md, B-82
- Le riorganizzazioni della catena si contengono. Si rilevano, si mette in pausa la lotteria quando sono profonde, e si paga solo ciò che risulta davvero sulla catena. → B-82, B-85
Limite accettato: un attacco al 51% su PLM resta possibile e riguarda chiunque usi PLM, non solo la lotteria. Queste misure fanno sì che non convenga e che non blocchi la lotteria; non lo rendono impossibile. Vedi decisioni-e-limiti.md.
Ordine di implementazione
Le fasi vanno eseguite in ordine: ognuna si appoggia sulle precedenti. Dentro una fase l'ordine è indicativo. Ogni voce è un commit a sé, con il suo test di regressione, secondo processo-di-modifica.md.
Fase 1 — Fondamenta
| Voce | Cosa | Gravità |
|---|---|---|
| B-88 | Transazioni SQLite vere (BEGIN IMMEDIATE, synchronous=FULL) |
alta |
| B-75 | Client Electrum: limite di 16 MiB, risposta troppo grande = errore della richiesta, UTXO sotto la soglia di dust ignorati | critica |
| B-97 | Test che esegue le migrazioni e verifica gli indici | media |
| B-80 | Indirizzo del montepremi per round | critica |
Fase 2 — Nel dubbio non liberare
| Voce | Cosa | Gravità |
|---|---|---|
| B-84 | Quorum minimo obbligatorio (almeno 2 server di riserva, almeno 2 risposte) | alta |
| B-76 | Invio ambiguo: la riga resta building, invio a tutti i server |
critica |
| B-77 | Tutti i txid della catena di sostituzioni; RBF salvato prima dell'invio | critica |
| B-78 | Abbandono solo con prova; le righe failed restano sorvegliate |
critica |
| B-83 | Conferme e reintegri verificati dal quorum (prova merkle) | alta |
Fase 3 — Estrazione
| Voce | Cosa | Gravità |
|---|---|---|
| B-74 | Header: difficoltà minima, collegamento verificato su ogni salto | critica |
| B-85 | Riorganizzazioni seguite, registrate, con pausa se profonde | alta |
| B-86 | Rotazione se il server si ferma | alta |
| B-73 | Commit-reveal, altezza fissa, conferme sul blocco di estrazione, prova pubblica | critica |
| B-81 | drawing riprende dopo un errore o un riavvio |
critica |
Fase 4 — Pagamento
| Voce | Cosa | Gravità |
|---|---|---|
| B-79 | Riserva per l'RBF su ogni pagamento | critica |
| B-82 | 6 conferme sui depositi, 120 sulle coinbase, verifica prima del pagamento | critica |
| B-87 | RBF che non lascia resti sotto la soglia di dust | alta |
| B-95 | Parametri del round fotografati all'apertura, tetto al montepremi | media |
Fase 5 — Operatività
| Voce | Cosa | Gravità |
|---|---|---|
| B-71 | Una sola copia della master key e del database | bassa |
| B-72 | setup.md senza il falso "in locale o via Docker" |
bassa |
| B-89 | Verifica della chiave all'avvio | alta |
| B-90 | Ripristino da backup sicuro | alta |
| B-92 | Readiness, stato Electrum, filtri dell'audit, log | media |
| B-93 | Deploy e rollback | media |
| B-91 | Container non root, permessi, dipendenze fissate | alta |
Fase 6 — Rifiniture
| Voce | Cosa | Gravità |
|---|---|---|
| B-94 | Limiti su cambio password, login, bug report; errori strutturati | media |
| B-96 | Incoerenze minori (sette voci, un test ciascuna) | media |
Fase 7 — Prova su rete reale
Nessuna delle falle critiche sarebbe stata trovata dai test attuali, che simulano tutto. Prima di aprire al pubblico serve una prova con importi piccoli e guasti provocati di proposito, secondo la lista di operativita.md.
Correzioni solo documentali già applicate
Nella stessa revisione sono state corrette, senza un B-nn perché il codice non cambia:
- affermazioni false sul comportamento attuale: timeout trattato come rifiuto, "prima o poi abbandonata", quorum "su ogni decisione", tempi "nel caso peggiore", resto di 294 sat "accelerabile";
- due procedure operative pericolose: il ripristino con sblocco di
drawing(OPS-07) e la rotazione della chiave di cifratura (OPS-22); - puntatori sbagliati e requisiti duplicati in più documenti;
- formulazioni vaghe in regole normative.