f7f9442156
**Motivations:** - Miner stopped producing blocks after bitcoind and mempool restart - PSBT signing failed with "PSBT signing failed" error - descriptorprocesspsbt failed with "Argument list too long" error due to large PSBT size (1.5MB) **Root causes:** - descriptorprocesspsbt called via command line exceeded argument length limit when PSBT is large - walletprocesspsbt succeeded but could not mark PSBT as complete because it cannot sign artificial signet transactions (to_spend/spend) which are not real UTXOs in wallet - After restart, the miner needed descriptorprocesspsbt to sign artificial signet transactions, but command line approach failed **Correctifs:** - Modified miner to use JSON-RPC HTTP API directly for descriptorprocesspsbt instead of command line - PSBT is now passed via HTTP request body, avoiding command line argument length limit - Added fallback to walletprocesspsbt if HTTP RPC fails - Updated mine.sh to use -rpcwallet and -datadir correctly for wallet operations **Evolutions:** - Miner now uses HTTP JSON-RPC for large PSBTs, making it more robust for signet mining with many transactions - Improved error handling with fallback mechanisms **Pages affectées:** - miner: Modified PSBT signing logic to use HTTP JSON-RPC for descriptorprocesspsbt - mine.sh: Updated to use -rpcwallet and -datadir correctly
39 lines
2.2 KiB
Markdown
39 lines
2.2 KiB
Markdown
# UserWallet – Notifications relais (pull-based)
|
||
|
||
**Author:** Équipe 4NK
|
||
**Date:** 2026-01-26
|
||
|
||
## Objectif
|
||
|
||
Exposer les « notifications » liées aux événements relais (collecte signatures, clés) pour que l’UI sache **quel hash** aller chercher et afficher la **progression** (ex. X/Y signatures). Modèle **pull-only** : pas de push/WebSocket, uniquement GET sur les relais.
|
||
|
||
## Implémenté
|
||
|
||
### 1. Collecte signatures (login mFA)
|
||
|
||
- **Hash connu** : le challenge login a un `hash` ; on fetch `GET /signatures/:hash` sur chaque relais.
|
||
- **Boucle de collecte** : `runCollectLoop` appelle `fetchSignaturesForHash` puis merge, jusqu’à `hasEnoughSignatures` ou timeout.
|
||
- **Progression** : `CollectLoopOpts.onProgress?: (merged) => void` appelé à chaque poll. L’UI peut afficher « Signatures collectées : X / Y » via `collectProgress(path, merged, pairToMembers)` → `{ satisfied, required }`.
|
||
- **LoginCollectShare** : reçoit `collectProgress` et affiche « Signatures collectées : X / Y » pendant la collecte.
|
||
|
||
### 2. Clés et messages (sync)
|
||
|
||
- **Scan keys** : `GET /keys?start=&end=` → liste de `MsgCle` avec `hash_message`. On en déduit les hashes à fetch.
|
||
- **Fetch par hash** : `GET /messages/:hash` pour chaque hash, puis ECDH decrypt. Pas de « notification » explicite : le sync fait scan → fetch → decrypt en une passe. Les stats (indéchiffrable, validé, non validé) sont remontées au `SyncScreen`.
|
||
|
||
### 3. Pairing (membre finaliser)
|
||
|
||
- Hash et fetch signatures par hash déjà utilisés dans `fetchSignaturesForHash` (pairingConfirm). Pas de progression affichée côté pairing.
|
||
|
||
## À faire (évolutif)
|
||
|
||
- **Événements relais** : si un jour le relais propose du push (ex. WebSocket), adapter l’UI pour réagir aux événements « nouveau message / nouvelles signatures / nouvelles clés » et déclencher fetch par hash en conséquence.
|
||
- **Optimisation** : utiliser éventuellement Bloom ou autre pour réduire les GET quand beaucoup de hashes.
|
||
|
||
## Références
|
||
|
||
- `features/userwallet-collecte-distante-2-devices.md`
|
||
- `features/userwallet-dh-systematique-scan-fetch.md`
|
||
- `userwallet/src/utils/collectSignatures.ts` (`runCollectLoop`, `CollectLoopOpts.onProgress`)
|
||
- `userwallet/src/utils/loginValidation.ts` (`collectProgress`)
|