davideandClaude Sonnet 5.5
8b182ac8b6
Only the duration and the cooldown (and, since B-73, the draw confirmations) were copied onto the round when it opened. The cost of a bet and the fee address were read live, so an edit from /admin in the middle of a round gave the players of that round different stakes for the same chance and redirected the commission of the round in progress. - `rounds.bet_amount_sats`, `rounds.fee_address` and `rounds.max_round_pool_sats` are copied from round_config in the transaction that opens the round (Alembic a7d3e9f15b48: plain add_column, existing rounds backfilled with the current configuration, i.e. what they were using; the expression indexes untouched). `place_bet` charges the round's cost, `_trigger_payout` pays the round's fee address (an empty one on the row still stops the payout, as before), `GET /rounds/current` advertises the round's cost while one is active and the configured one otherwise. The minimum withdrawal and the fee rate stay live, by design (ADR-20, ADR-10). - `round_config.max_round_pool_sats` (0 = none, otherwise >= the bet cost and <= 4e15, in /admin and PUT/GET /admin/config): a bet is refused with `round_full` (params also carry `max_round_pool_sats`) once the sum of the round's participant rows, in-flight ones included, has reached the round's cap, before anything moves; the pool can exceed it by one bet at most. A cap under the bet cost is a 422 `max_round_pool_below_bet_amount`. - PUT /admin/config's payability check (RND-40) now also judges a fee-rate change against the bet cost the round in progress opened with, which can be lower than the configured one. - `error.round_full` no longer says "maximum of N players" (it also fires for the pool cap): the seven translations are generic. Ambiguity resolved: the spec said the cap is snapshotted (RND-05, BET-20, ARC) in some places and "applies immediately, also to the round in progress" in the round_config table of modello-dati; the snapshot wins, with a column on `rounds` (modello-dati/api/guide-admin brought in line). Tests changed because the spec changed: the payout fixtures seed the round's own fee address, and the old "fee address missing" payout test now empties the round's address (clearing it in the configuration mid-round must not stop the payout). New test_round_snapshot.py: the copy at open, edits reaching only the next round, every bet of a round paying the same stake whether the cost is raised or lowered meanwhile, the payout following the round's address (and surviving it being cleared in the configuration), the cap (exactly at the cap is full, in-flight bets count, no cap, a mid-round edit of the cap does not apply, the refused player's coins untouched), plus the route, the admin bounds and the two 422s, the fee-rate check against the round's own cost, and the migration backfill. Mutation-checked: charging the live cost, paying the live address, not copying the cap and `>` instead of `>=` each fail tests. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
437 lines
28 KiB
Markdown
437 lines
28 KiB
Markdown
# Limiti noti
|
|
|
|
Questo documento raccoglie i **limiti noti (`LIM`)**: difetti di copertura o
|
|
di robustezza accettati consapevolmente, con l'impatto, ciò che oggi li
|
|
attenua e cosa servirebbe per chiuderli. Le **decisioni di progetto** non sono
|
|
più qui: ognuna è un ADR in [adr/](adr/README.md).
|
|
|
|
Un limite noto **non è un bug**: un bug è un comportamento che contraddice la
|
|
specifica e prende un numero `B-nn` ([storico-bug.md](storico-bug.md)). Se si
|
|
decide di chiudere un limite, si aggiorna prima la voce `LIM` qui (o la si
|
|
barra come rimossa) e poi il requisito del documento di dominio, secondo
|
|
[processo-di-modifica.md](processo-di-modifica.md).
|
|
|
|
Un limite che il [piano delle correzioni](piano-correzioni.md) chiuderà porta
|
|
`*Stato:* da chiudere con B-nn`, e *Per chiuderlo* descrive il comportamento
|
|
atteso; quando la correzione entra nel codice, il limite si barra come
|
|
`~~[LIM-nn]~~ Rimosso: chiuso da B-nn`.
|
|
|
|
Formato di ogni voce: descrizione, *Impatto*, *Mitigazione attuale*, *Per
|
|
chiuderlo*, e il codice coinvolto.
|
|
Formato di ogni voce: descrizione, *Impatto*, *Mitigazione attuale*, *Per
|
|
chiuderlo*, e il codice coinvolto.
|
|
|
|
### Quali limiti bloccano il funzionamento non presidiato
|
|
|
|
La revisione del 2026-09-28 ha mostrato che la tabella precedente era
|
|
incompleta: oltre a `drawing` e all'RBF, bloccavano il funzionamento non
|
|
presidiato le falle critiche B-73 … B-82 (estrazione manipolabile, risposte
|
|
oltre 64 KiB, abbandoni su un solo server, pagamento senza riserva, deposito
|
|
spendibile due volte). La colonna *Dopo il piano* dice cosa resta una volta
|
|
implementato il [piano delle correzioni](piano-correzioni.md).
|
|
|
|
| Limite | Blocca il non presidiato oggi? | Dopo il piano |
|
|
|---|---|---|
|
|
| ~~[LIM-01]~~ `drawing` non riprende dopo un errore o un riavvio | Non più (chiuso da B-81) | — |
|
|
| [LIM-02] RBF di una sola forma | Non più il pagamento senza resto (B-79) né il resto sotto soglia (B-87); resta una transazione che esaurisce resto o riserva | Visibile in `rbf_bump_failed`; resta in attesa senza abbandono |
|
|
| [LIM-03] Attesa in `closing` senza limite di tempo | **Sì, in caso di congestione** | Resta senza limite di tempo per scelta ([ADR-51](adr/ADR-51-dubbio-liberano-mai-fondi.md)); con B-78 e B-87 finisce quando la rete decide |
|
|
| [LIM-04] Prelievo e RBF mai provati in rete reale | **Sì, come verifica** | Da chiudere con la prova su rete reale ([operativita.md](operativita.md#prova-su-rete-reale)) prima di aprire al pubblico |
|
|
| ~~[LIM-10]~~ Riorganizzazioni non gestite | Non più (chiuso da B-82 e B-85) | Resta [LIM-24] |
|
|
| [LIM-11], ~~[LIM-12]~~ Quorum facoltativo e parziale | Non più (chiusi da B-82, B-83 e B-84) | Resta la scelta dell'operatore di server indipendenti ([LIM-11]) |
|
|
| [LIM-13] Estrazione manipolabile | **Sì** — per un giocatore che mina | Chiuso da B-73; resta [LIM-25] |
|
|
| [LIM-14] Header senza difficoltà minima | **Sì** — un header falso congela ogni estrazione | Chiuso da B-74 per il blocco; resta il costo basso di un header a difficoltà minima |
|
|
| [LIM-06] Token admin unico | No per il funzionamento, ma è il rischio di sicurezza più ampio | Invariato |
|
|
| tutti gli altri | No | — |
|
|
|
|
### Robustezza del ciclo di vita
|
|
|
|
- ~~[LIM-01]~~ Rimosso: chiuso da B-81. Un round in `drawing` riprende da solo
|
|
dopo un errore o un riavvio, con lo stesso blocco, gli stessi partecipanti e lo
|
|
stesso vincitore ([RND-36](ciclo-di-vita-del-round.md)).
|
|
|
|
- **[LIM-02]** **L'RBF gestisce una sola forma di transazione**: un'unica uscita
|
|
riducibile — il resto verso il mittente per scommesse e prelievi, l'uscita
|
|
di riserva per il pagamento ([RND-38](ciclo-di-vita-del-round.md#4--pagamento), B-79).
|
|
Non c'è il ripiego «aggiungi un'altra moneta» né il CPFP. Ogni aumento costa
|
|
almeno 1 sat/vB sull'intera dimensione della transazione (141 sat per una
|
|
transazione con un ingresso e due uscite) e si toglie da quell'uscita; se
|
|
quanto resta sarebbe sotto la soglia di polvere l'uscita viene eliminata e
|
|
il suo valore va in commissione, e quella sostituzione è l'ultima (B-87,
|
|
[ADR-19](adr/ADR-19-ogni-transazione-utente-conserva-uscita-resto.md)); se
|
|
nemmeno l'intera uscita raggiunge l'aumento minimo, o non esiste, `bump_fee`
|
|
solleva `RbfError`.
|
|
- *Impatto:* con la rete congestionata una transazione a 1 sat/vB che ha
|
|
esaurito resto o riserva può restare in mempool indefinitamente. Poiché il
|
|
riconciliatore abbandona solo ciò che il server **non conosce**, una
|
|
transazione ferma ma presente in mempool non viene mai abbandonata: una
|
|
scommessa così blocca il round in `closing`, un pagamento così lo blocca
|
|
in `paying_out`.
|
|
- *Mitigazione attuale:* la riserva del pagamento è dimensionata per circa
|
|
10 sat/vB; resto minimo garantito sulle transazioni utente; tetto al fee
|
|
rate (`MAX_FEE_RATE_SAT_VB`); ogni accelerazione impossibile o rifiutata
|
|
scrive `rbf_bump_failed` (una volta per transazione e motivo); abbandono
|
|
dopo 6 ore per ciò che sparisce dalla rete; ritentativo automatico del
|
|
pagamento dopo un abbandono.
|
|
- *Stato:* accettato dopo B-79 e B-87: una transazione che ha esaurito resto
|
|
o riserva e non conferma nemmeno al tetto del fee rate resta in attesa,
|
|
visibile, e non viene abbandonata ([ADR-51](adr/ADR-51-dubbio-liberano-mai-fondi.md)).
|
|
|
|
*Codice:* `app/tx/broadcast.py:bump_fee` · `app/wallet/psbt_builder.py:build_payout_transaction` · `app/tx/reconcile.py:reconcile_once`
|
|
|
|
- **[LIM-03]** **L'attesa in `closing` non ha un limite proprio.** Il round
|
|
aspetta ogni scommessa `building`/`broadcast`. A porre fine all'attesa di
|
|
una scommessa che non conferma è la sua conferma (una qualsiasi delle sue
|
|
versioni) oppure il riconciliatore, ma solo con la prova che non è partita
|
|
([ADR-51](adr/ADR-51-dubbio-liberano-mai-fondi.md)); una scommessa ferma ma presente in mempool trattiene il round senza
|
|
limite ([LIM-02]).
|
|
- *Impatto:* un round può restare chiuso ma non estratto per ore; nessun
|
|
nuovo round si apre nel frattempo.
|
|
- *Mitigazione attuale:* lo stato è visibile (`closing`) e il pannello
|
|
«Transazioni pendenti» mostra la scommessa che trattiene il round.
|
|
- *Stato:* B-78, B-77 e B-87 chiusi; resta per scelta l'assenza di un limite di tempo.
|
|
- *Per chiuderlo:* con B-78 l'attesa finisce quando la scommessa conferma
|
|
(una qualsiasi delle sue versioni, B-77) o quando c'è la prova che non
|
|
confermerà mai ([ADR-51](adr/ADR-51-dubbio-liberano-mai-fondi.md)), non dopo un tempo fisso; con B-87 la scommessa
|
|
resta accelerabile fino all'eliminazione del resto. Un **limite di tempo
|
|
resta escluso per scelta**: escludere e rimborsare una scommessa lenta
|
|
libererebbe fondi senza prova, che è ciò che [ADR-51](adr/ADR-51-dubbio-liberano-mai-fondi.md) vieta. Resta quindi
|
|
accettato che una scommessa ferma al tetto del fee rate trattenga il
|
|
round.
|
|
|
|
*Codice:* `app/rounds/scheduler.py:RoundScheduler._tick` · `app/tx/reconcile.py:_is_due`
|
|
|
|
- **[LIM-04]** **Prelievo e accelerazione RBF non sono mai stati inviati in una
|
|
rete reale.** Sono coperti da test unitari, rami di errore e annullamento
|
|
compresi; il resto del flusso (registrazione, deposito, scommessa, un ciclo
|
|
completo di round con pagamento) è stato verificato in mainnet.
|
|
- *Impatto:* un errore di costruzione o di firma specifico della rete reale
|
|
emergerebbe al primo prelievo di un utente vero.
|
|
- *Stato:* da chiudere con la fase 7 del [piano](piano-correzioni.md#fase-7--prova-su-rete-reale).
|
|
- *Per chiuderlo:* un prelievo e un RBF reali in mainnet, con verifica
|
|
dell'aritmetica sulla transazione inviata, dentro la prova con importi
|
|
piccoli e guasti provocati di
|
|
[operativita.md](operativita.md#prova-su-rete-reale).
|
|
|
|
*Codice:* `app/withdrawals/service.py:request_withdrawal` · `app/tx/broadcast.py:bump_fee`
|
|
|
|
- **[LIM-05]** **Nessun test di integrazione con una connessione Electrum
|
|
vera.** `tests/integration/` è vuota; la verifica dal vivo è stata tutta
|
|
manuale (`scripts/electrum_smoke_test.py`, script ad hoc, transazioni reali).
|
|
- *Impatto:* le differenze di comportamento fra implementazioni di server
|
|
Electrum (formati di risposta, errori) emergono solo in produzione.
|
|
- *Per chiuderlo:* lo strato di test di guasto e di integrazione previsto in
|
|
[architettura.md](architettura.md#test) (server Electrum simulati che
|
|
rispondono in ritardo, tagliano la connessione, mandano risposte enormi o
|
|
catene divergenti), più la prova su rete reale di
|
|
[operativita.md](operativita.md#prova-su-rete-reale). Nessuna delle falle
|
|
critiche del 2026-09-28 sarebbe stata trovata dai test attuali.
|
|
|
|
*Codice:* `tests/integration/__init__.py` · `scripts/electrum_smoke_test.py`
|
|
|
|
### Sicurezza e amministrazione
|
|
|
|
- **[LIM-06]** **Un unico token admin condiviso, senza identità per
|
|
operatore.** Il registro di audit dice *cosa* è cambiato (per esempio
|
|
`config_updated` con prima/dopo) ma non *chi*. Il token dà accesso a elenco
|
|
utenti, esportazione delle chiavi private, reset delle password e storico.
|
|
Non c'è limite ai tentativi sul token.
|
|
- *Impatto:* una fuga del token ha il raggio d'azione più ampio del sistema,
|
|
ed è impossibile attribuire un'azione a una persona.
|
|
- *Mitigazione attuale:* confronto a tempo costante, pannello chiuso se il
|
|
token è vuoto, ogni azione sensibile in audit, `/admin` non collegato dalla
|
|
pagina pubblica. Dettagli in [sicurezza.md](sicurezza.md).
|
|
- *Per chiuderlo:* account amministrativi individuali (con l'identità scritta
|
|
in ogni voce di audit) e limitazione dei tentativi sul token.
|
|
|
|
*Codice:* `app/api/routes/admin.py:require_admin` · `app/audit/log.py:write_audit_log`
|
|
|
|
- **[LIM-07]** **Nessuna limitazione di frequenza su scommesse, prelievi,
|
|
endpoint admin, cambio password e segnalazioni di bug.** Solo login e
|
|
registrazione sono limitati ([ADR-41](adr/ADR-41-limitazione-tentativi-su-login-registrazione.md)); il canale SSE ha tetti di
|
|
concorrenza (500 globali, 5 per IP), non di frequenza.
|
|
- *Impatto:* un utente autenticato può martellare scommesse e prelievi (il
|
|
blocco per-utente li serializza, non li limita); il cambio password
|
|
permette di provare password attuali senza ritardi a chi possiede già un
|
|
token valido; le segnalazioni anonime possono riempire il database.
|
|
- *Stato:* da chiudere in parte con B-94 (cambio password limitato e
|
|
registrato, segnalazioni di bug limitate per IP, lunghezza massima di 256
|
|
caratteri sui campi delle credenziali). Scommesse, prelievi ed endpoint
|
|
admin restano senza limite di frequenza anche dopo il piano.
|
|
- *Per chiuderlo:* un limitatore per utente e per IP sugli endpoint
|
|
interessati, sullo stesso modello di `RateLimiter`/`RollingQuota`.
|
|
|
|
*Codice:* `app/api/routes/bets.py:create_bet` · `app/api/routes/withdrawals.py:create_withdrawal` · `app/api/routes/users.py:change_password` · `app/api/routes/bug_reports.py:create_bug_report`
|
|
|
|
- **[LIM-08]** **Nessun registro di sicurezza lato utente.** Registrazione,
|
|
login, login falliti e cambio password dell'utente non scrivono voci di audit
|
|
(le scrive solo il reset da parte dell'admin).
|
|
- *Impatto:* dopo una compromissione non c'è traccia di quando e da dove sia
|
|
avvenuto l'accesso.
|
|
- *Stato:* da chiudere in parte con B-92 (`user_registered`, con indice di
|
|
derivazione e indirizzo) e B-94 (`password_changed`). Login riusciti e
|
|
falliti restano senza voce di audit dopo il piano.
|
|
- *Per chiuderlo:* eventi di audit per questi casi (vedi
|
|
[audit-log.md](audit-log.md)).
|
|
|
|
*Codice:* `app/auth/routes.py:login` · `app/api/routes/users.py:change_password`
|
|
|
|
- **[LIM-09]** **Il JWT sta in `localStorage` e la CSP ammette script inline.**
|
|
Una falla XSS permetterebbe di leggere il token.
|
|
- *Mitigazione attuale:* CSP `default-src 'self'`, `frame-ancestors 'none'`,
|
|
escape dei valori controllati dall'utente nelle pagine; sessioni revocabili
|
|
([ADR-36](adr/ADR-36-password-argon2-sessioni-jwt-hs256-24.md)).
|
|
- *Per chiuderlo:* togliere gestori e stili inline dalle SPA per poter
|
|
eliminare `'unsafe-inline'`, oppure spostare la sessione in un cookie
|
|
`HttpOnly`.
|
|
|
|
*Codice:* `Caddyfile` · `app/static/app.js`
|
|
|
|
- **[LIM-26]** **La piattaforma è custodiale: gli utenti devono fidarsi
|
|
dell'operatore.** Tutte le chiavi stanno sul server ([ADR-01](adr/ADR-01-piattaforma-custodiale-tutte-chiavi-generate-tenute.md)): l'operatore
|
|
(o chi compromette il server) può spendere ogni fondo, leggere
|
|
`server_seed` prima della rivelazione e scegliere il vincitore con un
|
|
minatore ([LIM-25]). Nessuna misura del piano lo cambia.
|
|
- *Impatto:* il rischio di perdita totale dei fondi depositati dipende dalla
|
|
sicurezza del server e dall'onestà dell'operatore.
|
|
- *Mitigazione dopo il piano:* chiave cifrata a riposo con la chiave di
|
|
cifratura in un file separato (B-91), container non root, verifica della
|
|
chiave all'avvio (B-89), prova pubblica di ogni estrazione ([ADR-24](adr/ADR-24-l-estrazione-commit-reveal-fra-server.md)), audit
|
|
di ogni azione sensibile. Modello di minaccia in
|
|
[sicurezza.md](sicurezza.md#modello-di-fiducia).
|
|
- *Per chiuderlo:* un disegno non custodiale, scartato in [ADR-01](adr/ADR-01-piattaforma-custodiale-tutte-chiavi-generate-tenute.md).
|
|
|
|
*Codice:* `app/wallet/hd.py:_load_account_key` · `app/wallet/keystore.py:decrypt_xprv`
|
|
|
|
### Fiducia nella rete
|
|
|
|
- ~~[LIM-10]~~ Rimosso: chiuso da B-82 e B-85. I depositi si accreditano a
|
|
`deposit_confirmations` conferme (le coinbase a 120), le riorganizzazioni sono
|
|
seguite, registrate e, da profondità 2, mettono in pausa; le monete del round
|
|
si verificano con il quorum prima del pagamento e i partecipanti spariti
|
|
restano fuori ([ADR-52](adr/ADR-52-riorganizzazioni-catena-contengono-invece-ignorarle.md)). Resta accettato il 51% ([LIM-24]).
|
|
|
|
- **[LIM-11]** **I server del quorum li sceglie l'operatore.** Il server
|
|
rifiuta di partire con meno di 2 server di riserva e ogni corroborazione
|
|
richiede almeno 2 risposte ([ADR-07](adr/ADR-07-ogni-decisione-sposta-denaro-base-risposta.md), B-84), ma più server controllati dalla
|
|
stessa parte contano come voci indipendenti. I certificati TLS non sono
|
|
verificati contro un'autorità; si possono fissare per endpoint
|
|
(`host:porta:pin=<sha256>`, `ELECTRUM_CERT_PIN`).
|
|
- *Impatto:* chi controlla la maggioranza dei server configurati (o
|
|
raggiungibili) può scegliere il vincitore o alterare i saldi mostrati.
|
|
- *Mitigazione attuale:* quorum minimo obbligatorio; meno di 2 risposte →
|
|
la corroborazione **fallisce** (una rete irraggiungibile non prova
|
|
nulla); pin facoltativo del certificato. Il vecchio caso «senza riserve
|
|
tutto passa» e «una sola risposta decide» è chiuso da B-84.
|
|
- *Per chiuderlo:* non si chiude: resta una scelta dell'operatore usare
|
|
server indipendenti fra loro.
|
|
|
|
*Codice:* `app/electrum/listener.py:ElectrumListener._corroborate_majority`
|
|
|
|
- ~~[LIM-12]~~ Rimosso: chiuso da B-83 e B-82. Conferme (prova merkle),
|
|
reintegri, abbandoni e le monete del montepremi usate per il pagamento sono
|
|
tutti decisi dal quorum degli altri server, mai dal solo server attivo.
|
|
|
|
- **[LIM-13]** **L'estrazione attuale è manipolabile da chi produce o
|
|
trasmette i blocchi.**
|
|
- *Minatore:* il seme è il solo hash del blocco, quindi un minatore con
|
|
biglietti in gioco può trattenere i blocchi finché uno lo fa vincere. Non
|
|
è un'ipotesi remota: la potenza di calcolo di PLM (~22 TH/s) si può
|
|
affittare, e scartare qualche blocco costa solo le ricompense perse.
|
|
- *Server attivo:* può scegliere quale blocco reale usare semplicemente non
|
|
annunciandone uno; la corroborazione verifica che il blocco esista, non che
|
|
sia il primo dopo la chiusura, e dopo una corroborazione fallita si passa
|
|
comunque al blocco successivo.
|
|
- *Verificabilità:* l'ordine dei partecipanti è l'orario di invio registrato
|
|
dal server, un dato non pubblico; un giocatore non può ricalcolare da solo
|
|
l'esito (il commento di `draw_winner` dice il contrario).
|
|
- *Pareggi:* due scommesse con lo stesso `broadcast_at` non hanno un criterio
|
|
secondario di ordinamento, quindi l'estrazione non è riproducibile.
|
|
- *Distorsione del modulo:* un seme da 256 bit modulo al più 400 partecipanti
|
|
introduce una distorsione inferiore a 400/2²⁵⁶, accettata anche dopo il
|
|
piano.
|
|
- *Stato:* chiuso da B-73.
|
|
- *Come è chiuso:* il commit-reveal di [ADR-24](adr/ADR-24-l-estrazione-commit-reveal-fra-server.md) con l'altezza fissa e le
|
|
conferme di [ADR-25](adr/ADR-25-blocco-estrazione-fissato-altezza-successivo-chiusura.md): seme che dipende da un segreto impegnato
|
|
all'apertura, partecipanti ordinati per txid e fissati da un'impronta,
|
|
prova pubblica. Resta accettata la collusione fra operatore e minatore
|
|
([LIM-25]).
|
|
|
|
*Codice:* `app/rounds/draw.py:draw_winner` · `app/rounds/scheduler.py:RoundScheduler._close_and_draw`
|
|
|
|
- **[LIM-14]** **La validazione degli header non ricostruisce la difficoltà
|
|
reale.** Il bersaglio dichiarato non può essere più facile del limite di rete
|
|
(B-74, [ELC-11](connessione-electrum.md#4-header-validati-non-creduti)) e
|
|
ogni salto di più blocchi è verificato come catena, quindi un header falso a
|
|
un'altezza enorme non blocca più `tip_height`.
|
|
- *Mitigazione attuale:* la corroborazione del blocco usato per l'estrazione
|
|
([ADR-07](adr/ADR-07-ogni-decisione-sposta-denaro-base-risposta.md), [ADR-25](adr/ADR-25-blocco-estrazione-fissato-altezza-successivo-chiusura.md)); non proteggeva dal blocco di `tip_height`, ora chiuso da B-74.
|
|
- *Stato:* chiuso da B-74.
|
|
- *Come è chiuso:* bersaglio non più facile di `powLimit` e catena
|
|
verificata su ogni salto ([ADR-26](adr/ADR-26-validazione-degli-header-concatenata-senza-ricalcolo.md)). Resta accettato dopo il piano: senza
|
|
il ricalcolo della difficoltà, un header a difficoltà minima (`powLimit`,
|
|
in media 2³² hash) costa una frazione di secondo a un miner ASIC e pochi
|
|
secondi a una GPU, quindi un
|
|
server ostile può ancora produrre una breve catena falsa concatenata alla
|
|
nostra. A neutralizzarla sono il quorum sull'header di estrazione
|
|
([ADR-25](adr/ADR-25-blocco-estrazione-fissato-altezza-successivo-chiusura.md)), il segreto del commit-reveal ([ADR-24](adr/ADR-24-l-estrazione-commit-reveal-fra-server.md)) e il rilevamento delle
|
|
riorganizzazioni ([ADR-52](adr/ADR-52-riorganizzazioni-catena-contengono-invece-ignorarle.md)); una validazione completa con le regole di
|
|
ricalcolo della difficoltà di PLM resta fuori scopo.
|
|
|
|
*Codice:* `app/rounds/draw.py:header_meets_its_own_target` · `app/electrum/listener.py:ElectrumListener._apply_header`
|
|
|
|
- **[LIM-15]** **La sottoscrizione di un nuovo indirizzo è a sforzo
|
|
singolo.** Se fallisce subito dopo la registrazione, l'indirizzo resta non
|
|
osservato fino alla riconnessione successiva o al giro di `DepositReconciler`
|
|
(300s, che attende prima di partire).
|
|
- *Impatto:* un deposito fatto subito dopo la registrazione può tardare fino
|
|
a cinque minuti.
|
|
|
|
*Codice:* `app/electrum/listener.py:ElectrumListener.address_for_new_user` · `app/deposits/reconcile.py:DepositReconciler`
|
|
|
|
- **[LIM-24]** **Un attacco al 51% su PLM resta possibile: è contenuto, non
|
|
impedito.** Chi controlla la maggioranza della potenza di calcolo (che per
|
|
PLM, ~22 TH/s, si può affittare) può riscrivere più di 6 blocchi e
|
|
annullare depositi già accreditati o scommesse già confermate. Riguarda
|
|
chiunque usi PLM, non solo la lotteria.
|
|
- *Impatto:* un deposito accreditato e poi annullato da una riorganizzazione
|
|
più profonda di `deposit_confirmations` è denaro che la piattaforma ha già
|
|
contato; può essere stato scommesso o prelevato.
|
|
- *Mitigazione dopo il piano:* 6 conferme sui depositi ([ADR-06](adr/ADR-06-depositi-richiedono-deposit-confirmations-conferme-6.md)) rendono
|
|
l'attacco costoso quanto sei blocchi dell'intera rete; il rilevamento e la
|
|
pausa sulle riorganizzazioni profonde ([ADR-52](adr/ADR-52-riorganizzazioni-catena-contengono-invece-ignorarle.md)) lo rendono visibile e
|
|
fermano nuovi round; la verifica delle monete prima del pagamento fa sì
|
|
che un round colpito paghi ciò che resta invece di bloccarsi. Il denaro
|
|
sottratto dall'attaccante è perso per la piattaforma.
|
|
- *Aperto:* nessuna di queste misure lega il costo dell'attacco alla
|
|
dimensione del montepremi. Il tetto opzionale `max_round_pool_sats`
|
|
([ADR-21](adr/ADR-21-tre-limiti-distinti-sul-numero-monete.md)) è disattivato per default (0) e, anche impostato, il suo
|
|
valore non discende da alcun calcolo del costo di noleggiare potenza
|
|
sufficiente a riscrivere `deposit_confirmations` blocchi: resta a
|
|
discrezione dell'operatore. Per un montepremi abbastanza grande, quindi,
|
|
l'attacco può convenire nonostante le mitigazioni sopra. Decisione
|
|
rimandata: se e come legare `max_round_pool_sats` a una stima di quel
|
|
costo (o attivarlo per default) non è stato ancora deciso.
|
|
- *Per chiuderlo:* non è chiudibile dal software della lotteria.
|
|
|
|
*Codice:* `app/deposits/service.py:find_new_credit_candidates` · `app/electrum/listener.py:ElectrumListener._apply_header` · `app/rounds/scheduler.py:RoundScheduler._trigger_payout`
|
|
|
|
- **[LIM-25]** **Operatore e minatore insieme possono scegliere il
|
|
vincitore.** Con il commit-reveal ([ADR-24](adr/ADR-24-l-estrazione-commit-reveal-fra-server.md)) l'operatore conosce
|
|
`server_seed` e può calcolare l'esito di ogni blocco candidato; un minatore
|
|
d'accordo con lui può scartare i blocchi sfavorevoli. Lo stesso vale per chi
|
|
ottiene sia il database sia la chiave di cifratura: il segreto è cifrato a
|
|
riposo ([sicurezza.md](sicurezza.md#sec-56) SEC-56), quindi il solo
|
|
database, o un suo backup, non basta.
|
|
- *Impatto:* un round può essere vinto da un complice.
|
|
- *Perché è accettato:* l'operatore è già fidato come custode di tutti i
|
|
fondi ([LIM-26]); chi può leggere il database può già fare di peggio.
|
|
Il commit-reveal impedisce a chi produce o trasmette i blocchi *da solo*
|
|
di scegliere il vincitore, che era il rischio da chiudere.
|
|
- *Per chiuderlo:* un contributo di casualità che l'operatore non conosce
|
|
(segreti dei giocatori, beacon esterno), scartato in [ADR-24](adr/ADR-24-l-estrazione-commit-reveal-fra-server.md).
|
|
|
|
*Codice:* `app/rounds/draw.py:draw_winner` · `app/rounds/service.py:open_new_round_if_needed`
|
|
|
|
- **[LIM-27]** **Le soglie di conferma differiscono da quelle del portafoglio
|
|
di riferimento.** `PalladiumWallet` considera spendibile un'uscita normale
|
|
dopo `MinConfirmations = 6` conferme e una coinbase dopo 121 (maturità 120
|
|
più un blocco di margine). La piattaforma adotta 6 solo per i depositi
|
|
([ADR-06](adr/ADR-06-depositi-richiedono-deposit-confirmations-conferme-6.md)) e 120 per le coinbase; un prelievo o una vincita, confermati qui
|
|
a 1 conferma, compaiono nel portafoglio di riferimento dell'utente come non
|
|
ancora spendibili per altri 5 blocchi.
|
|
- *Impatto:* un utente che preleva verso `PalladiumWallet` vede i fondi
|
|
arrivati ma bloccati per altri 5 blocchi (10 minuti in media) rispetto a
|
|
quanto dice la piattaforma; nessun rischio per i fondi.
|
|
- *Per chiuderlo:* non serve: è una politica del portafoglio del
|
|
destinatario, non una regola di consenso. Le guide
|
|
([guida-utente.md](guida-utente.md)) possono dirlo.
|
|
|
|
*Codice:* `app/tx/confirmation.py:poll_once` · `app/deposits/service.py:find_new_credit_candidates`
|
|
|
|
### Configurazione ed economia
|
|
|
|
- ~~[LIM-16]~~ Rimosso: chiuso da B-95. Costo della scommessa, `fee_address` e
|
|
tetto al montepremi sono fotografati sulla riga del round all'apertura, come
|
|
durata e pausa ([ADR-10](adr/ADR-10-parametri-round-fotografati-all-apertura.md)); il fee rate resta letto dal vivo per scelta e il prelievo
|
|
minimo segue il costo corrente della configurazione ([ADR-20](adr/ADR-20-prelievo-minimo-costo-corrente-scommessa.md)).
|
|
|
|
- **[LIM-17]** **Nessun consolidamento automatico del montepremi.** Monete
|
|
avanzate e resti si accumulano sugli indirizzi del montepremi (fino a B-80
|
|
su uno solo, per tutti i round); il margine fra 400 partecipanti e 500
|
|
ingressi ([ADR-21](adr/ADR-21-tre-limiti-distinti-sul-numero-monete.md)) si consumava nel tempo.
|
|
- *Impatto:* raggiunto il limite, il pagamento fallisce con
|
|
`too_many_inputs` e il round resta in `paying_out`, con un `payout_failed`
|
|
ogni 60s.
|
|
- *Stato:* la parte del margine che si consumava è chiusa da B-80: con un
|
|
indirizzo per round ([ADR-03](adr/ADR-03-ogni-round-ha-proprio-indirizzo-montepremi.md)) il pagamento spende solo le monete del proprio
|
|
round, e il margine non si consuma più (resta lo stato descritto sopra per
|
|
i round aperti prima di B-80, che condividono l'indirizzo di riserva).
|
|
- *Resta accettato:* le riserve per l'RBF ([ADR-17](adr/ADR-17-commissione-pagamento-esce-dalla-quota-vincitore.md)) e le monete
|
|
estranee inviate agli indirizzi di round chiusi si accumulano senza
|
|
consolidamento automatico; recuperarle è un'operazione manuale
|
|
([operativita.md](operativita.md#intervento-manuale-sui-fondi)).
|
|
|
|
*Codice:* `app/rounds/scheduler.py:RoundScheduler._trigger_payout` · `app/wallet/psbt_builder.py:build_payout_transaction`
|
|
|
|
### Prodotto e interfacce
|
|
|
|
- **[LIM-18]** **Il sistema presuppone un solo processo.** Canale SSE, blocchi
|
|
per-utente, limitatori di tentativi, cache dei QR e della chiave dell'account
|
|
sono in memoria.
|
|
- *Impatto:* con più worker, due costruzioni dello stesso utente potrebbero
|
|
scegliere le stesse monete, i limiti per IP si dividerebbero per worker e
|
|
gli eventi SSE arriverebbero solo ai client dello stesso worker.
|
|
- *Per chiuderlo:* canale condiviso (Redis pub/sub) e lock su database o
|
|
Redis. L'invariante del round attivo è già un indice e non rientra qui.
|
|
Il piano del 2026-09-28 **non** lo chiude: un solo processo e un solo file
|
|
SQLite restano la scelta di [ADR-13](adr/ADR-13-processo-file-sqlite.md), adeguata alla scala prevista; il piano
|
|
rende solo più affidabile quel processo (B-88, B-93).
|
|
|
|
*Codice:* `app/tx/locks.py:UserLocks` · `app/rounds/events.py:RoundEventBroadcaster` · `app/auth/rate_limit.py:AuthRateLimiters`
|
|
|
|
- **[LIM-19]** **Nessuna cronologia per l'utente.** L'utente non vede lo storico
|
|
dei round, delle scommesse, dei depositi o dei prelievi: un prelievo fallito
|
|
lascia una riga `failed` che l'utente non può mai vedere. Esistono solo
|
|
`GET /users/me/last-round-result` (l'ultimo round giocato) e
|
|
`GET /bug-reports/mine`. L'operatore ha invece `/admin/rounds`,
|
|
`/admin/pending-transactions`, `/admin/audit-log`.
|
|
- *Per chiuderlo:* endpoint e sezione di cronologia personale.
|
|
|
|
*Codice:* `app/api/routes/users.py:last_round_result` · `app/withdrawals/service.py:request_withdrawal`
|
|
|
|
- **[LIM-20]** **`/guida` è un segnaposto.** Il collegamento funziona ma la
|
|
pagina dice che la guida arriverà. (`/report-bug` invece è completa e
|
|
tradotta.)
|
|
|
|
*Codice:* `app/main.py:user_guide` · `app/static/guida.html`
|
|
|
|
- **[LIM-21]** **La parità delle chiavi di traduzione non è verificata da un
|
|
test.** Oggi le 7 lingue hanno le stesse 151 chiavi, ma nulla lo impone: una
|
|
chiave mancante ricade sull'inglese e, se manca anche lì, viene mostrata la
|
|
chiave grezza.
|
|
- *Stato:* da chiudere con il test di parità di
|
|
[ARC-63](architettura.md#test) (nessun B-nn: non è un difetto del codice).
|
|
- *Per chiuderlo:* un test che confronti gli insiemi di chiavi di
|
|
`TRANSLATIONS`.
|
|
|
|
*Codice:* `app/static/i18n.js:t`
|
|
|
|
- **[LIM-22]** **L'API di amministrazione e alcuni errori di contorno non usano
|
|
il formato d'errore strutturato.** Gli endpoint `/admin/*` rispondono con un
|
|
`detail` stringa (per esempio `"invalid admin token"`, `"user not found"`), e
|
|
così il 503 del canale SSE oltre il tetto; è coerente con un pannello non
|
|
tradotto, ma non è dichiarato altrove.
|
|
- *Stato:* da chiudere con B-94.
|
|
- *Per chiuderlo:* errori strutturati ovunque: `/admin/*`, il 503 del canale
|
|
SSE e gli errori generati dal framework usano lo stesso formato
|
|
`{code, message, params}` ([ADR-47](adr/ADR-47-l-api-parla-sola-lingua-risponde.md)).
|
|
|
|
*Codice:* `app/api/routes/admin.py:require_admin` · `app/api/routes/rounds.py:round_stream`
|
|
|
|
- **[LIM-23]** **`GET /admin/users` non ha limite né paginazione**, a
|
|
differenza degli altri elenchi admin.
|
|
- *Impatto:* con molti utenti la risposta cresce senza limite.
|
|
- *Stato:* da chiudere con B-94 (paginazione dell'elenco utenti).
|
|
|
|
*Codice:* `app/api/routes/admin.py:list_users`
|