ncantu f7f9442156 Fix Bitcoin miner PSBT signing after bitcoind restart

**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

2026-01-27 23:30:19 +01:00

2.2 KiB

Raw Blame History

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é

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)

2.2 KiB Raw Blame History Unescape Escape