forked from bitcoinafterlife/bal-electrum-plugin
add remaining root files
This commit is contained in:
bot
691
CHANGELOG_REFACTOR.md
Normal file
691
CHANGELOG_REFACTOR.md
Normal file
@@ -0,0 +1,691 @@
|
||||
# BAL — Resoconto del refactoring (per l'autore originale)
|
||||
|
||||
Questo documento elenca **tutte** le modifiche apportate al plugin BAL
|
||||
(Bitcoin After Life) rispetto alla versione originale `0.2.8`.
|
||||
|
||||
**Principio guida:** refactoring **conservativo e a comportamento invariato**
|
||||
(Approccio A). La logica di business è stata mantenuta **byte-identica** dove
|
||||
possibile; sono cambiati soprattutto la **disposizione dei file** e gli
|
||||
**import**. Nessuna riscrittura algoritmica.
|
||||
|
||||
Ambiente di verifica: **Electrum 4.7.2** + **PyQt6** (l'ultima release stabile
|
||||
che espone `json_db.register_dict`).
|
||||
|
||||
---
|
||||
|
||||
## 1. Riorganizzazione della struttura (separazione logica / GUI)
|
||||
|
||||
Il problema principale segnalato era che la logica e la grafica erano
|
||||
mescolate, in particolare in un unico file `qt.py` da **4131 righe**.
|
||||
|
||||
### Struttura PRIMA (flat, 7 file)
|
||||
```
|
||||
BAL/
|
||||
├── __init__.py (vuoto, 0 righe)
|
||||
├── bal.py (243) logica + plugin base
|
||||
├── util.py (533) helper
|
||||
├── heirs.py (791) modello eredi + costruzione tx
|
||||
├── will.py (927) modello will/WillItem
|
||||
├── willexecutors.py (374) networking will-executor
|
||||
├── qt.py (4131) TUTTA la GUI + il Plugin in un solo file
|
||||
└── bal_resources.py (14)
|
||||
```
|
||||
|
||||
### Struttura DOPO (core/ vs gui/)
|
||||
```
|
||||
bal/
|
||||
├── manifest.json metadati conformi allo standard
|
||||
├── qt.py shim di caricamento (re-export di Plugin)
|
||||
├── __init__.py docstring di architettura + __version__
|
||||
├── core/ LOGICA senza dipendenze Qt
|
||||
│ ├── util.py (ex util.py)
|
||||
│ ├── plugin_base.py (ex bal.py)
|
||||
│ ├── heirs.py (ex heirs.py)
|
||||
│ ├── will.py (ex will.py)
|
||||
│ └── willexecutors.py (ex willexecutors.py)
|
||||
└── gui/qt/ PRESENTAZIONE PyQt6
|
||||
├── theme.py (59) mappatura stato → colore
|
||||
├── common.py (155) import condivisi + helper GUI
|
||||
├── widgets.py (782) widget "foglia"
|
||||
├── calendar.py (80) BalCalendar
|
||||
├── dialogs.py (1127) finestre di dialogo
|
||||
├── lists.py (957) viste ad albero (eredi/preview/executor)
|
||||
├── window.py (952) controller GUI per-wallet (BalWindow)
|
||||
└── plugin.py (273) classe Plugin (@hook Electrum → GUI)
|
||||
```
|
||||
|
||||
Il file `qt.py` da 4131 righe è stato suddiviso per **responsabilità**. I
|
||||
**corpi delle classi sono stati copiati verbatim** (riga per riga) per non
|
||||
toccare la logica delicata delle transazioni di eredità.
|
||||
|
||||
### Mappa: dove sono finite le 40 classi/funzioni di `qt.py`
|
||||
|
||||
| Classe/funzione (riga orig.) | Nuovo modulo |
|
||||
|-------------------------------------|-------------------------|
|
||||
| `Plugin` (67) | `gui/qt/plugin.py` |
|
||||
| `shown_cv` (317) | `gui/qt/common.py` |
|
||||
| `BalWindow` (330) | `gui/qt/window.py` |
|
||||
| `add_widget` (1257) | `gui/qt/common.py` |
|
||||
| `ClickableLabel` (1263) | `gui/qt/widgets.py` |
|
||||
| `BalTxFeesWidget` (1271) | `gui/qt/widgets.py` |
|
||||
| `_LockTimeEditor` (1340) | `gui/qt/widgets.py` |
|
||||
| `BalTimeEditWidget` (1374) | `gui/qt/widgets.py` |
|
||||
| `TimeRawEditWidget` (1508) | `gui/qt/widgets.py` |
|
||||
| `LockTimeRawEdit` (1527) | `gui/qt/widgets.py` |
|
||||
| `LockTimeDateEdit` (1605) | `gui/qt/widgets.py` |
|
||||
| `ThresholdTimeWidget` (1644) | `gui/qt/widgets.py` |
|
||||
| `LockTimeWidget` (1664) | `gui/qt/widgets.py` |
|
||||
| `WillSettingsWidget` (1683) | `gui/qt/widgets.py` |
|
||||
| `PercAmountEdit` (1818) | `gui/qt/widgets.py` |
|
||||
| `BalDialog` (1883) | `gui/qt/dialogs.py` |
|
||||
| `BalWizardDialog` (1913) | `gui/qt/dialogs.py` |
|
||||
| `BalWizardWidget` (2002) | `gui/qt/dialogs.py` |
|
||||
| `BalWizardHeirsWidget` (2068) | `gui/qt/dialogs.py` |
|
||||
| `BalWizardWEDownloadWidget` (2103) | `gui/qt/dialogs.py` |
|
||||
| `BalWizardWEWidget` (2190) | `gui/qt/dialogs.py` |
|
||||
| `BalWizardLocktimeAndFeeWidget`(2207)| `gui/qt/dialogs.py` |
|
||||
| `BalWaitingDialog` (2224) | `gui/qt/dialogs.py` |
|
||||
| `BalBlockingWaitingDialog` (2285) | `gui/qt/dialogs.py` |
|
||||
| `BalLineEdit` (2304) | `gui/qt/widgets.py` |
|
||||
| `BalTextEdit` (2312) | `gui/qt/widgets.py` |
|
||||
| `BalCheckBox` (2320) | `gui/qt/widgets.py` |
|
||||
| `BalBuildWillDialog` (2335) | `gui/qt/dialogs.py` |
|
||||
| `HeirListWidget` (2858) | `gui/qt/lists.py` |
|
||||
| `PreviewList` (3059) | `gui/qt/lists.py` |
|
||||
| `WillDetailDialog` (3445) | `gui/qt/dialogs.py` |
|
||||
| `WillWidget` (3545) | `gui/qt/widgets.py` |
|
||||
| `WillExecutorListWidget` (3637) | `gui/qt/lists.py` |
|
||||
| `WillExecutorWidget` (3873) | `gui/qt/lists.py` |
|
||||
| `WillExecutorDialog` (3982) | `gui/qt/dialogs.py` |
|
||||
| `CheckAliveError` (4018) | `gui/qt/common.py` |
|
||||
| `log_error` (4028) | `gui/qt/common.py` |
|
||||
| `export_meta_gui` (4043) | `gui/qt/common.py` |
|
||||
| `BalCalendar` (4066) | `gui/qt/calendar.py` |
|
||||
|
||||
---
|
||||
|
||||
## 2. Rimozioni (codice morto / debug) — comportamento invariato
|
||||
|
||||
Tutte le rimozioni seguenti sono state verificate come **non utilizzate** o
|
||||
**puramente di debug**, quindi non alterano il comportamento del plugin.
|
||||
|
||||
1. **`util.py` → `core/util.py`**: rimossi tre helper di debug usati solo per
|
||||
stampe a console:
|
||||
- `print_var()` (orig. riga 439)
|
||||
- `print_utxo()` (orig. riga 474)
|
||||
- `print_prevout()` (orig. riga 486)
|
||||
|
||||
2. **`bal.py` → `core/plugin_base.py`**: rimossa la funzione **stub vuota**
|
||||
`get_will_settings(x)` (orig. righe 12-14):
|
||||
```python
|
||||
def get_will_settings(x):
|
||||
# print(x)
|
||||
pass
|
||||
```
|
||||
⚠️ Verificato: **non era riferita da nessun `register_dict`** — i tre
|
||||
`register_dict` usano `tuple`, `dict`, `lambda x: x`. Quindi era codice
|
||||
morto. La funzione **usata** `get_will(x)` è stata mantenuta identica.
|
||||
|
||||
3. **`will.py` (`WillItem`) → spostato in `gui/qt/theme.py`**: il metodo
|
||||
`WillItem.get_color()` (orig. riga 852) restituiva colori esadecimali —
|
||||
è logica di **presentazione**, non di dominio. È stato spostato fuori dal
|
||||
modello e trasformato nella funzione `status_color(will_item)` in
|
||||
`gui/qt/theme.py`. **Verificato byte-identico** su tutte le combinazioni di
|
||||
stato (stessa catena di `get_status(...)`, stessi codici colore).
|
||||
|
||||
---
|
||||
|
||||
## 3. Cambi di import (necessari per la nuova struttura)
|
||||
|
||||
Gli import sono stati aggiornati da "flat" a "a package". Esempi:
|
||||
|
||||
| Prima | Dopo |
|
||||
|------------------------------------|---------------------------------------|
|
||||
| `from .bal import BalPlugin` | `from .plugin_base import BalPlugin` (in willexecutors) |
|
||||
| `from .util import Util` | `from .util import Util` (invariato, ora dentro core/) |
|
||||
| (in qt.py) `from .bal import ...` | i moduli GUI importano da `...core.X` |
|
||||
|
||||
- Aggiunti `from .common import _, _logger` nei moduli GUI, perché `import *`
|
||||
**non** esporta i nomi che iniziano con underscore.
|
||||
- Aggiunti 3 import "lazy" (dentro le funzioni) in `dialogs.py` per spezzare il
|
||||
ciclo `dialogs ↔ lists` (lists importa `BalBuildWillDialog` da dialogs).
|
||||
|
||||
La **logica interna dei metodi** non è stata toccata: `prepare_transactions()`,
|
||||
`buildTransactions()` ecc. sono verbatim.
|
||||
|
||||
---
|
||||
|
||||
## 4. Packaging conforme allo standard Electrum
|
||||
|
||||
`manifest.json` reso conforme a https://plugins.electrum.org/developers.html :
|
||||
|
||||
| Campo | Prima | Dopo |
|
||||
|------------------|--------------------|-------------------------------|
|
||||
| `name` | `"BAL"` | `"bal"` (minuscolo = nome dir) |
|
||||
| `version` | (assente, era solo nella description) | `"0.2.8"` |
|
||||
| `description` | con `<br>` HTML | testo pulito |
|
||||
| `licence` | (assente) | `"MIT"` |
|
||||
| `fullname`/`author`/`available_for`/`icon` | presenti | invariati |
|
||||
|
||||
- `__init__.py` (era **vuoto**): ora contiene la docstring di architettura e
|
||||
`__version__ = "0.2.8"`.
|
||||
- Portati nel package: `LICENSE`, `VERSION`, `README.md`, `bal_resources.py`,
|
||||
e la cartella `wallet_util/` (invariata).
|
||||
|
||||
---
|
||||
|
||||
## 5. CORREZIONE BUG: caricamento come plugin esterno (.zip)
|
||||
|
||||
Durante i test su **Electrum 4.7.2 portable per Windows** sono emersi due
|
||||
problemi reali nel caricare il plugin come **plugin esterno da .zip**:
|
||||
|
||||
### Bug 5a — `ModuleNotFoundError: No module named 'electrum_external_plugins'`
|
||||
- **Causa:** Electrum carica i plugin esterni da zip sotto il package sintetico
|
||||
`electrum_external_plugins.bal`, ed esegue **solo** l'`__init__` del package e
|
||||
il modulo `qt`. Non registra il package radice sintetico né i sotto-package
|
||||
annidati (`gui`, `gui.qt`). Un semplice `from .gui.qt.plugin import Plugin`
|
||||
fallisce risalendo ai parent mancanti.
|
||||
- **Fix:** `qt.py` ora è uno shim resiliente che (1) rileva a runtime il proprio
|
||||
nome di package (`__package__`), (2) ricostruisce in `sys.modules` gli
|
||||
eventuali package padre mancanti, (3) importa `Plugin` con
|
||||
`importlib.import_module`. Funziona **sia** come plugin interno
|
||||
(`electrum.plugins.bal`) **sia** esterno (`electrum_external_plugins.bal`).
|
||||
|
||||
### Bug 5b — `zlib.error: Error -5 ... incomplete or truncated stream`
|
||||
- **Causa:** alcune build portable di Electrum su Windows non riescono a
|
||||
decomprimere con `zipimport` archivi che contengono **voci di directory** o
|
||||
compressione non standard.
|
||||
- **Fix:** aggiunto `build_zip.py`, che genera un archivio "zipimport-friendly":
|
||||
solo file (nessuna voce di directory), DEFLATE standard, ordine deterministico
|
||||
(SHA-256 riproducibile), escludendo `__pycache__`/`*.pyc`. Stampa anche
|
||||
l'hash SHA-256 per verificare l'integrità del download.
|
||||
|
||||
---
|
||||
|
||||
## 6. Test aggiunti
|
||||
|
||||
- `tests/smoke_test.py` — verifica import + comportamento di base
|
||||
(`BalTimestamp`, helper di `Util`, costanti `HEIR_*`, stati di `WillItem`,
|
||||
hook del `Plugin`).
|
||||
- `tests/external_zip_test.py` — riproduce **fedelmente** la sequenza di
|
||||
caricamento di un plugin esterno da zip di Electrum (regressione per il
|
||||
Bug 5a/5b).
|
||||
|
||||
Tutti i test passano sotto Electrum 4.7.2 + PyQt6.
|
||||
|
||||
---
|
||||
|
||||
## 7. Riepilogo: cosa NON è cambiato
|
||||
|
||||
- La logica di costruzione delle transazioni (`heirs.py`, `will.py`).
|
||||
- I valori e i tipi di `json_db.register_dict(...)`.
|
||||
- I codici colore degli stati (solo spostati in `theme.py`).
|
||||
- L'algoritmo di tutte le classi GUI (copiate verbatim).
|
||||
- Il formato dei dati salvati nel wallet.
|
||||
|
||||
## 8. Note / raccomandazioni
|
||||
|
||||
- Il plugin **richiede Electrum 4.7.2**: `json_db.register_dict` è stato
|
||||
**rimosso** nelle versioni successive (master), dove andrebbe sostituito con
|
||||
`stored_dict.register_name`. Valutare un adeguamento se si vuole supportare
|
||||
Electrum più recente.
|
||||
- Prima del rilascio è consigliata una prova **end-to-end in una sessione
|
||||
Electrum reale** (preferibilmente su testnet), oltre agli smoke test.
|
||||
|
||||
---
|
||||
|
||||
## 9. CORREZIONI GUI — finestre e ciclo di vita (B1-B10)
|
||||
|
||||
Dopo il refactoring di struttura sono stati corretti **dieci difetti grafici e
|
||||
di ciclo di vita** delle finestre, già presenti nel codice originale. La logica
|
||||
di business è rimasta **byte-identica** (nessuna modifica a `bal/core/*`): sono
|
||||
cambiati solo **presentazione, parent, modalità, z-order, ciclo di vita e
|
||||
cleanup** delle finestre Qt.
|
||||
|
||||
Sintomi segnalati dall'utente, ora risolti:
|
||||
- **(S1)** le finestre del plugin sparivano dietro la finestra di Electrum;
|
||||
- **(S2)** alcuni meccanismi funzionavano solo dopo aver chiuso e riavviato
|
||||
Electrum.
|
||||
|
||||
| ID | Problema (presente nell'originale) | Correzione applicata |
|
||||
|-----|----------------------------------------------------------------------|----------------------|
|
||||
| B1 | `self.parent = parent` sovrascriveva il metodo `parent()` di Qt, rompendo la gerarchia delle finestre | rinominato in `self._bal_parent` (in `dialogs.py`, `lists.py`, `widgets.py`); il parent reale passa da `top_level_of(parent)` |
|
||||
| B2 | dialoghi aperti con `.show()` non modale → finivano sotto la finestra principale | sostituiti con `show_on_top()` / `show_modal()` e parent corretto |
|
||||
| B3 | messaggio "Please restart Electrum to activate the BAL plugin": il plugin si attivava solo dopo riavvio | inizializzazione **a caldo** con `_setup_window()` che replica `load_wallet` — niente più riavvio |
|
||||
| B4 | chiave del dizionario finestre usava il **metodo** `winId` invece del valore | chiave stabile `_window_key()` basata su `id(window)` |
|
||||
| B5 | `on_close` ingoiava tutti gli errori con `except: pass` | riscritto: niente `except:pass`, log per ogni passo, reset pulito dello stato |
|
||||
| B6 | `BalBlockingWaitingDialog` bloccava il thread della GUI (`processEvents` commentato) | ripristinato `processEvents()` → GUI reattiva durante l'attesa |
|
||||
| B7 | `closeEvent`/`hideEvent` con cleanup del thread commentato | gestione esplicita di `closeEvent`/`hideEvent` + chiamata a `super()` |
|
||||
| B8 | `closeEvent` incompleto in alcuni dialog | gestione uniforme dello stato di chiusura |
|
||||
| B9 | `show()+raise_()` senza `activateWindow()` né modalità → finestra non in primo piano | `bring_to_front()` = `raise_()` + `activateWindow()` |
|
||||
| B10 | gestione multi-wallet / multi-finestra fragile; menu cercato per titolo `&Tools` | uso dell'API ufficiale `window.tools_menu` |
|
||||
|
||||
### Nuovo modulo: `gui/qt/window_utils.py` (119 righe)
|
||||
|
||||
Gli helper per la gestione delle finestre sono stati **centralizzati** in un
|
||||
unico modulo, così la stessa logica non viene duplicata nei vari dialog:
|
||||
|
||||
- `top_level_of(widget)` — risale alla finestra di primo livello corretta da
|
||||
usare come parent;
|
||||
- `bring_to_front(window)` — `raise_()` + `activateWindow()` per portare in
|
||||
primo piano;
|
||||
- `stop_thread(thread)` — stop+wait sicuro di un `TaskThread`;
|
||||
- `show_modal(dialog)` — apertura modale corretta (`exec()`);
|
||||
- `show_on_top(window)` — apertura non modale ma sopra le altre finestre.
|
||||
|
||||
`gui/qt/common.py` importa questi helper e li rende disponibili al resto della
|
||||
GUI.
|
||||
|
||||
---
|
||||
|
||||
## 10. CORREZIONE BUG: download lista will-executor
|
||||
|
||||
Dopo l'installazione del pacchetto con le correzioni GUI, l'utente ha
|
||||
segnalato che il comando **"download list"** dei will-executor non scaricava
|
||||
più la lista.
|
||||
|
||||
### Indagine
|
||||
|
||||
Il codice di rete (`core/willexecutors.py`: `send_request`, `handle_response`,
|
||||
`download_list`, `initialize_willexecutor`) è stato confrontato riga per riga
|
||||
con l'originale Gitea ed è risultato **byte-identico** (l'unica differenza è il
|
||||
parametro aggiuntivo `welist_server` in `download_list`, retro-compatibile).
|
||||
|
||||
Durante l'indagine sono comunque emersi e stati corretti **due difetti reali**
|
||||
introdotti dalle correzioni GUI, che potevano "perdere" il risultato del
|
||||
download:
|
||||
|
||||
1. **`BalDialog.closeEvent`/`hideEvent` fermavano il `TaskThread`.** In Electrum
|
||||
`TaskThread.on_done` esegue `cb_done` (cioè `self.accept`, che **chiude** il
|
||||
dialog) **prima** di `cb_result` (cioè `on_success`, che **aggiorna** la
|
||||
lista). Fermare il thread alla chiusura del dialog **scartava** quindi il
|
||||
risultato appena scaricato. → I due metodi sono stati riportati a **non**
|
||||
fermare il thread (con commento esplicativo nel codice).
|
||||
2. **`BalWaitingDialog.exe()` usava una modalità sbagliata** (`show_modal` /
|
||||
`WindowModal`). → Ripristinato l'originale `self.exec()`, aggiungendo prima
|
||||
`bring_to_front(self)` per garantire il primo piano.
|
||||
|
||||
Inoltre i percorsi del **pulsante** e del **wizard** (che prima scaricavano in
|
||||
modi diversi e con messaggi diversi) sono stati **unificati** in un unico
|
||||
helper `fetch_will_executors_list`, eseguito dentro il worker del `TaskThread`.
|
||||
|
||||
### Causa vera del mancato download: ambientale, NON del plugin
|
||||
|
||||
Una probe di controllo con `urllib` che **bypassava completamente Electrum**
|
||||
falliva ugualmente con `WinError 10054` ("connection forcibly closed by remote
|
||||
host"): segno che la **rete/ISP dell'utente resettava la connessione HTTPS**
|
||||
verso `welist.bitcoin-after.life`. La conferma definitiva: **attivando una VPN
|
||||
il download è andato a buon fine.**
|
||||
|
||||
L'originale "sembrava" funzionare perché spedisce comunque un will-executor di
|
||||
**default già incorporato** (`https://we.bitcoin-after.life`), quindi la lista
|
||||
non risultava mai del tutto vuota anche senza un download riuscito.
|
||||
|
||||
### Pulizia finale (scelta dall'utente — "Opzione 1")
|
||||
|
||||
- **Finestra di attesa non bloccante** mantenuta (`BalWaitingDialog`), così la
|
||||
GUI non si congela durante il download.
|
||||
- **Fallback dell'URL**: prima l'URL configurato (`WELIST_SERVER`), poi quello
|
||||
hardcoded `https://welist.bitcoin-after.life/`.
|
||||
- **Diagnostica dettagliata spostata nei soli log** (rimossa la probe `urllib`
|
||||
dall'interfaccia).
|
||||
- **Messaggio d'errore semplice per l'utente, in inglese** (`DOWNLOAD_FAILED_MESSAGE`):
|
||||
|
||||
> *"Could not download the will-executors list. This is usually caused by
|
||||
> your internet connection or a firewall, not by the plugin. Please check
|
||||
> your connection (a VPN often helps) and try again."*
|
||||
|
||||
### File toccati (solo presentazione/GUI, logica invariata)
|
||||
|
||||
- `gui/qt/window.py` — helper condiviso `fetch_will_executors_list`,
|
||||
`download_list` con `TaskThread` + `BalWaitingDialog`, costante
|
||||
`DOWNLOAD_FAILED_MESSAGE`.
|
||||
- `gui/qt/lists.py` — `WillExecutorWidget.download_list` instradato sul
|
||||
percorso condiviso con `on_success` che aggiorna/salva la lista.
|
||||
- `gui/qt/dialogs.py` — `BalDialog.closeEvent`/`hideEvent` **non** fermano più
|
||||
il thread; `BalWaitingDialog.exe()` torna a `self.exec()` + `bring_to_front`.
|
||||
- `tests/gui_fixes_test.py` — asserzione di **regressione**: verifica che
|
||||
`closeEvent`/`hideEvent` **non** contengano `stop_thread` (per non
|
||||
reintrodurre il bug che scartava il download).
|
||||
|
||||
---
|
||||
|
||||
## 11. Confronto strutturale finale (originale Gitea → refactor)
|
||||
|
||||
Conteggio file `.py` (escluse cartelle generate):
|
||||
|
||||
| Originale (Gitea) | righe | → | Refactor (`bal/`) | righe |
|
||||
|------------------------------|------:|----|-------------------------------------------|------:|
|
||||
| `__init__.py` | 1 | → | `__init__.py` | 37 |
|
||||
| `bal.py` | 161 | → | `core/plugin_base.py` | 351 |
|
||||
| `util.py` | 1051 | → | `core/util.py` | 614 |
|
||||
| `heirs.py` | 792 | → | `core/heirs.py` | 806 |
|
||||
| `will.py` | 903 | → | `core/will.py` | 938 |
|
||||
| `willexecutors.py` | 547 | → | `core/willexecutors.py` | 390 |
|
||||
| `qt.py` (monolite GUI) | 3777 | → | suddiviso in `gui/qt/*` (vedi sotto) | — |
|
||||
| `bal_resources.py` | 14 | → | `bal_resources.py` | 14 |
|
||||
| `wallet_util/*.py` | 275 | → | `wallet_util/*.py` (invariati) | 280 |
|
||||
|
||||
Suddivisione del vecchio `qt.py` (3777 righe) nei moduli GUI:
|
||||
|
||||
| Modulo refactor | righe | Contenuto |
|
||||
|-----------------------------|------:|-----------|
|
||||
| `gui/qt/plugin.py` | 303 | classe `Plugin` (`@hook` Electrum → GUI) |
|
||||
| `gui/qt/window.py` | 1048 | `BalWindow` (controller per-wallet) |
|
||||
| `gui/qt/dialogs.py` | 1155 | finestre di dialogo + wizard |
|
||||
| `gui/qt/lists.py` | 964 | viste ad albero (eredi/preview/executor) |
|
||||
| `gui/qt/widgets.py` | 782 | widget "foglia" |
|
||||
| `gui/qt/common.py` | 157 | import condivisi + helper |
|
||||
| `gui/qt/window_utils.py` | 119 | helper finestre (NUOVO — vedi §9) |
|
||||
| `gui/qt/calendar.py` | 80 | `BalCalendar` |
|
||||
| `gui/qt/theme.py` | 59 | mappatura stato → colore |
|
||||
| `gui/qt/__init__.py` | 17 | init package GUI |
|
||||
|
||||
> Le differenze nei conteggi di righe rispetto all'originale derivano da:
|
||||
> riformattazione/commenti, separazione degli import per modulo, e spostamento
|
||||
> di funzioni tra `util.py`/`bal.py` e i nuovi moduli. **Gli algoritmi non sono
|
||||
> stati modificati.**
|
||||
|
||||
---
|
||||
|
||||
## 12. Cronologia delle modifiche su GitHub
|
||||
|
||||
- **`4198a51`** — import iniziale del refactor strutturale (v0.2.8): separazione
|
||||
`core/` (logica) vs `gui/qt/` (presentazione), packaging conforme, fix
|
||||
caricamento zip esterno, smoke test (sezioni §1-§8).
|
||||
- **`d56fa36`** — questo changelog del refactoring (in italiano).
|
||||
- **`4806997`** — `DIAGNOSI_GUI.md`: diagnosi dei bug GUI di z-order e ciclo di
|
||||
vita (Fase A).
|
||||
- **`dd6f677`** (PR **#2**, squash) — correzioni GUI **B1-B10** + fix download
|
||||
lista will-executor + `window_utils.py` + test di regressione (sezioni §9-§10).
|
||||
- **PR #3** — fix **OverflowError su Windows (anno 2038)** che rompeva le schede
|
||||
Will/Heirs e la voce di menu (sezione §13).
|
||||
|
||||
---
|
||||
|
||||
## 13. CORREZIONE BUG: OverflowError su Windows (limite anno 2038)
|
||||
|
||||
### Sintomo (Windows 11)
|
||||
Dopo aver **riavviato Electrum** o **cambiato wallet**, le schede **Will** e
|
||||
**Heirs** sparivano e compariva una **voce di menu condensata/illeggibile**
|
||||
(icona + testo sovrapposti) sotto il logo di Electrum, accanto a *Portafogli*.
|
||||
Su Linux il problema non si manifestava.
|
||||
|
||||
### Causa vera (dal log di Electrum dell'utente)
|
||||
```
|
||||
OverflowError: Python int too large to convert to C int
|
||||
window.py __init__ -> create_heirs_tab -> WillSettingsWidget
|
||||
-> on_locktime_change -> BalTimestamp.to_date
|
||||
-> datetime.fromtimestamp(NLOCKTIME_MAX)
|
||||
```
|
||||
|
||||
- `NLOCKTIME_MAX = 2**32 - 1 = 4294967295` viene usato come locktime di
|
||||
**default/sentinella**.
|
||||
- Su **Windows** `time_t` è a **32 bit**, quindi `datetime.fromtimestamp(ts)`
|
||||
solleva **`OverflowError`** per qualsiasi timestamp oltre il **2038**.
|
||||
- Su **Linux 64-bit** la stessa chiamata **funziona**: ecco perché il bug si
|
||||
vedeva solo su Windows e i test su Linux non lo intercettavano.
|
||||
- L'eccezione interrompeva `BalWindow.__init__` durante `init_menubar` /
|
||||
`load_wallet`, lasciando le schede Will/Heirs e la voce di menu **a metà
|
||||
costruzione** → l'elemento grafico condensato/illeggibile sotto il logo.
|
||||
|
||||
> Nota: i due primi tentativi di correzione (status-bar no-op e idempotenza di
|
||||
> `init_menubar_tools`) **non** centravano la causa; sono stati comunque
|
||||
> mantenuti perché innocui e leggermente migliorativi, ma il vero colpevole era
|
||||
> questo crash a monte.
|
||||
|
||||
### Fix (comportamento invariato per tutti i valori normali)
|
||||
- **`BalTimestamp._safe_fromtimestamp()`**: `datetime.fromtimestamp` con
|
||||
**clamp a INT32_MAX** (anno 2038) in caso di `OverflowError`/`OSError`/
|
||||
`ValueError`, **esattamente** come la funzione `get_max_allowed_timestamp()`
|
||||
dell'originale (workaround per Electrum issue **#6170**).
|
||||
- Usato in `to_date` / `to_timestamp` / `__str__` / `__repr__` di
|
||||
`BalTimestamp`.
|
||||
- `gui/qt/widgets.py` (`set_value`): usa il converter sicuro.
|
||||
- `core/util.py` (`timestamp_minus`): stessa protezione inline con clamp a
|
||||
INT32_MAX.
|
||||
|
||||
I valori entro il 2038 (date assolute normali, durate relative come `90d`/`5y`)
|
||||
producono **lo stesso identico risultato** di prima.
|
||||
|
||||
### Test
|
||||
- `tests/windows_overflow_test.py` riproduce il limite 32-bit di Windows
|
||||
(monkeypatch di `datetime.fromtimestamp`) e dimostra che **senza** il fix si
|
||||
ottiene lo **stesso** `OverflowError` del log, mentre **con** il fix passa.
|
||||
Verificato anche che il test **fallisce** senza il fix.
|
||||
|
||||
Confermato dall'utente: **"si ora funziona"**.
|
||||
|
||||
## 14. NUOVA FUNZIONE: invalidazione automatica al posticipo dell'eredità
|
||||
|
||||
### Problema
|
||||
Una transazione di eredità viene firmata con un **locktime fisso e immutabile**
|
||||
e inviata ai will-executor, che sono economicamente incentivati a trasmetterla
|
||||
(incassano le fee). Se l'utente, dopo aver firmato/inviato, **posticipa** la
|
||||
data di consegna (es. di un anno), la **vecchia** transazione gia firmata resta
|
||||
valida sui server dei will-executor. Poiche ha il locktime piu basso, un
|
||||
will-executor potrebbe trasmetterla appena scade, eseguendo l'eredita **in
|
||||
anticipo** rispetto alla nuova volonta dell'utente. La versione precedente
|
||||
**non gestiva** questo caso: il posticipo non produceva alcuna azione.
|
||||
|
||||
### Soluzione (Strategia B — invalidazione esplicita on-chain)
|
||||
Al posticipo di un'eredita **gia firmata e/o inviata** (stato `COMPLETE` o
|
||||
`PUSHED`), il plugin chiede di **invalidare on-chain** i fondi prima di
|
||||
ricostruire la nuova eredita. L'invalidazione spende gli stessi UTXO verso un
|
||||
nuovo indirizzo di change con `locktime = altezza corrente` (RBF), quindi e
|
||||
trasmettibile subito: una volta confermata, la vecchia transazione pre-firmata
|
||||
diventa **definitivamente inutilizzabile**, vincendo la corsa contro qualunque
|
||||
will-executor.
|
||||
|
||||
### Dettagli tecnici
|
||||
- **`core/will.py`**:
|
||||
- nuova eccezione `WillPostponedException` (sottoclasse di
|
||||
`NotCompleteWillException`);
|
||||
- `check_willexecutors_and_heirs`: il confronto del locktime non usa piu
|
||||
l'entry dell'erede memorizzata (`their[2]`), che viene aggiornata in memoria
|
||||
insieme al nuovo valore al momento del posticipo e quindi risulterebbe
|
||||
sempre uguale. Ora confronta il locktime richiesto con **`w.tx.locktime`**,
|
||||
cioe il locktime **congelato** nella transazione firmata (immutabile, e
|
||||
quello che i will-executor possiedono). Tre casi: invariato → coerente;
|
||||
nuovo > tx su will firmato/inviato → `WillPostponedException`; nuovo > tx su
|
||||
will mai inviato → semplice ricostruzione (nessuna fee on-chain).
|
||||
- **`gui/qt/dialogs.py`** (`BalBuildWillDialog.task_phase1`, il percorso reale
|
||||
usato da **Tools → Prepare**): aggiunto il ramo `except WillPostponedException`
|
||||
**prima** di `NotCompleteWillException`; si comporta come il caso "will
|
||||
scaduto" e ritorna `(None, tx)` per innescare firma + broadcast
|
||||
dell'invalidazione. L'utente preme di nuovo **Prepare** per ricostruire,
|
||||
rifirmare e reinviare la nuova eredita (due passi espliciti, per maggior
|
||||
controllo).
|
||||
- **`gui/qt/window.py`** (`build_inheritance_transaction`): aggiunto lo stesso
|
||||
ramo per completezza del percorso alternativo, con messaggio esplicativo.
|
||||
- **`gui/qt/common.py`**: `WillPostponedException` esportato.
|
||||
|
||||
### NUOVA COLONNA "Server" nella lista transazioni
|
||||
Per dare all'utente visibilita costante sullo stato online delle proprie
|
||||
transazioni di eredita, e stata aggiunta una colonna dedicata **"Server"** in
|
||||
`PreviewList` (`gui/qt/lists.py`), con etichetta sempre leggibile
|
||||
(`Confirmed on server`, `Sent (not checked)`, `Send failed`, `Not on server`,
|
||||
`Signed (not sent)`, `Not sent`) e **tooltip** con URL del will-executor e
|
||||
stato. Le funzioni `server_status_text()` e `server_status_tooltip()` sono in
|
||||
`gui/qt/theme.py` e riusano gli stessi flag di stato gia esistenti.
|
||||
|
||||
### Test
|
||||
- I 182 test ufficiali continuano a passare; smoke test ed external-zip test
|
||||
OK; `ruff` senza nuove segnalazioni reali.
|
||||
- Verificato sui dati reali del log dell'utente: il posticipo di un'eredita
|
||||
firmata ora rileva correttamente la condizione e avvia l'invalidazione.
|
||||
|
||||
Confermato dall'utente: **"mi pare che funziona"**.
|
||||
|
||||
## 15. TENTATIVO E REVERT: fix doppia invalidazione al posticipo (v0.3.1 -> v0.3.2)
|
||||
|
||||
### v0.3.1 (RITIRATA)
|
||||
Per risolvere la doppia firma dell'invalidazione al posticipo, era stato
|
||||
introdotto `Will.mark_invalidated_by_tx()`, chiamato in
|
||||
`loop_broadcast_invalidating` dopo il broadcast dell'invalidazione, per marcare
|
||||
`INVALIDATED` le will che spendevano gli stessi UTXO della tx di invalidazione
|
||||
e persistere lo stato con `save_willitems`.
|
||||
|
||||
### Perche e stata ritirata
|
||||
La modifica ha introdotto una regressione grave segnalata dall'utente:
|
||||
**la lista eredita mostrava ancora le vecchie eredita e l'aggiornamento di
|
||||
eredi/date risultava incoerente**.
|
||||
|
||||
Causa: `loop_broadcast_invalidating` e il punto di broadcast usato per **TUTTI**
|
||||
i tipi di invalidazione (posticipo, CheckAlive, will scaduto/anticipato), non
|
||||
solo per il posticipo. Inoltre il metodo marcava e **persisteva** lo stato
|
||||
`INVALIDATED` su tutte le will item che condividevano gli UTXO del wallet
|
||||
(tipicamente tutte). Queste will item invalidate restavano poi in memoria e su
|
||||
disco, inquinando la ricostruzione di eredi/date e lasciando vecchie voci nella
|
||||
lista.
|
||||
|
||||
### v0.3.2 (questa versione): REVERT completo
|
||||
- Rimosso `Will.mark_invalidated_by_tx()` da `core/will.py`.
|
||||
- Rimossa la chiamata in `gui/qt/dialogs.py` (`loop_broadcast_invalidating`):
|
||||
il metodo torna **identico** alla v0.3.0.
|
||||
- Rimossi i due test relativi; mantenuto solo l'assert di gerarchia su
|
||||
`WillPostponedException` (corretto e indipendente).
|
||||
- `core/will.py` e `gui/qt/dialogs.py` sono ora **byte-identici** alla v0.3.0
|
||||
funzionante (verificato con `git diff a394cde`).
|
||||
|
||||
Il bug della doppia invalidazione al posticipo resta quindi **aperto** e andra
|
||||
riaffrontato in modo piu mirato (senza toccare il percorso di broadcast comune e
|
||||
senza persistere stati su will che condividono gli UTXO), previa conferma
|
||||
dell'utente. La priorita era ripristinare il comportamento corretto di
|
||||
lista/eredi/date.
|
||||
|
||||
## 16. Aggiornamenti mancati, Check/Close coerenti, e rifinitura UI (v0.3.2)
|
||||
|
||||
### FIX 1 - Rimozione di un erede rilevata su Check / chiusura Electrum
|
||||
`core/will.py` (`check_willexecutors_and_heirs`): prima il plugin
|
||||
rilevava solo l'**aggiunta** di un erede (raise `HeirNotFoundException` quando un
|
||||
erede corrente non era piu nella will). Mancava il caso inverso: la
|
||||
**rimozione** di un erede. Aggiunto il ramo `else` che lancia
|
||||
`HeirNotFoundException` anche quando la will porta ancora un erede che non e piu
|
||||
presente nel set di eredi corrente. Cosi la ricostruzione dell'eredita scatta su
|
||||
**Check** e alla **chiusura di Electrum** (entrambi usano lo stesso percorso
|
||||
`BalBuildWillDialog.build_will_task()`), come deciso dall'utente: nessun
|
||||
aggiornamento automatico dopo la modifica, solo manuale con Check / alla
|
||||
chiusura.
|
||||
|
||||
### FIX 2 - Check interroga i server anche per le will gia inviate
|
||||
`core/will.py` (nuovo `Will.needs_server_check(w)`) e
|
||||
`gui/qt/lists.py` (`PreviewList.check`): prima il Check interrogava i server solo
|
||||
per le will in stato `PUSHED`. Le will gia inviate ma rimaste su "New / Not sent"
|
||||
non venivano ricontrollate ("nothing to do"). Ora `needs_server_check` include
|
||||
ogni will **VALID** con un will-executor e **non ancora CHECKED**, anche se non
|
||||
in stato `PUSHED`. Stesso controllo usato sia dal pulsante Check sia da
|
||||
`on_close`.
|
||||
|
||||
### FIX 3 - Hide invalidated/replaced da finestra Impostazioni aggiornava la lista
|
||||
`core/plugin_base.py` (nuovo `sync_hide_filters()`) e
|
||||
`gui/qt/window.py` (`update_all`): le checkbox "Hide Replaced" / "Hide
|
||||
Invalidated" nella finestra Impostazioni scrivono direttamente la config
|
||||
(`BalConfig.set`) senza toccare i flag in cache `_hide_invalidated` /
|
||||
`_hide_replaced` usati dalla lista per filtrare. Risultato: la lista continuava
|
||||
a filtrare col valore vecchio finche non si riavviava Electrum. Ora
|
||||
`update_all()` chiama `sync_hide_filters()` che ri-legge i flag dalla config,
|
||||
quindi qualunque sorgente del cambiamento (toolbar o finestra Impostazioni)
|
||||
aggiorna subito la lista.
|
||||
|
||||
### Rifinitura UI - Risultati in grassetto nel dialog "Building Will"
|
||||
`gui/qt/dialogs.py` (`BalBuildWillDialog`): i **risultati** mostrati a destra di
|
||||
ogni riga di stato (es. `Ok`, `Ko`, `Nothing to do`, `Skipped`, `Wait`,
|
||||
`Timeout`) sono ora resi in **grassetto**, mantenendo i loro colori
|
||||
(verde/rosso/giallo). Le etichette di stato a sinistra restano in peso normale.
|
||||
Modifica centralizzata negli helper `msg_ok`, `msg_error`, `msg_warning`,
|
||||
`msg_set_status`, piu le righe dei will-executor (push e check) che ora mostrano
|
||||
`Ok/Ko` e `True/False` in grassetto + colore (verde/rosso).
|
||||
|
||||
### Test
|
||||
- 186 test ufficiali passano; smoke test, external-zip test e simulazione dei
|
||||
flussi di aggiornamento (`tests/sim_update_flows.py`) OK; `ruff` senza nuove
|
||||
segnalazioni reali (solo falsi positivi pre-esistenti da star-import).
|
||||
- Aggiunti test in `tests/test_core_will.py`:
|
||||
`test_check_heirs_unchanged_is_coherent`,
|
||||
`test_check_heir_removed_triggers_rebuild`,
|
||||
`test_check_heir_added_triggers_rebuild`, `test_needs_server_check`.
|
||||
|
||||
Confermato dall'utente sui dati reali: dopo Sign -> Broadcast -> Check le
|
||||
transazioni gia inviate sono tornate verdi ("confirmed on server"); la lista
|
||||
torna pulita; il grassetto e l'aggiornamento delle hide-flag funzionano.
|
||||
|
||||
## 17. UI polish and bug fix — signed-tx colour, wizard, Building Will dialog (v0.3.3)
|
||||
|
||||
This session groups several behaviour-invariant UI refinements plus one colour
|
||||
bug fix. All comments and code remain in English; only the chat with the
|
||||
author was in Italian.
|
||||
|
||||
### FIX — Signed-but-not-sent transaction shown RED instead of blue
|
||||
`core/will.py` (`needs_server_check`): a previous-session change (section 16,
|
||||
"FIX 2") had removed the `PUSHED` requirement from `needs_server_check`, so a
|
||||
will that was *signed but never broadcast* was still server-queried. The query
|
||||
returned CHECK_FAIL, and because `status_color()` checks CHECK_FAIL (red,
|
||||
`#e83845`) before COMPLETE (blue, `#2bc8ed`), the row turned red. Restored the
|
||||
original Gitea `check()` condition by adding back `and w.get_status("PUSHED")`,
|
||||
so only already-broadcast wills are server-checked. A signed-but-not-sent will
|
||||
now stays blue (COMPLETE) as in the original.
|
||||
- `tests/test_core_will.py` (`test_needs_server_check`): a freshly-built item
|
||||
(VALID, not PUSHED) now correctly expects `False`.
|
||||
|
||||
### Wizard "Will Settings" — equal-width, left-aligned rows
|
||||
`gui/qt/widgets.py` (`WillSettingsWidget`, vertical layout): the calendar button
|
||||
and the fee field used to stretch to the dialog's right edge, far wider than the
|
||||
date rows. Now every row is capped to the widest date-row width (`row_w`) and
|
||||
left-aligned, so they form a tidy column. The leading icons keep their original
|
||||
`HelpButton` width (`icon_w` is used only as a spacer in front of the calendar,
|
||||
never to widen the icons themselves).
|
||||
|
||||
### Wizard button — icon + text
|
||||
`gui/qt/lists.py` (`create_toolbar`): the "build your will" toolbar button is now
|
||||
more inviting: a 28×28 wizard icon plus a bold `"Create your will"` caption,
|
||||
`setMinimumHeight(40)`. `gui/qt/common.py` gained `QSize` in the QtCore import.
|
||||
|
||||
### Building Will dialog — clearer final report + manual Close
|
||||
`gui/qt/dialogs.py` (`BalBuildWillDialog`):
|
||||
- The closing summary line is no longer a bare "Ok": it now has an explicit
|
||||
left-side label, `"All done: Ok"`, like the other result rows.
|
||||
- A blank separator row is inserted above "All done" so the overall outcome is
|
||||
visually detached from the per-step rows.
|
||||
- The four `"checking variables"` status strings are capitalised to
|
||||
`"Checking variables"` to match the rows below; the redundant trailing colon
|
||||
on the final one was dropped (`msg_set_status` already adds `":\t"`).
|
||||
- The final auto-closing countdown (`self.wait(5)`) was replaced by an explicit
|
||||
right-aligned **"Close"** button (`_add_close_button` / `_on_close_clicked`).
|
||||
The dialog now stays open until the user dismisses it, so the full report can
|
||||
be read at leisure. The intermediate technical pauses (`wait(10)`, `wait(5)`,
|
||||
`wait(3)`) are kept. Closing still shows the persistent "next steps"
|
||||
(Sign / Broadcast) popup when `self._next_steps_hint` is set.
|
||||
|
||||
### Preview helpers (dev-only, not shipped logic)
|
||||
`tests/preview_wizard_settings_align.py`, `tests/preview_wizard_button.py`,
|
||||
`tests/preview_building_will_close_btn.py`: small offscreen scripts used to
|
||||
render before/after mock-ups for visual approval.
|
||||
|
||||
### Test
|
||||
- 186 official tests pass; smoke test, external-zip test OK.
|
||||
- `ruff` reports only the pre-existing baseline false positives (F401/F403/F405
|
||||
star-import re-exports, one F841, one F541) — no new issues.
|
||||
- Version bumped to **0.3.3** (`bal/VERSION`, `bal/__init__.py`,
|
||||
`bal/manifest.json`).
|
||||
|
||||
## 18. Documentation site (docs/) — no behaviour change
|
||||
|
||||
Added a `docs/` tree that renders directly on GitHub and GitHub Pages (no PDF):
|
||||
|
||||
- `docs/inheritance-options.md` + `.html`: a code‑accurate **Inheritance Options
|
||||
Guide** covering every change a user can make (date earlier/later, add/remove
|
||||
heir, change percentages, fees, will‑executors), each transaction status flag
|
||||
and its colour, and what happens on the will‑executor servers. Includes a
|
||||
decision **flow chart** (GitHub‑native Mermaid block in the `.md`, plus a
|
||||
static SVG fallback `docs/images/inheritance-flow.svg`, plus a live Mermaid
|
||||
render in the `.html`). Behaviour is derived directly from
|
||||
`core/will.py::is_will_valid` / `check_willexecutors_and_heirs` and
|
||||
`gui/qt/window.py::build_inheritance_transaction`.
|
||||
- `docs/manual/README.md` + `manual.html` + `images/`: the official **BAL User
|
||||
Manual (revB)** converted from the upstream Gitea PDF into GitHub‑friendly
|
||||
Markdown/HTML with the original screenshots re‑rendered at high resolution
|
||||
(`docs/manual/images/fig*.png`, `logo.png`).
|
||||
- `docs/README.md`: documentation index linking both documents.
|
||||
|
||||
No plugin code changed; 186 tests still pass.
|
||||
319
DIAGNOSI_GUI.md
Normal file
319
DIAGNOSI_GUI.md
Normal file
@@ -0,0 +1,319 @@
|
||||
# BAL — Diagnosi dei problemi GUI (Fase A) → ✅ RISOLTI (Fase B)
|
||||
|
||||
> **STATO: tutti i bug B1-B10 sono stati CORRETTI** e mergiati in `main`
|
||||
> (PR #2, squash `dd6f677`). La logica di business resta **byte-identica**
|
||||
> (nessuna modifica a `bal/core/*`): sono cambiati solo presentazione, parent,
|
||||
> modalità, ciclo di vita e cleanup delle finestre.
|
||||
>
|
||||
> | ID | Stato | Fix applicato |
|
||||
> |----|-------|---------------|
|
||||
> | B1 | ✅ FIXED | `self.parent` → `self._bal_parent` (dialogs/lists/widgets); parent = `top_level_of(parent)` |
|
||||
> | B2 | ✅ FIXED | `.show()` → `show_on_top()` / `show_modal()` con parent corretto |
|
||||
> | B3 | ✅ FIXED | init a caldo: `_setup_window()` replica `load_wallet`, niente "restart Electrum" |
|
||||
> | B4 | ✅ FIXED | chiave finestra stabile `_window_key()` = `id(window)` |
|
||||
> | B5 | ✅ FIXED | `on_close` riscritto: niente `except:pass`, log per-step, reset stato |
|
||||
> | B6 | ✅ FIXED | `BalBlockingWaitingDialog`: `processEvents()` ripristinato |
|
||||
> | B7 | ✅ FIXED | `closeEvent/hideEvent`: `stop_thread()` + `super()` |
|
||||
> | B8 | ✅ FIXED | `closeEvent`: `stop_thread()` (stop+wait) + `super()` |
|
||||
> | B9 | ✅ FIXED | `bring_to_front()` = `raise_()` + `activateWindow()` |
|
||||
> | B10| ✅ FIXED | uso di `window.tools_menu` (API ufficiale), niente ricerca per titolo `&Tools` |
|
||||
>
|
||||
> Helper centralizzati in `bal/gui/qt/window_utils.py`:
|
||||
> `top_level_of`, `bring_to_front`, `stop_thread`, `show_modal`, `show_on_top`.
|
||||
> Test di regressione: `tests/gui_fixes_test.py` (oltre a smoke + external_zip).
|
||||
|
||||
---
|
||||
|
||||
## (Storico) Diagnosi originale
|
||||
|
||||
Documento di sola **diagnosi**: nessuna riga di codice funzionale era stata
|
||||
modificata in Fase A. Elenca i problemi grafici/di ciclo di vita riscontrati nel
|
||||
codice, la loro **causa tecnica** e il **fix proposto**, con riferimenti riga.
|
||||
|
||||
I due sintomi che hai segnalato:
|
||||
- **(S1)** Le finestre del plugin spariscono dietro la finestra di Electrum.
|
||||
- **(S2)** Alcuni meccanismi funzionano solo dopo aver chiuso e "ripulito"
|
||||
Electrum.
|
||||
|
||||
Sono entrambi spiegati dai bug qui sotto.
|
||||
|
||||
---
|
||||
|
||||
## Riepilogo (tabella)
|
||||
|
||||
| ID | Gravità | Sintomo | File:riga | Causa breve |
|
||||
|----|---------|---------|-----------|-------------|
|
||||
| B1 | 🔴 Alta | S1 | `dialogs.py:40,69,475` | `self.parent = parent` sovrascrive il metodo `QWidget.parent()` |
|
||||
| B2 | 🔴 Alta | S1 | `window.py:148,936`, `window.py:566` | dialoghi aperti con `.show()` (non-modali, senza stare in primo piano) |
|
||||
| B3 | 🔴 Alta | S2 | `plugin.py:38-42` | messaggio "Please restart Electrum" = init a caldo non gestito |
|
||||
| B4 | 🔴 Alta | S2 | `plugin.py:45,111` | chiave dizionario `winId` (metodo) invece di `winId()` (valore) |
|
||||
| B5 | 🟠 Media | S2 | `window.py:664-677` | `on_close` con `except: pass` che nasconde errori di cleanup |
|
||||
| B6 | 🟠 Media | S1/S2 | `dialogs.py:445-462` | `BalBlockingWaitingDialog` blocca il thread GUI, `processEvents` commentato |
|
||||
| B7 | 🟠 Media | S2 | `dialogs.py:48-58` | `closeEvent/hideEvent` con cleanup thread commentato |
|
||||
| B8 | 🟠 Media | S2 | `dialogs.py:828-830` | `closeEvent` chiama `thread.stop()` ma non `thread.wait()` né `super()` |
|
||||
| B9 | 🟡 Bassa | S1 | `dialogs.py:1121-1122` | `show()+raise_()` senza `activateWindow()` né modalità |
|
||||
| B10| 🟡 Bassa | — | `plugin.py:36` (init), vari | gestione finestre multiple/ multi-wallet fragile |
|
||||
|
||||
---
|
||||
|
||||
## Dettaglio dei problemi
|
||||
|
||||
### B1 — `self.parent = parent` rompe il sistema di finestre di Qt 🔴
|
||||
**Dove:** `dialogs.py:40` (in `BalDialog.__init__`), ripetuto a `:69` e `:475`;
|
||||
analoghi in altri dialoghi.
|
||||
|
||||
```python
|
||||
self.parent = parent # <-- PROBLEMA
|
||||
super().__init__(parent)
|
||||
```
|
||||
|
||||
**Causa:** in Qt, `parent()` è un **metodo** di `QWidget` che restituisce il
|
||||
widget genitore. Assegnando un **attributo** `self.parent`, lo si maschera: da
|
||||
quel punto `self.parent` non è più il metodo ma il valore salvato. Qualunque
|
||||
codice (anche interno a Qt o di Electrum) che si aspetta `widget.parent()` come
|
||||
metodo può comportarsi in modo imprevisto. Inoltre il `parent` passato non è
|
||||
sempre la **top-level window** corretta, quindi il dialogo non viene agganciato
|
||||
gerarchicamente alla finestra di Electrum e finisce **dietro** (S1).
|
||||
|
||||
**Fix proposto:**
|
||||
- Non sovrascrivere `parent`: rinominare l'attributo (es. `self._bal_parent`).
|
||||
- Passare sempre come `parent` la **top-level window** di Electrum
|
||||
(`window.top_level_window()`), così il dialogo resta in primo piano rispetto
|
||||
ad essa.
|
||||
|
||||
---
|
||||
|
||||
### B2 — Dialoghi aperti con `.show()` invece che modali 🔴
|
||||
**Dove:**
|
||||
- `window.py:148` `show_willexecutor_dialog` → `self.willexecutor_dialog.show()`
|
||||
- `window.py:936` `preview_modal_dialog` → `self.dw.show()` (il nome dice
|
||||
"modal" ma usa `show()`!)
|
||||
- `window.py:566` `show_transaction_real` → `d.show()`
|
||||
|
||||
**Causa:** `show()` apre una finestra **non-modale e indipendente**: se il
|
||||
`parent` non è impostato correttamente (vedi B1), la finestra non resta sopra
|
||||
Electrum e ci "sparisce dietro" (S1). Si nota l'incoerenza: altrove si usa
|
||||
correttamente `.exec()` (es. `init_wizard` a `window.py:144`, `settings_dialog`
|
||||
a `plugin.py:254`), che è modale e resta in primo piano.
|
||||
|
||||
**Fix proposto:**
|
||||
- Per i dialoghi che devono restare in primo piano: usare `exec()` (modale) **o**
|
||||
`show()` + parent corretto + `setWindowModality(Qt.WindowModal)` +
|
||||
`raise_()` + `activateWindow()`.
|
||||
- Mantenere la stessa logica di "cosa fa il dialogo" (nessun cambio di
|
||||
comportamento funzionale, solo z-order/modalità).
|
||||
|
||||
---
|
||||
|
||||
### B3 — "Please restart Electrum to activate the BAL plugin" 🔴
|
||||
**Dove:** `plugin.py:38-42` (hook `init_qt`).
|
||||
|
||||
```python
|
||||
if wallet:
|
||||
window.show_warning(_("Please restart Electrum to activate the BAL plugin"), ...)
|
||||
return
|
||||
```
|
||||
|
||||
**Causa:** quando il plugin viene **abilitato a caldo** (wallet già aperto),
|
||||
l'hook `init_qt` si arrende e chiede il riavvio invece di inizializzare le tab
|
||||
e i menu sul wallet già caricato. È **la causa diretta del sintomo S2**: "devi
|
||||
chiudere/riavviare Electrum perché funzioni".
|
||||
|
||||
**Fix proposto:**
|
||||
- In `init_qt`, se c'è già un wallet aperto, eseguire la stessa inizializzazione
|
||||
che normalmente avviene in `load_wallet` (creare `BalWindow`, tab, menu,
|
||||
caricare il will) **senza** richiedere il riavvio.
|
||||
- Simmetricamente, gestire bene `close_wallet` per smontare tab/menu, così
|
||||
ri-abilitare/ricaricare non lascia stato sporco.
|
||||
|
||||
---
|
||||
|
||||
### B4 — Chiave del dizionario `winId` (metodo) invece di `winId()` 🔴
|
||||
**Dove:** `plugin.py:45` (scrittura) e `plugin.py:111` (lettura).
|
||||
|
||||
```python
|
||||
self.bal_windows[top_level_window.winId] = w # scrive con la *funzione* winId
|
||||
...
|
||||
w = self.bal_windows.get(window.winId, None) # legge con la *funzione* winId
|
||||
```
|
||||
|
||||
**Causa:** `winId` senza parentesi è il **metodo legato** (bound method), non
|
||||
l'identificatore della finestra. Usato come chiave "funziona per caso" perché
|
||||
lo stesso oggetto-finestra produce lo stesso bound method; ma è fragile e
|
||||
semanticamente errato: con più finestre/wallet o dopo riaperture la
|
||||
corrispondenza può saltare, creando `BalWindow` duplicati o non trovando quello
|
||||
giusto → stato incoerente (contribuisce a S2).
|
||||
|
||||
**Fix proposto:**
|
||||
- Usare una chiave stabile e corretta, es. `int(window.winId())` oppure
|
||||
`id(window)`, in modo **coerente** sia in scrittura sia in lettura.
|
||||
|
||||
---
|
||||
|
||||
### B5 — `on_close` ingoia tutti gli errori 🟠
|
||||
**Dove:** `window.py:664-677`.
|
||||
|
||||
```python
|
||||
def on_close(self):
|
||||
try:
|
||||
if not self.disable_plugin:
|
||||
close_window = BalBuildWillDialog(self)
|
||||
close_window.build_will_task()
|
||||
self.save_willitems()
|
||||
self.heirs_tab.close()
|
||||
...
|
||||
except Exception:
|
||||
pass # <-- nasconde qualsiasi errore di cleanup
|
||||
```
|
||||
|
||||
**Causa:** se una qualsiasi di queste operazioni fallisce, l'eccezione viene
|
||||
silenziata: tab/menu non vengono rimossi, lo stato (`willitems`, `heirs`, tab)
|
||||
resta in memoria e "sporco" finché non si riavvia Electrum (S2).
|
||||
|
||||
**Fix proposto:**
|
||||
- Non silenziare: loggare l'errore con `_logger`.
|
||||
- Rendere il cleanup **robusto e idempotente** (ogni passo in un try/except
|
||||
separato con log), così un fallimento parziale non blocca gli altri passi.
|
||||
- Azzerare esplicitamente lo stato (`willitems={}`, riferimenti a tab/menu a
|
||||
`None`) a fine `on_close`.
|
||||
|
||||
---
|
||||
|
||||
### B6 — `BalBlockingWaitingDialog` blocca il thread della GUI 🟠
|
||||
**Dove:** `dialogs.py:445-462`.
|
||||
|
||||
```python
|
||||
self.show()
|
||||
# QCoreApplication.processEvents() # <-- commentato
|
||||
# QCoreApplication.processEvents()
|
||||
try:
|
||||
task() # esegue il task SUL thread GUI -> finestra "congelata"
|
||||
finally:
|
||||
self.accept()
|
||||
```
|
||||
|
||||
**Causa:** dopo `show()` non si dà alla GUI il tempo di disegnarsi
|
||||
(`processEvents` è commentato) e poi si esegue `task()` **bloccando** il thread
|
||||
dell'interfaccia. Risultato: la finestra "Please wait" può apparire vuota,
|
||||
non ridisegnarsi, e l'app sembra bloccata (contribuisce a S1/percezione di
|
||||
freeze).
|
||||
|
||||
**Fix proposto:**
|
||||
- O eseguire il task in un `TaskThread` (come fa già `BalWaitingDialog`),
|
||||
- oppure, se deve restare bloccante, ripristinare un `processEvents()` dopo
|
||||
`show()` per far disegnare la finestra prima del task.
|
||||
|
||||
---
|
||||
|
||||
### B7 — `closeEvent`/`hideEvent` con cleanup thread commentato 🟠
|
||||
**Dove:** `dialogs.py:48-58` (`BalDialog`).
|
||||
|
||||
```python
|
||||
def closeEvent(self, event):
|
||||
self._stopping = True
|
||||
#if self.thread:
|
||||
# self.thread.stop() # <-- disattivato
|
||||
super().closeEvent(event)
|
||||
```
|
||||
|
||||
**Causa:** alla chiusura del dialogo i thread eventualmente attivi **non**
|
||||
vengono fermati. Restano in esecuzione in background, possono scrivere su widget
|
||||
già distrutti o tenere risorse/connessioni → comportamenti erratici finché non
|
||||
si riavvia (S2).
|
||||
|
||||
**Fix proposto:**
|
||||
- Ripristinare in modo sicuro lo stop dei thread: `if self.thread:
|
||||
self.thread.stop(); self.thread.wait()` con guardia su `None`.
|
||||
|
||||
---
|
||||
|
||||
### B8 — `BalBuildWillDialog.closeEvent` incompleto 🟠
|
||||
**Dove:** `dialogs.py:828-830`.
|
||||
|
||||
```python
|
||||
def closeEvent(self, event):
|
||||
self._stopping = True
|
||||
self.thread.stop()
|
||||
# manca self.thread.wait() e manca super().closeEvent(event)
|
||||
```
|
||||
|
||||
**Causa:** `stop()` segnala lo stop ma non attende la fine del thread
|
||||
(`wait()`), e non viene chiamato `super().closeEvent(event)`: l'evento di
|
||||
chiusura non è propagato correttamente. Possibili thread orfani e finestre che
|
||||
non si chiudono pulite.
|
||||
|
||||
**Fix proposto:**
|
||||
- `self.thread.stop(); self.thread.wait(); super().closeEvent(event)` con
|
||||
guardia su `self.thread is None`.
|
||||
|
||||
---
|
||||
|
||||
### B9 — `show()+raise_()` senza `activateWindow()`/modalità 🟡
|
||||
**Dove:** `dialogs.py:1121-1122` (es. `WillExecutorDialog`/dettaglio).
|
||||
|
||||
```python
|
||||
self.show()
|
||||
self.raise_()
|
||||
# manca self.activateWindow(); nessuna modalità impostata
|
||||
```
|
||||
|
||||
**Causa:** `raise_()` alza la finestra nello stack ma su alcuni window manager
|
||||
(incluso Windows) senza `activateWindow()` non riceve il focus e può comunque
|
||||
finire dietro. Senza modalità, l'utente può tornare alla finestra principale
|
||||
lasciando il dialogo nascosto.
|
||||
|
||||
**Fix proposto:**
|
||||
- Aggiungere `self.activateWindow()` dopo `raise_()`, e valutare
|
||||
`setWindowModality(Qt.WindowModal)` dove ha senso.
|
||||
|
||||
---
|
||||
|
||||
### B10 — Gestione finestre multiple / multi-wallet fragile 🟡
|
||||
**Dove:** `plugin.py:30-62` (`init_qt`), `get_window` (`plugin.py:109-115`).
|
||||
|
||||
**Causa:** la mappa `bal_windows` e l'aggancio ai menu si basano su assunzioni
|
||||
(B4) e sull'iterazione dei figli del menubar per nome (`"&Tools"`), che è
|
||||
sensibile alla **localizzazione** (tu usi `Locale: Italian_Italy`!). Se il menu
|
||||
non si chiama esattamente `&Tools` nella lingua corrente, l'aggancio può
|
||||
fallire silenziosamente.
|
||||
|
||||
**Fix proposto:**
|
||||
- Usare l'API ufficiale `window.tools_menu` (già usata in `init_menubar`,
|
||||
`plugin.py:79`) invece di cercare il menu per titolo tradotto.
|
||||
- Unificare la creazione/lookup di `BalWindow` su una chiave stabile (B4).
|
||||
|
||||
---
|
||||
|
||||
## Strategia di correzione proposta (per la Fase B/C)
|
||||
|
||||
Per **non cambiare la logica di funzionamento** e ridurre i rischi, propongo di
|
||||
introdurre un **unico punto centralizzato** di gestione finestre (un piccolo
|
||||
helper, es. `gui/qt/window_utils.py`) con funzioni tipo:
|
||||
|
||||
- `show_modal(dialog)` → imposta parent corretto, modalità, `exec()`.
|
||||
- `show_on_top(dialog)` → `show()` + `raise_()` + `activateWindow()` per i
|
||||
pochi casi che devono restare non-modali.
|
||||
|
||||
E poi sostituire i `.show()`/`.exec()` sparsi con queste funzioni. Vantaggi:
|
||||
- la **logica di business resta intatta** (cosa fa il dialogo non cambia);
|
||||
- si tocca **solo** il "come" viene mostrato/chiuso;
|
||||
- più facile da testare e da revisionare (diff piccolo e localizzato).
|
||||
|
||||
### Ordine consigliato
|
||||
1. **B3 + B4** (init a caldo + chiave finestre): risolvono la radice di S2.
|
||||
2. **B1 + B2 + B9** (parent/modalità/z-order): risolvono S1.
|
||||
3. **B5 + B7 + B8** (cleanup robusto + thread): chiudono i residui di S2.
|
||||
4. **B6 + B10** (waiting dialog + menu localizzati): rifiniture.
|
||||
|
||||
---
|
||||
|
||||
## Cosa serve da te per la Fase B/C
|
||||
- Conferma che posso modificare il **comportamento della GUI** (parent,
|
||||
modalità, cleanup, init a caldo) mantenendo invariata la logica di business.
|
||||
- Test su **Electrum portable Windows** dopo ogni gruppo di fix, con descrizione
|
||||
/screenshot di cosa succede (apertura dialoghi, abilitazione a caldo,
|
||||
chiusura wallet).
|
||||
|
||||
> Nota: i bug B1–B10 esistono **identici nell'originale** — questo refactor li
|
||||
> ha preservati fedelmente (era l'obiettivo della fase precedente). La Fase B/C
|
||||
> li corregge.
|
||||
134
README.md
134
README.md
@@ -1 +1,133 @@
|
||||
clean slate
|
||||
# BAL — Bitcoin After Life (Electrum plugin)
|
||||
|
||||
Free and decentralized **Bitcoin inheritance** support for the
|
||||
[Electrum](https://electrum.org) wallet. Build time-locked "will" transactions
|
||||
that transfer your funds to your heirs if you stop refreshing them
|
||||
(dead-man's switch), optionally relayed by will-executor servers.
|
||||
|
||||
This repository contains a **behavior-preserving refactor** of the original
|
||||
plugin. The logic was kept byte-identical wherever possible; only the file
|
||||
layout was reorganized to cleanly separate **business logic** from the
|
||||
**PyQt GUI**.
|
||||
|
||||
## Repository layout
|
||||
|
||||
```
|
||||
bal/ the installable Electrum plugin package
|
||||
├── manifest.json plugin metadata (Electrum reads this)
|
||||
├── qt.py Qt entry-point shim (re-exports Plugin)
|
||||
├── core/ GUI-free logic (importable without Qt)
|
||||
│ ├── util.py
|
||||
│ ├── plugin_base.py
|
||||
│ ├── heirs.py
|
||||
│ ├── will.py
|
||||
│ └── willexecutors.py
|
||||
├── gui/qt/ PyQt6 presentation layer
|
||||
│ ├── theme.py status → color mapping
|
||||
│ ├── common.py shared imports / helpers
|
||||
│ ├── widgets.py leaf widgets
|
||||
│ ├── calendar.py calendar widget
|
||||
│ ├── dialogs.py dialog windows
|
||||
│ ├── lists.py tree/list views
|
||||
│ ├── window.py per-wallet GUI controller
|
||||
│ └── plugin.py Plugin (Electrum @hooks → GUI)
|
||||
├── icons/ wallet_util/ LICENSE VERSION README.md
|
||||
build_zip.py builds a clean, zipimport-friendly distribution zip
|
||||
tests/ smoke + external-zip regression tests
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Electrum 4.7.2** — the last stable release exposing `json_db.register_dict`,
|
||||
which this plugin relies on. Newer versions removed it.
|
||||
- **PyQt6** (bundled with the Electrum desktop GUI).
|
||||
|
||||
## Installation
|
||||
|
||||
### Build the distribution archive
|
||||
|
||||
```bash
|
||||
python3 build_zip.py
|
||||
# -> bal-electrum-plugin.zip (prints size + SHA-256 for integrity checks)
|
||||
```
|
||||
|
||||
The builder writes a `zipimport`-friendly archive (files only, standard
|
||||
DEFLATE, deterministic order) to avoid loader errors seen on some Electrum
|
||||
portable builds.
|
||||
|
||||
### Install as an external plugin (zip)
|
||||
|
||||
1. Electrum → **Tools → Plugins** → install from file → pick the built zip.
|
||||
2. Enable **Bitcoin After Life** and restart Electrum.
|
||||
3. (Recommended) verify the downloaded zip's SHA-256 matches the value printed
|
||||
by `build_zip.py`.
|
||||
|
||||
### Install as an internal plugin
|
||||
|
||||
Copy the `bal/` directory into your Electrum installation's
|
||||
`electrum/plugins/` directory, so that `electrum/plugins/bal/manifest.json`
|
||||
exists, then enable it from **Tools → Plugins**.
|
||||
|
||||
## Inheritance safety: anticipate / postpone
|
||||
|
||||
A will transaction is signed with a **fixed, immutable locktime** and then
|
||||
optionally sent to will-executor servers, which are economically incentivised
|
||||
to broadcast it (they collect fees). Because the locktime is baked into the
|
||||
signed transaction, simply changing the delivery time later is **not enough**:
|
||||
the old, already-signed transaction keeps living on the will-executors.
|
||||
|
||||
The plugin handles the two cases as follows (triggered when you press
|
||||
**Tools → Prepare**):
|
||||
|
||||
* **Anticipate** (new delivery time *earlier* than the signed locktime): the
|
||||
will is treated as expired and you are asked to **invalidate** the old
|
||||
transaction on-chain, then rebuild.
|
||||
* **Postpone** (new delivery time *later* than the signed locktime) on a will
|
||||
that was already **signed and/or pushed**: the previously committed coins
|
||||
must be invalidated on-chain **first**, otherwise a will-executor could
|
||||
broadcast the old (earlier-locktime) transaction and execute the inheritance
|
||||
*too early*. The plugin detects this by comparing the requested locktime with
|
||||
the locktime **frozen inside the signed transaction** (`tx.locktime`), and
|
||||
asks you to sign and broadcast an invalidation transaction. After it is
|
||||
broadcast, press **Prepare** again to rebuild, re-sign and re-send the new
|
||||
(postponed) inheritance. Postponing a will that was *never* signed/sent just
|
||||
rebuilds it (no on-chain fee).
|
||||
|
||||
## Transaction list: the "Server" column
|
||||
|
||||
The will transaction list shows a dedicated **Server** column so you always
|
||||
know whether each inheritance transaction is actually stored on the
|
||||
will-executor servers, independently of the row colour:
|
||||
|
||||
| Label | Meaning |
|
||||
| --- | --- |
|
||||
| `Confirmed on server` | the will-executor confirmed it stored the transaction |
|
||||
| `Sent (not checked)` | pushed to the will-executor, not yet re-checked |
|
||||
| `Send failed` / `Not on server` | push failed or the server no longer has it |
|
||||
| `Signed (not sent)` | signed locally, not sent to any will-executor |
|
||||
| `Not sent` | not signed/sent yet |
|
||||
|
||||
Hovering the cell shows a tooltip with the will-executor URL and the current
|
||||
state.
|
||||
|
||||
## Testing
|
||||
|
||||
```bash
|
||||
# imports + behavior
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 tests/smoke_test.py electrum.plugins.bal
|
||||
|
||||
# external-zip loading regression
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 tests/external_zip_test.py bal-electrum-plugin.zip
|
||||
```
|
||||
|
||||
## ⚠️ Safety
|
||||
|
||||
This plugin builds real Bitcoin inheritance transactions with time-locks. Test
|
||||
on **testnet** or a fund-less wallet first, and review the generated
|
||||
transactions before broadcasting.
|
||||
|
||||
## License
|
||||
|
||||
MIT — see [`bal/LICENSE`](bal/LICENSE).
|
||||
|
||||
253
REPORT_NETWORKING_PARALLELO.md
Normal file
253
REPORT_NETWORKING_PARALLELO.md
Normal file
@@ -0,0 +1,253 @@
|
||||
# Technical report — Parallel networking (Will-Executor anti-freeze) + UI feedback
|
||||
|
||||
**Audience:** external programmer / plugin maintainer
|
||||
**Author:** AI refactoring work (on GitHub `Bitcoin-after-life/test`)
|
||||
**Date:** 2026-06-15
|
||||
**Branch:** `feature/networking-parallelo` (Pull Request #4)
|
||||
**Private Gitea repo `kaibot/bal-plugin-ai`: NOT modified** (per explicit request; cloned read-only only to run the official tests).
|
||||
|
||||
---
|
||||
|
||||
## 1. Problem
|
||||
|
||||
When the plugin contacts the Will-Executor servers (pushing transactions,
|
||||
pinging/refreshing the inheritance, downloading the list, and **checking**
|
||||
transactions), it used to do it **sequentially**. If a server did not answer,
|
||||
the thread stayed blocked on the connection timeouts and, worse, on the
|
||||
**retries**:
|
||||
|
||||
- `send_request` retried up to **10 times** with `time.sleep(3)` on every
|
||||
timeout → roughly **~140 seconds per unreachable server**, summed one after
|
||||
another.
|
||||
|
||||
Consequences:
|
||||
- Noticeable already with a few servers; with **20 servers** it became
|
||||
unusable.
|
||||
- The user saw "Stay waiting — Not responding" with no idea what was happening.
|
||||
- A single dead server blocked the whole operation.
|
||||
|
||||
---
|
||||
|
||||
## 2. Solution (overview)
|
||||
|
||||
1. **Parallelism** with `ThreadPoolExecutor`: servers are contacted
|
||||
concurrently. Total time ≈ the **slowest** server, not the **sum**.
|
||||
2. **Fast-fail** for interactive operations (ping/info/download): no retry
|
||||
storm, a single short timeout and the server is marked "KO".
|
||||
3. **Aggressive timeouts + global deadline** for push/check: a short per-server
|
||||
retry budget is kept (a real transaction must survive a transient hiccup),
|
||||
but a wall-clock **global deadline** caps the whole batch so a dialog never
|
||||
freezes behind one unresponsive server.
|
||||
4. **Live feedback + reliable elapsed-time counter**: `on_each(...)` updates the
|
||||
dialog as results arrive, and `on_tick()` refreshes an elapsed-time counter
|
||||
(`Xs / DEADLINEs`) so the user always knows progress and the maximum wait.
|
||||
|
||||
### Why it is thread-safe
|
||||
`Network.send_http_on_proxy()` uses `asyncio.run_coroutine_threadsafe(coro,
|
||||
loop)` and then `coro.result()`: every call schedules its own coroutine on
|
||||
Electrum's shared asyncio loop and blocks **only its own worker thread**.
|
||||
Multiple concurrent calls are therefore safe → `ThreadPoolExecutor` gives true
|
||||
parallelism.
|
||||
|
||||
UI updates go through `BalWaitingDialog.update()` / the dialog's `pyqtSignal`,
|
||||
which marshals to the GUI thread automatically. Callbacks from worker threads
|
||||
can therefore update the dialog safely.
|
||||
|
||||
### Why the counter is driven from the calling thread (important)
|
||||
An earlier attempt refreshed the elapsed-time counter from a separate raw
|
||||
`threading.Thread` heartbeat that emitted the `pyqtSignal`. That proved
|
||||
**unreliable**: a `pyqtSignal` emitted from a raw (non-Qt) Python thread inside
|
||||
the wizard's `TaskThread` was not reliably marshalled and the dialog never
|
||||
repainted — the counter was invisible.
|
||||
|
||||
The fix: the parallel helpers accept an **`on_tick` callback that is invoked
|
||||
periodically from the CALLING thread** (the same thread that already drives
|
||||
`on_each` and successfully repaints). The helpers poll the futures in short
|
||||
slices (`concurrent.futures.wait(..., timeout=tick_interval)`) and call
|
||||
`on_tick()` between waits. No heartbeat thread is used anymore.
|
||||
|
||||
---
|
||||
|
||||
## 3. Modified files (all on GitHub `Bitcoin-after-life/test`, branch `feature/networking-parallelo`)
|
||||
|
||||
### 3.1 `bal/core/willexecutors.py`
|
||||
|
||||
**Networking constants** (module level, also exposed as `Willexecutors` class
|
||||
attributes for a single source of truth in the GUI):
|
||||
```python
|
||||
DEFAULT_TIMEOUT = 5 # interactive ops (ping/info/list)
|
||||
|
||||
PUSH_TIMEOUT = 8 # broadcast (pushtxs)
|
||||
PUSH_MAX_RETRIES = 2
|
||||
PUSH_RETRY_SLEEP = 1
|
||||
PUSH_GLOBAL_DEADLINE = 30 # wall-clock cap for the whole parallel push
|
||||
|
||||
CHECK_TIMEOUT = 8 # check (searchtx)
|
||||
CHECK_MAX_RETRIES = 1
|
||||
CHECK_RETRY_SLEEP = 1
|
||||
CHECK_GLOBAL_DEADLINE = 30 # wall-clock cap for the whole parallel check
|
||||
```
|
||||
Worst case per server is now ~26s (push) / ~17s (check) instead of ~140s, and
|
||||
the global deadline guarantees the dialog proceeds within 30s regardless.
|
||||
|
||||
**`send_request(...)`** — keyword-only retry controls:
|
||||
```python
|
||||
def send_request(method, url, data=None, *, timeout=10, handle_response=None,
|
||||
count_reply=0, max_retries=10, retry_sleep=3):
|
||||
```
|
||||
- Defaults unchanged → callers that need the historical behaviour are
|
||||
unaffected.
|
||||
- Interactive callers pass `max_retries=0` → fast-fail.
|
||||
|
||||
**`get_info_task(...)`** — fast-fail by default (`max_retries=0`); a
|
||||
timeout/empty response yields `status="KO"`.
|
||||
|
||||
**`check_transaction(...)`** — now accepts `timeout`/`max_retries`/`retry_sleep`
|
||||
(defaults from the `CHECK_*` constants) and forwards them to `send_request`,
|
||||
replacing the old ~140s default storm.
|
||||
|
||||
**NEW `ping_servers_parallel(willexecutors, *, on_each=None, max_workers=8,
|
||||
timeout=DEFAULT_TIMEOUT, on_tick=None, tick_interval=1.0)`**
|
||||
- `ThreadPoolExecutor`; polls futures in slices and calls `on_tick()` from the
|
||||
calling thread; mutates `willexecutors` in place; invokes
|
||||
`on_each(url, we, ok)` as results arrive; a worker exception never blocks the
|
||||
others (defensive try/except).
|
||||
|
||||
**NEW `push_transactions_parallel(willexecutors, *, on_each=None, max_workers=8,
|
||||
deadline=PUSH_GLOBAL_DEADLINE, on_timeout=None, on_tick=None,
|
||||
tick_interval=1.0)`**
|
||||
- Parallel push only to entries that have a `"txs"` key; each server keeps its
|
||||
short retry budget.
|
||||
- `on_each(url, we, ok, exc)` per server; `on_timeout(url, we)` for servers
|
||||
still pending when the global deadline elapses; `on_tick()` for the counter.
|
||||
- Manual pool (no `with`) so `shutdown(wait=False, cancel_futures=True)` does
|
||||
not block on a hung worker once the deadline is reached.
|
||||
- Returns `{url: (ok, exc)}` for the servers that answered in time.
|
||||
|
||||
**NEW `check_transactions_parallel(items, *, on_each=None, max_workers=8,
|
||||
deadline=CHECK_GLOBAL_DEADLINE, on_timeout=None, on_tick=None,
|
||||
tick_interval=1.0)`**
|
||||
- Same design as the push helper but for the **Check** (searchtx) operation.
|
||||
- `items` is an iterable of `(wid, url)` pairs; `_check_one` calls
|
||||
`check_transaction`.
|
||||
- `on_each(wid, url, result_or_None, exc)`, `on_timeout(wid, url)`, `on_tick()`.
|
||||
- Returns `{wid: (result_or_None, exc)}`.
|
||||
|
||||
### 3.2 `bal/gui/qt/window.py`
|
||||
|
||||
- **`ping_willexecutors_task(self, wes)`** rewritten on `ping_servers_parallel`
|
||||
with live feedback and a counter `Ping Will-Executors: 2/3 (3s / 30s)` driven
|
||||
by `on_tick` from the calling thread.
|
||||
- **`push_transactions_to_willexecutors(self, force=False)`** rewritten on
|
||||
`push_transactions_parallel`; `on_each` does thread-safe book-keeping + UI
|
||||
update; "already present" servers are verified afterwards (original check
|
||||
logic intact).
|
||||
- **`check_transactions_task(self, will)`** rewritten on
|
||||
`check_transactions_parallel`; shows `Checking transactions: 2/5 (4s / 30s)`,
|
||||
reusing the original `set_check_willexecutor(...)` per-item logic inside
|
||||
`on_each` (and `set_check_willexecutor(None)` on `on_timeout`).
|
||||
- **`fetch_will_executors_list(...)`** fast-fail download
|
||||
(`timeout=10, max_retries=1, retry_sleep=1`); the download dialog shows
|
||||
`Downloading will-executors list... (Xs / 45s)`.
|
||||
|
||||
### 3.3 `bal/gui/qt/dialogs.py`
|
||||
|
||||
- **`BalBuildWillDialog.loop_push`** (the "Building Will" wizard broadcast step)
|
||||
rewritten on `push_transactions_parallel` with the `on_tick` counter
|
||||
`Broadcasting 2/3 (5s / 30s)`. The previous raw heartbeat thread was removed.
|
||||
|
||||
### 3.4 `bal/gui/qt/plugin.py` — status-bar icon (restored)
|
||||
|
||||
`create_status_bar` re-adds the BAL `StatusBarButton` (bottom-right of the
|
||||
Electrum status bar). It shows that the plugin is installed and opens the plugin
|
||||
settings on click; it also de-duplicates the button per window. (Comments in
|
||||
English.)
|
||||
|
||||
### 3.5 `bal/gui/qt/lists.py` and `bal/gui/qt/widgets.py` — GUI usability
|
||||
|
||||
- **Tooltips** (hover) on the Will toolbar icons, all in English:
|
||||
Wizard (`Wizard - Build your will`), Delivery time (truck), Check Alive
|
||||
(siren), Calendar, Check (refresh).
|
||||
- **Toolbar order** changed to:
|
||||
`Wizard | Delivery time | Check Alive | Calendar | Check`; layout margins
|
||||
tightened so everything fits the Will window.
|
||||
|
||||
### 3.6 `bal/core/util.py` — BUGFIX (pre-existing regression)
|
||||
|
||||
In `get_value_amount` (line 324) `Util.in_output(...)` (returns `bool`) had been
|
||||
used instead of `Util.din_output(...)` (returns the tuple
|
||||
`(same_amount, same_address)`), causing:
|
||||
```
|
||||
TypeError: cannot unpack non-iterable bool object
|
||||
```
|
||||
**Fixed** by restoring `din_output`. Found by running the official Gitea tests
|
||||
(`tests/test_core_util.py::test_get_value_amount`).
|
||||
|
||||
---
|
||||
|
||||
## 4. Verification (ruff + official tests)
|
||||
|
||||
### 4.1 ruff (lint / PEP8)
|
||||
- `ruff check` on the new code: **no new issues** introduced. The `F403/F405/
|
||||
F401` warnings come from the original `from .common import *` pattern;
|
||||
per-file counts are identical between HEAD and the working tree.
|
||||
- The new parallel functions add **0 `E501`** (line-length) issues; in
|
||||
`window.py` the count actually decreased after the rewrite.
|
||||
- `ruff check tests/parallel_ping_test.py` → no new issues.
|
||||
|
||||
### 4.2 Official tests from the Gitea repo `kaibot/bal-plugin-ai/tests`
|
||||
Run against the refactored code (with all the networking + UI changes):
|
||||
|
||||
| Suite | Result |
|
||||
|-------|--------|
|
||||
| `test_core_*` + `test_gui_*` (pytest) | **182 passed** |
|
||||
| `smoke_test.py` | OK |
|
||||
| `external_zip_test.py` | OK |
|
||||
| `windows_overflow_test.py` | OK |
|
||||
| `gui_fixes_test.py` | OK |
|
||||
| `parallel_ping_test.py` (new) | OK — parallel ping/push/check ~`0.50s` for 8 servers (sequential would be ~`4.00s`); global deadline enforced; `on_tick` fired from the calling thread; static checks that the dialogs use the parallel helpers + the `Xs / Ns` counter |
|
||||
|
||||
Commands (as per README):
|
||||
```bash
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 -m pytest tests/ -q
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 tests/smoke_test.py electrum.plugins.bal
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 tests/external_zip_test.py bal-electrum-plugin.zip
|
||||
QT_QPA_PLATFORM=offscreen PYTHONPATH=<electrum-src> \
|
||||
python3 tests/parallel_ping_test.py bal
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Integration notes / risks
|
||||
|
||||
- **No change to the server protocol**: only the *how* (parallel) and the
|
||||
*when* (retries/deadline) of the calls changed, not the payloads.
|
||||
- **Push transactions**: per-server retries are intentionally kept so a real
|
||||
transaction is not lost to a transient hiccup; only ping/info/download use
|
||||
fast-fail. The global deadline marks unanswered servers as failed (`on_timeout`)
|
||||
so the user can retry later.
|
||||
- **`max_workers=8`** is conservative; with many servers (e.g. 20) it can be
|
||||
raised, but 8 workers already collapse the total time to the slowest server.
|
||||
- **Thread/UI**: all UI updates from workers go through `pyqtSignal`-based
|
||||
dialog updates; the periodic counter is driven by `on_tick` from the calling
|
||||
thread. Do **not** reintroduce a raw heartbeat thread emitting signals — it
|
||||
does not repaint reliably.
|
||||
- **Compatibility**: signatures are backward compatible (new parameters are
|
||||
keyword-only with defaults that preserve the old behaviour).
|
||||
|
||||
---
|
||||
|
||||
## 6. How to test
|
||||
|
||||
1. Install `bal-electrum-plugin.zip` (Tools → Plugins → install from file).
|
||||
Fully close and reopen Electrum to avoid the cached zip import.
|
||||
2. Configure several Will-Executors, including **at least one unreachable**.
|
||||
3. Run push / ping / Check: each dialog shows per-server status plus a counter
|
||||
`N/total (Xs / 30s)` and **no longer freezes** on the dead server — within
|
||||
the global deadline the operation reports the dead server and proceeds.
|
||||
|
||||
The SHA-256 of the zip is printed by `build_zip.py` at the end of the build
|
||||
(use it to verify integrity).
|
||||
73
build_zip.py
Normal file
73
build_zip.py
Normal file
@@ -0,0 +1,73 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Build a clean, zipimport-friendly distribution archive of the BAL plugin.
|
||||
|
||||
Electrum loads external plugins from a ``.zip`` using Python's ``zipimport``.
|
||||
``zipimport`` is picky about the archive layout, so this builder deliberately:
|
||||
|
||||
* writes **only files** (no explicit directory entries) — some Electrum
|
||||
portable builds choke on directory records inside the archive;
|
||||
* uses standard DEFLATE compression (well supported by ``zipimport``);
|
||||
* emits entries in a deterministic, sorted order so the archive is
|
||||
reproducible (stable SHA-256);
|
||||
* skips ``__pycache__`` directories and compiled ``*.pyc``/``*.pyo`` files.
|
||||
|
||||
The archive keeps the top-level ``bal/`` directory so that the package is
|
||||
importable as ``bal`` (and Electrum derives ``dirname='bal'`` from the path of
|
||||
``bal/manifest.json``).
|
||||
|
||||
Usage::
|
||||
|
||||
python3 build_zip.py [output.zip]
|
||||
|
||||
Prints the resulting size and SHA-256 so the download can be integrity-checked.
|
||||
"""
|
||||
|
||||
import hashlib
|
||||
import os
|
||||
import sys
|
||||
import zipfile
|
||||
|
||||
SRC_ROOT = "bal"
|
||||
DEFAULT_OUT = "bal-electrum-plugin.zip"
|
||||
|
||||
|
||||
def build(out_path: str) -> None:
|
||||
if os.path.exists(out_path):
|
||||
os.remove(out_path)
|
||||
|
||||
files = []
|
||||
for dirpath, dirnames, filenames in os.walk(SRC_ROOT):
|
||||
# prune cache dirs in place so os.walk does not descend into them
|
||||
dirnames[:] = [d for d in dirnames if d != "__pycache__"]
|
||||
for fn in filenames:
|
||||
if fn.endswith((".pyc", ".pyo")):
|
||||
continue
|
||||
files.append(os.path.join(dirpath, fn))
|
||||
files.sort()
|
||||
|
||||
with zipfile.ZipFile(
|
||||
out_path, "w", compression=zipfile.ZIP_DEFLATED, compresslevel=6
|
||||
) as z:
|
||||
for f in files:
|
||||
arc = f.replace(os.sep, "/") # forward slashes inside the archive
|
||||
z.write(f, arc)
|
||||
|
||||
# Integrity + summary
|
||||
with zipfile.ZipFile(out_path) as z:
|
||||
bad = z.testzip()
|
||||
if bad is not None:
|
||||
raise SystemExit(f"ERROR: corrupt entry in archive: {bad}")
|
||||
names = z.namelist()
|
||||
if not any(n.endswith("manifest.json") for n in names):
|
||||
raise SystemExit("ERROR: manifest.json missing from archive")
|
||||
|
||||
data = open(out_path, "rb").read()
|
||||
print(f"built : {out_path}")
|
||||
print(f"files : {len(files)}")
|
||||
print(f"size : {len(data)} bytes")
|
||||
print(f"sha256: {hashlib.sha256(data).hexdigest()}")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
out = sys.argv[1] if len(sys.argv) > 1 else DEFAULT_OUT
|
||||
build(out)
|
||||
10140
giovanna7
Executable file
10140
giovanna7
Executable file
File diff suppressed because one or more lines are too long
47
promptai
Normal file
47
promptai
Normal file
@@ -0,0 +1,47 @@
|
||||
traduci tutti i testi, commenti, docstring, e nomi variabile in inglese.
|
||||
scrivi sempre tutto il codice in inglese.
|
||||
scrivi sempre commenti e docstring su tutti i metodi e classi per spiegarne il funzionamento.
|
||||
|
||||
quando non sei sicuro non inventare, chiedi conferma tenendo pero' conto che non sono un programmatore.
|
||||
siccome ordinare block-height e timestamp e' impossibile, elimina block-height dalla codebase, considera solo i timestamp.
|
||||
|
||||
assicurati che i seguenti stati della transazione vengano assegnati correttamente:
|
||||
ANTICIPATED — La transazione è stata generata con un locktime anticipato di 1 giorno rispetto a una transazione pre-esistente con cui condivide gli stessi eredi. Rimane valida (VALID non viene pulito).
|
||||
REPLACED — La transazione è stata sostituita perché almeno uno dei suoi input viene speso da una nuova transazione con locktime inferiore. La vecchia tx perde lo status VALID e viene marcata REPLACED. Si propaga a cascata ai figli.
|
||||
INVALIDATED — La transazione non è più spendibile perché almeno uno dei suoi input è stato speso da una transazione in mempool o già confermata, e la tx precedente non esiste più nella will. Perde lo status VALID.
|
||||
UPDATED — la transazione e' spendibile e valida, ma una nuova transazione la rimpiazza mantenendo lo stesso locktime e gli stessi eredi
|
||||
MEMPOOL — la transazione e' stata vista nella mempool di electrum
|
||||
CONFIRMED — la transazione e' confermata nella blockchain
|
||||
|
||||
|
||||
aggiungi una opzione nella configurazione del plugin con una checkbox che chiede se firmare automaticamente le transazioni default: True
|
||||
ripristina che il pulsante check firmi le transazioni, e se e' impostata una password quando la chiede se si clicca su annulla, o se la nuova checkbox nelle impostazioni del plugin e' settata per non firmare automaticamente le transazioni deve saltare la fase della firma e come ora dire all'utente di firmare
|
||||
|
||||
modifica gli allarmi dell'evento nel calendario:
|
||||
aggiungi una opzione nelle impostazioni del plugin che chiede il numero di allarmi si vogliono impostare default 3
|
||||
quando si crea l'evento, si sceglie quale e' maggiore tra la data attuale ed il check-alive, si divide il tempo per il numero di allarmi piu' uno, e si impostano gli allarmi sulle prime divisioni.
|
||||
|
||||
crea dei test mock per testare le funzionalità:
|
||||
usa il wallet giovanna7 per prendere dati plausibili ed indirizzi bitcoin validi
|
||||
usa l'environment di electrum in ../electrum/env in sola lettura.
|
||||
|
||||
|
||||
scrivi test per verificare l'output dell'evento per il calendario.
|
||||
testa che l'evento abbia la data e l'ora del valore inferiore tra will-settings['locktime'] o della tx valida con locktime inferiore
|
||||
testa che gli allarmi vengano creati correttamente secondo lo standard ics compatibile con i vari calendari online
|
||||
|
||||
crea almeno 3 eredi con indirizzi, locktime, ed amount validi
|
||||
crea almeno 2 willexecutors con base amount ed indirizzi validi
|
||||
esegui una eredità e confronta gli ammontare degli eredi con gli output della transazione per verificare che siano corretti
|
||||
modifica l'indirizzo di un erede, aggiorna, e verifica che la nuova eredità sia anticipata di un giorno, abbia stato anticipated ed aggiornato l'output dell'erede.
|
||||
modifica l'ammontare di un erede, aggiorna, e verifica che la nuova eredita sia anticipata di un ulteriore giorno, abbia stato anticipated ed aggiornato l'output dell'erede.
|
||||
modifica la base_fee ad un willexecutor, aggiorna l'eredità, ed assicurati che la nuova eredità abbia lo stesso locktime di quella attuale e l'output per il willexecutor aggiornato con la nuova base_fee. la vecchia transazione deve avere lo stato UPDATED e conservare lo stato valido
|
||||
testa che tutti gli stati vengano assegnati correttamente secondo la loro descrizione
|
||||
|
||||
scrivi dei test per testare la connettività
|
||||
simula tutti i tipi di errori di rete e verifica che vengano gestiti correttamente in tutte le varie richieste ai willexecutors ed alla welist
|
||||
|
||||
scrivi test per testare i willexecutors e le loro risposte alle varie interrogazioni.
|
||||
usa il willexecutor di default we.bitcoin-after.life/bitcoin per eseguire le interrogazioni e verificare le risposte.
|
||||
usa la welist all'indirizzo https://welist.bitcoin-after.life/data/bitcoin
|
||||
|
||||
47
promptai.txt
Normal file
47
promptai.txt
Normal file
@@ -0,0 +1,47 @@
|
||||
traduci tutti i testi, commenti, docstring, e nomi variabile in inglese.
|
||||
scrivi sempre tutto il codice in inglese.
|
||||
scrivi sempre commenti e docstring su tutti i metodi e classi per spiegarne il funzionamento.
|
||||
|
||||
quando non sei sicuro non inventare, chiedi conferma tenendo pero' conto che non sono un programmatore.
|
||||
siccome ordinare block-height e timestamp e' impossibile, elimina block-height dalla codebase, considera solo i timestamp.
|
||||
|
||||
assicurati che i seguenti stati della transazione vengano assegnati correttamente:
|
||||
ANTICIPATED — La transazione è stata generata con un locktime anticipato di 1 giorno rispetto a una transazione pre-esistente con cui condivide gli stessi eredi. Rimane valida (VALID non viene pulito).
|
||||
REPLACED — La transazione è stata sostituita perché almeno uno dei suoi input viene speso da una nuova transazione con locktime inferiore. La vecchia tx perde lo status VALID e viene marcata REPLACED. Si propaga a cascata ai figli.
|
||||
INVALIDATED — La transazione non è più spendibile perché almeno uno dei suoi input è stato speso da una transazione in mempool o già confermata, e la tx precedente non esiste più nella will. Perde lo status VALID.
|
||||
UPDATED — la transazione e' spendibile e valida, ma una nuova transazione la rimpiazza mantenendo lo stesso locktime e gli stessi eredi
|
||||
MEMPOOL — la transazione e' stata vista nella mempool di electrum
|
||||
CONFIRMED — la transazione e' confermata nella blockchain
|
||||
|
||||
|
||||
aggiungi una opzione nella configurazione del plugin con una checkbox che chiede se firmare automaticamente le transazioni default: True
|
||||
ripristina che il pulsante check firmi le transazioni, e se e' impostata una password quando la chiede se si clicca su annulla, o se la nuova checkbox nelle impostazioni del plugin e' settata per non firmare automaticamente le transazioni deve saltare la fase della firma e come ora dire all'utente di firmare
|
||||
|
||||
modifica gli allarmi dell'evento nel calendario:
|
||||
aggiungi una opzione nelle impostazioni del plugin che chiede il numero di allarmi si vogliono impostare default 3
|
||||
quando si crea l'evento, si sceglie quale e' maggiore tra la data attuale ed il check-alive, si divide il tempo per il numero di allarmi piu' uno, e si impostano gli allarmi sulle prime divisioni.
|
||||
|
||||
crea dei test mock per testare le funzionalità:
|
||||
usa il wallet giovanna7 per prendere dati plausibili ed indirizzi bitcoin validi
|
||||
usa l'environment di electrum in ../electrum/env in sola lettura.
|
||||
|
||||
|
||||
scrivi test per verificare l'output dell'evento per il calendario.
|
||||
testa che l'evento abbia la data e l'ora del valore inferiore tra will-settings['locktime'] o della tx valida con locktime inferiore
|
||||
testa che gli allarmi vengano creati correttamente secondo lo standard ics compatibile con i vari calendari online
|
||||
|
||||
crea almeno 3 eredi con indirizzi, locktime, ed amount validi
|
||||
crea almeno 2 willexecutors con base amount ed indirizzi validi
|
||||
esegui una eredità e confronta gli ammontare degli eredi con gli output della transazione per verificare che siano corretti
|
||||
modifica l'indirizzo di un erede, aggiorna, e verifica che la nuova eredità sia anticipata di un giorno, abbia stato anticipated ed aggiornato l'output dell'erede.
|
||||
modifica l'ammontare di un erede, aggiorna, e verifica che la nuova eredita sia anticipata di un ulteriore giorno, abbia stato anticipated ed aggiornato l'output dell'erede.
|
||||
modifica la base_fee ad un willexecutor, aggiorna l'eredità, ed assicurati che la nuova eredità abbia lo stesso locktime di quella attuale e l'output per il willexecutor aggiornato con la nuova base_fee. la vecchia transazione deve avere lo stato UPDATED e conservare lo stato valido
|
||||
testa che tutti gli stati vengano assegnati correttamente secondo la loro descrizione
|
||||
|
||||
scrivi dei test per testare la connettività
|
||||
simula tutti i tipi di errori di rete e verifica che vengano gestiti correttamente in tutte le varie richieste ai willexecutors ed alla welist
|
||||
|
||||
scrivi test per testare i willexecutors e le loro risposte alle varie interrogazioni.
|
||||
usa il willexecutor di default we.bitcoin-after.life/bitcoin per eseguire le interrogazioni e verificare le risposte.
|
||||
usa la welist all'indirizzo https://welist.bitcoin-after.life/data/bitcoin
|
||||
|
||||
Reference in New Issue
Block a user