**Motivations:**
- Réduire la consommation mémoire en paginant côté serveur au lieu de charger toutes les données
- Corriger les erreurs "Input not found or already spent" dans l'API d'ancrage
- Maintenir la synchronisation entre la base de données et l'état réel de Bitcoin
- Améliorer l'expérience utilisateur avec un suivi de progression pour la collecte de signatures
**Root causes:**
- Pagination effectuée côté client : le serveur retournait tous les UTXOs/hashes (68k+ UTXOs, 32k+ hashes) puis le frontend paginait en JavaScript
- Désynchronisation entre la DB et Bitcoin : UTXOs dépensés non mis à jour dans la base de données
- Détection d'erreur incomplète : ne couvrait pas tous les cas ("already spent", "input not found")
- Pas de vérification de disponibilité de l'UTXO juste avant utilisation dans une transaction
**Correctifs:**
- Implémentation de la pagination côté serveur pour `/api/utxo/list` et `/api/hash/list` avec paramètres `page` et `limit`
- Amélioration de la détection d'erreur pour inclure "already spent" et "input not found"
- Ajout d'une vérification de disponibilité de l'UTXO avant utilisation avec mécanisme de retry (max 3 tentatives)
- Mise à jour automatique de tous les UTXOs dépensés dans la base de données lors de chaque synchronisation
- Script de synchronisation périodique avec cron job toutes les heures
- Optimisation mémoire : utilisation de tables temporaires SQL au lieu de charger tous les UTXOs en mémoire
**Evolutions:**
- Pagination serveur avec métadonnées (total, totalPages, page, limit) pour les endpoints `/api/utxo/list` et `/api/hash/list`
- Adaptation du frontend pour utiliser la pagination serveur (compatibilité maintenue avec chargement jusqu'à 1000 éléments)
- Ajout de `onProgress` callback dans `runCollectLoop` pour notifier la progression de la collecte de signatures
- Nouvelle fonction `collectProgress` pour calculer la progression (satisfied vs required) pour les notifications/UI
- Refactoring de `hasEnoughSignatures` avec extraction de `pairsPerMemberFromSigs` pour réutilisabilité
**Pages affectées:**
- `api-anchorage/src/bitcoin-rpc.js` : Vérification disponibilité UTXO, amélioration détection erreur, paramètre retryCount
- `api-anchorage/src/routes/anchor.js` : Passage des nouveaux paramètres à createAnchorTransaction
- `signet-dashboard/src/server.js` : Pagination pour `/api/hash/list` et `/api/utxo/list`
- `signet-dashboard/src/bitcoin-rpc.js` : Mise à jour automatique de tous les UTXOs dépensés avec optimisation mémoire
- `signet-dashboard/public/hash-list.html` : Adaptation pour charger avec pagination serveur
- `signet-dashboard/public/utxo-list.html` : Adaptation pour utiliser la pagination serveur par catégorie
- `userwallet/src/utils/collectSignatures.ts` : Ajout interface CollectLoopOpts avec onProgress callback
- `userwallet/src/utils/loginValidation.ts` : Ajout fonction collectProgress, refactoring avec pairsPerMemberFromSigs
- `data/sync-utxos-spent-status.mjs` : Script de synchronisation périodique des UTXOs dépensés
- `data/sync-utxos-cron.sh` : Script wrapper pour cron job
- `features/pagination-serveur-base-donnees.md` : Documentation de la pagination serveur
- `features/synchronisation-automatique-utxos-depenses.md` : Documentation de la synchronisation automatique
- `fixKnowledge/api-anchorage-utxo-already-spent-error.md` : Documentation de la correction de l'erreur UTXO déjà dépensé
**Motivations:**
- Réduction drastique de la consommation mémoire lors des ancrages
- Élimination du chargement de 173k+ UTXOs à chaque requête
- Stabilisation de la mémoire système sous charge élevée (50+ ancrages/minute)
**Root causes:**
- api-anchorage chargeait tous les UTXOs (173k+) via listunspent RPC à chaque ancrage
- Filtrage et tri de 173k+ objets en mémoire pour sélectionner un seul UTXO
- Croissance mémoire de ~16 MB toutes les 12 secondes avec 50 ancrages/minute
- Saturation mémoire système en quelques minutes
**Correctifs:**
- Création du module database.js pour gérer la base de données SQLite partagée
- Remplacement de listunspent RPC par requête SQL directe avec LIMIT 1
- Sélection directe d'un UTXO depuis la DB au lieu de charger/filtrer 173k+ objets
- Marquage des UTXOs comme dépensés dans la DB après utilisation
- Fermeture propre de la base de données lors de l'arrêt
**Evolutions:**
- Utilisation de la base de données SQLite partagée avec signet-dashboard
- Réduction mémoire de 99.999% (173k+ objets → 1 objet par requête)
- Amélioration des performances (requête SQL indexée vs filtrage en mémoire)
- Optimisation mémoire de signet-dashboard (chargement UTXOs seulement si nécessaire)
- Monitoring de lockedUtxos dans api-anchorage pour détecter les fuites
- Nettoyage des intervalles frontend pour éviter les fuites mémoire
**Pages affectées:**
- api-anchorage/src/database.js (nouveau)
- api-anchorage/src/bitcoin-rpc.js
- api-anchorage/src/server.js
- api-anchorage/package.json
- signet-dashboard/src/bitcoin-rpc.js
- signet-dashboard/public/app.js
- features/optimisation-memoire-applications.md (nouveau)
- features/api-anchorage-optimisation-base-donnees.md (nouveau)
**Motivations:**
- Ensure all application directories have systemd services enabled at boot
- Complete service installation for api-relay, filigrane-api, and clamav-api
- Fix dependencies and import issues preventing clamav-api from starting
**Root causes:**
- Three services (api-relay, filigrane-api, clamav-api) had service files but were not installed in systemd
- api-clamav had incorrect node-clamav version (0.12.1) that doesn't exist
- api-clamav dependencies were not installed (node_modules missing)
- ES module import syntax incompatible with CommonJS node-clamav package
**Correctifs:**
- Installed api-relay.service, filigrane-api.service, and clamav-api.service in /etc/systemd/system/
- Enabled all three services for automatic startup at boot
- Updated api-clamav/package.json: changed node-clamav version from ^0.12.1 to ^1.0.11
- Installed npm dependencies for api-clamav
- Fixed ES module import in api-clamav/src/routes/scan.js to use CommonJS-compatible syntax
**Evolutions:**
- All 7 application services now have systemd services enabled at boot
- Complete service coverage: anchorage-api, faucet-api, signet-dashboard, userwallet, api-relay, filigrane-api, clamav-api
- All services verified active and listening on their respective ports
**Pages affectées:**
- api-clamav/package.json
- api-clamav/src/routes/scan.js
- api-clamav/node_modules/ (new)
- api-clamav/package-lock.json (new)
- /etc/systemd/system/api-relay.service (new)
- /etc/systemd/system/filigrane-api.service (new)
- /etc/systemd/system/clamav-api.service (new)
**Motivations:**
- Ajouter dates manquantes dans hash_list.txt et compléter historique
- Compléter blockTime manquants dans utxo_list.txt et compléter historique
- Récupérer frais depuis transactions d'ancrage (OP_RETURN) et les stocker
- Bouton UI pour déclencher récupération frais
- Diagnostic Bloc Rewards (pourquoi ~4700 BTC au lieu de 50 BTC)
**Root causes:**
- hash_list.txt sans date (format ancien)
- utxo_list.txt blockTime souvent vide
- Frais absents du fichier (métadonnées OP_RETURN non stockées)
- Pas de moyen de récupérer/compléter frais depuis UI
**Correctifs:**
- hash_list.txt : format étendu avec date (rétrocompatible)
- utxo_list.txt : blockTime complété automatiquement lors écritures
- fees_list.txt : nouveau fichier pour stocker frais
- updateFeesFromAnchors() : récupère frais depuis OP_RETURN ancrages
- Endpoint /api/utxo/fees/update pour déclencher récupération
- Bouton "Récupérer les frais depuis les ancrages" dans section Frais (spinner)
- Scripts batch : complete-hash-list-dates.js, complete-utxo-list-blocktime.js
- Script diagnostic : diagnose-bloc-rewards.js (subsidy, coinbase, listunspent)
**Evolutions:**
- Frais chargés depuis fees_list.txt dans getUtxoList
- Complétion automatique dates/blockTime lors écritures futures
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js
- signet-dashboard/src/server.js
- signet-dashboard/public/utxo-list.html
- scripts/complete-hash-list-dates.js
- scripts/complete-utxo-list-blocktime.js
- scripts/diagnose-bloc-rewards.js
- features/utxo-list-fees-update-and-historical-completion.md
**Motivations:**
- Le cache UTXO existant a l'ancien format (seulement la date)
- Le code ne gérait pas correctement l'ancien format
- Nécessité de gérer la transition entre ancien et nouveau format
**Root causes:**
- Le cache UTXO avait l'ancien format <date> au lieu de <date>;<hauteur>
- Le code lisait parts[1] qui était undefined pour l'ancien format
- Cela causait une détection permanente de nouveaux blocs
**Correctifs:**
- Amélioration du code de lecture pour gérer l'ancien format (1 partie) et le nouveau format (2 parties)
- Détection automatique de l'ancien format et mise à jour forcée pour réécrire avec le bon format
- Validation de la hauteur pour éviter les valeurs invalides
**Evolutions:**
- Compatibilité avec l'ancien format du cache
- Migration automatique vers le nouveau format lors de la prochaine mise à jour
- Meilleure robustesse du code de lecture du cache
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js : Méthode getUtxoList()
**Motivations:**
- Le cache UTXO n'avait pas le format attendu (seulement la date)
- Le serveur détectait toujours de nouveaux blocs et faisait une mise à jour complète à chaque fois
- Le serveur était bloqué par le traitement de la liste UTXO
**Root causes:**
- Le cache UTXO était écrit avec seulement la date au lieu du format <date>;<hauteur>
- Le code de lecture attendait le format <date>;<hauteur> mais ne le trouvait pas
- Cela causait une détection permanente de nouveaux blocs et une mise à jour complète
**Correctifs:**
- Correction du format d'écriture du cache UTXO pour inclure la hauteur du bloc
- Format: <date>;<hauteur> au lieu de seulement <date>
**Evolutions:**
- Le cache UTXO fonctionne correctement maintenant
- Le serveur ne fait plus de mise à jour complète inutile
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js : Méthode getUtxoList()
**Motivations:**
- Le chargement et l'actualisation de la home est très long
- Réduire les appels RPC Bitcoin pour améliorer les performances
- Utiliser les fichiers texte comme source principale de données
**Root causes:**
- Les méthodes getAnchorCount(), getHashList() et getUtxoList() faisaient des appels RPC à chaque chargement
- Les fichiers texte hash_list.txt et utxo_list.txt n'étaient pas utilisés efficacement
**Correctifs:**
- getAnchorCount() : Lit directement depuis hash_list.txt au lieu de faire des appels RPC pour compter
- getHashList() : Lit directement depuis hash_list.txt et ne complète que les nouveaux blocs si nécessaire
- getUtxoList() : Lit depuis utxo_list.txt et ne fait l'appel RPC listunspent que si de nouveaux blocs sont détectés
- Mise à jour des confirmations sans appels RPC supplémentaires
**Evolutions:**
- Performance améliorée : les appels RPC sont limités aux cas où de nouveaux blocs sont détectés
- Utilisation efficace des fichiers texte comme source de vérité
- Réduction significative du temps de chargement de la home
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js : Méthodes getAnchorCount(), getHashList(), getUtxoList()
**Motivations:**
- Le chargement des UTXOs est très long car il recalcule tout à chaque fois
- Chaque UTXO nécessite plusieurs appels RPC (getrawtransaction, gettxout, getTransaction)
- Avec des milliers d'UTXOs, cela prend beaucoup de temps
**Root causes:**
- Le code ne lit jamais le fichier utxo_list.txt pour éviter de recalculer
- Tous les UTXOs sont recalculés à chaque appel, même s'ils n'ont pas changé
- Le fichier de cache utxo_list_cache.txt n'est utilisé que pour stocker une date, pas pour éviter les recalculs
**Correctifs:**
- Chargement des UTXOs existants depuis utxo_list.txt au démarrage
- Comparaison avec les UTXOs actuels de listunspent pour identifier les nouveaux/modifiés
- Recalcul uniquement des UTXOs nouveaux ou modifiés
- Mise à jour des informations dynamiques (isSpentOnchain, isLockedInMutex, confirmations) en parallèle
- Conservation des UTXOs dépensés dans le fichier pour l'historique (mais exclus des listes actives)
**Evolutions:**
- Utilisation du fichier texte utxo_list.txt comme cache (comme getHashList() utilise hash_list.txt)
- Format du fichier étendu : category;txid;vout;address;amount;confirmations;isAnchorChange
- Vérifications en parallèle pour les UTXOs existants (Promise.all)
- Logs indiquant le nombre d'UTXOs chargés depuis le fichier vs recalculés
- Les UTXOs dépensés sont conservés dans le fichier mais exclus des listes actives
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js: Méthode getUtxoList() optimisée pour utiliser le fichier texte comme cache
**Motivations:**
- Afficher le nombre d'UTXOs et le montant total concernés par la consolidation
- Rendre le bouton de consolidation plus informatif
**Root causes:**
- Le bouton affichait un texte statique sans information sur ce qui sera consolidé
- Pas de visibilité sur le nombre d'UTXOs et le montant concernés
**Correctifs:**
- Création de la méthode getSmallUtxosInfo() pour obtenir les infos sans consolider
- Ajout de la route GET /api/utxo/small-info pour exposer ces informations
**Evolutions:**
- Bouton de consolidation avec texte dynamique : "Consolider la capacité d'ancrage résiduelle (X UTXOs, Y ✅)"
- Fonction loadSmallUtxosInfo() qui charge les infos depuis l'API
- Bouton désactivé avec message "Aucun UTXO à consolider" si aucun UTXO disponible
- Chargement automatique des infos au chargement de la page et après refresh
- Gestion d'erreur avec message "Erreur de chargement" si l'API échoue
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js: Méthode getSmallUtxosInfo() pour obtenir les infos des petits UTXOs
- signet-dashboard/src/server.js: Route GET /api/utxo/small-info
- signet-dashboard/public/utxo-list.html: Fonction loadSmallUtxosInfo() et mise à jour du bouton avec texte dynamique
**Motivations:**
- Améliorer l'affichage de la liste des UTXOs avec pagination et tri
- Permettre la consolidation des petits UTXOs (< 2500 sats) pour optimiser le wallet
- Afficher le nombre d'UTXOs confirmés disponibles pour l'ancrage
**Root causes:**
- La liste des UTXOs pouvait être très longue et difficile à naviguer
- Les petits UTXOs (< 2500 sats) s'accumulaient sans possibilité de consolidation
- Le nombre d'UTXOs confirmés n'était pas affiché séparément
**Correctifs:**
- Filtrage des UTXOs confirmés (minconf=1) dans getUtxoList() pour éviter les erreurs too-long-mempool-chain
- Ajout du compteur confirmedAvailableForAnchor dans la réponse API
- Création de la méthode consolidateSmallUtxos() pour consolider les UTXOs < 2500 sats
- Ajout de la route POST /api/utxo/consolidate pour déclencher la consolidation
**Evolutions:**
- Pagination des résultats par 100 UTXOs par page avec contrôles précédent/suivant
- Tri des montants et confirmations avec flèches (croissant/décroissant) au clic sur les en-têtes
- Affichage du nombre d'UTXOs confirmés dans la section "Capacité d'ancrage restante"
- Bouton "Consolider les UTXOs < 2500 sats" pour optimiser le wallet
- Pagination également appliquée à la table des frais
**Pages affectées:**
- signet-dashboard/src/bitcoin-rpc.js: Filtrage UTXOs confirmés, méthode consolidateSmallUtxos()
- signet-dashboard/src/server.js: Route /api/utxo/consolidate, ajout confirmedAvailableForAnchor dans counts
- signet-dashboard/public/utxo-list.html: Pagination, tri, bouton consolidation, affichage UTXOs confirmés
**Motivations:**
- Fix insufficient UTXO amount error in anchor API
- Ensure continuous availability of usable UTXOs for anchor transactions
- Improve anchor transaction reliability and efficiency
**Root causes:**
- UTXO selection logic was too restrictive, rejecting UTXOs larger than needed
- No automatic provisioning of new usable UTXOs when existing ones were not suitable
- Algorithm prevented efficient use of available UTXOs
**Correctifs:**
- Refactored createAnchorTransaction() to provision 7 UTXOs of 2500 sats on each anchor
- Use single large UTXO to create 1 anchor output + 7 provisioning outputs + change
- Simplified UTXO selection: single large UTXO per transaction instead of multiple small ones
- Added UTXO provisioning logic in signet-dashboard
- Enhanced Bitcoin RPC methods in both api-anchorage and signet-dashboard
- Added documentation in fixKnowledge/api-anchorage-utxo-provisioning.md
**Evolutions:**
- Enhanced signet-dashboard with new pages (hash-list, utxo-list, join-signet, api-docs)
- Improved Bitcoin RPC client with better error handling and UTXO management
- Added cache files for hash and UTXO lists
- Updated api-faucet with improved server configuration
- Enhanced anchor count tracking
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js: Complete refactor of createAnchorTransaction()
- api-anchorage/src/routes/anchor.js: Enhanced anchor route
- api-anchorage/src/server.js: Server configuration updates
- signet-dashboard/src/bitcoin-rpc.js: Added comprehensive Bitcoin RPC client
- signet-dashboard/src/server.js: Enhanced server with new routes
- signet-dashboard/public/: Added new HTML pages and updated app.js
- api-faucet/src/server.js: Server improvements
- api-faucet/README.md: Documentation updates
- fixKnowledge/api-anchorage-utxo-provisioning.md: New documentation
- anchor_count.txt, hash_list.txt, utxo_list.txt: Tracking files
