**Motivations:**
- Docker services (bitcoind and mempool) were not starting automatically after reboot
- Mempool API was unhealthy because it tried to connect to bitcoind before it was ready
- No restart policy for bitcoind container
- Restart script started mempool before bitcoind, causing connection errors
**Root causes:**
- Bitcoind container had no restart policy (restart: no)
- Restart script started mempool before bitcoind
- No wait for bitcoind RPC to be ready before starting mempool
- No boot startup script for Docker services
**Correctifs:**
- Configured restart policy for bitcoind container: docker update --restart=always
- Improved restart-services-cron.sh:
- Start/restart bitcoind BEFORE mempool
- Wait for bitcoind RPC to be ready (max 60s) before starting mempool
- Detect if container is stopped (start) or running (restart)
- Use 'docker compose up -d' for mempool instead of 'restart'
- Created start-docker-services.sh:
- Start bitcoind first
- Wait for bitcoind RPC to be ready (max 120s at boot)
- Start mempool after bitcoind
- Logging to data/start-docker-services.log
- Created docker-services.service:
- Systemd service to start Docker services at boot
- Runs after docker.service and network.target
- Executes start-docker-services.sh
**Evolutions:**
- Automatic startup at boot: Docker services start automatically after reboot
- Guaranteed startup order: Bitcoind always starts before mempool
- Availability check: Wait for bitcoind to be ready before starting mempool
- Restart policy: Bitcoind container restarts automatically if stopped
- Better observability: Detailed logs for diagnosis
**Pages affectées:**
- data/restart-services-cron.sh: Improved startup order and availability checks
- data/start-docker-services.sh: New boot startup script
- data/docker-services.service: New systemd service for automatic startup
- fixKnowledge/docker-services-boot-startup.md: Documentation of improvements
**Motivations:**
- Anchor API requests were being aborted with 'This operation was aborted' error
- API anchorage had performance issues causing long response times (30-60s)
- Mutex could block indefinitely if a previous request crashed or timed out
**Root causes:**
- No timeout on mutex acquisition, causing indefinite blocking
- Sequential RPC calls (8+ getNewAddress calls) instead of parallel
- Expensive fee calculation making N RPC calls (one per input) instead of using known UTXO amounts
- RPC timeout too short (30s) for slow Bitcoin node operations
- No guarantee of mutex release in error cases
**Correctifs:**
- Added 180s timeout on mutex acquisition with Promise.race() to prevent indefinite blocking
- Parallelized getNewAddress() calls with Promise.all() (9 sequential calls → 1 parallel call)
- Optimized fee calculation to use known UTXO amounts instead of getRawTransaction() per input (saves N RPC calls, up to 20+)
- Increased RPC timeout from 30s to 120s in .env.example
- Added finally block to guarantee mutex release in all cases (success, error, timeout)
- Added timeout and explicit error handling in api-filigrane callAnchorAPI() with AbortController (120s timeout)
**Evolutions:**
- Performance improvement: execution time reduced from ~30-60s to ~10-20s
- RPC calls reduction: from ~15-35 calls to ~8-12 calls per anchor transaction
- Better resilience: mutex cannot block indefinitely anymore
- Improved error messages with explicit timeout/abort information
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js: mutex timeout, parallel address generation, optimized fee calculation, finally block
- api-anchorage/.env.example: increased RPC timeout to 120s
- api-filigrane/src/routes/watermark.js: timeout and error handling for anchor API calls
- fixKnowledge/api-filigrane-anchor-request-aborted.md: documentation of issues and fixes
**Motivations:**
- Anchor API requests were timing out with "This operation was aborted" errors
- Multiple simultaneous anchor requests can wait for mutex, causing delays
- Slow Bitcoin RPC calls can exceed the 120s timeout
**Root causes:**
- Timeout of 120s was too short when multiple anchors are in progress (mutex wait)
- Slow Bitcoin RPC operations (listunspent, createrawtransaction, sign, send) can take longer than 120s
- Insufficient logging made it difficult to diagnose timeout vs connection closure
**Correctifs:**
- Increased ANCHOR_API_TIMEOUT_MS from 120000 (120s) to 180000 (180s) to handle mutex waits and slow RPC calls
- Added start time tracking to measure elapsed time for all operations
- Enhanced logging with:
- Log at request start with url, documentUid, hash (truncated), timeoutMs
- Log on success with txid and elapsedMs
- Log on abort with elapsedMs, timeoutMs, errorName, errorCode
- Log on failure with elapsedMs, errorName, errorCode
- Improved error message to include elapsed time: "timeout or connection closed after Xs"
- Added timeout-specific log when timeout is reached (before abort)
**Evolutions:**
- Better observability with elapsed time in all logs
- More detailed error information (errorName, errorCode) for diagnosis
- Timeout log helps distinguish timeout from early connection closure
**Pages affectées:**
- api-filigrane/src/routes/watermark.js: Increased timeout, added timing and enhanced logging
- fixKnowledge/api-filigrane-anchor-request-aborted.md: Updated documentation with new timeout (180s), improved logging details, and mutex wait explanation
**Motivations:**
- Avoid unnecessary re-anchoring of already anchored hashes
- Improve performance by using database as source of truth
- Return consistent information without additional RPC calls
**Evolutions:**
- Added optional skipIfExists parameter to /api/anchor/document endpoint
- Check database for existing anchors before creating new transaction
- Automatically store anchors in database after transaction creation
- Return old: true/false flag and ok: true in all responses
- Enrich anchors table with all necessary information for retrieval without RPC calls
**Pages affectées:**
- api-anchorage/src/routes/anchor.js: Added skipIfExists parameter and database check
- api-anchorage/src/bitcoin-rpc.js: Store anchor in database after transaction creation
- api-anchorage/README.md: Updated documentation with new parameter and response format
- features/api-anchorage-skip-if-exists.md: Evolution documentation
**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
**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:**
- Finaliser l'implémentation du pairing avec mots uniquement
- Mettre à jour la documentation du pairing connecté
**Root causes:**
- N/A (évolution fonctionnelle)
**Correctifs:**
- N/A
**Evolutions:**
- Finalisation du pairing avec mots uniquement
- Mise à jour de la documentation
**Pages affectées:**
- features/userwallet-pairing-words-only-finalise.md
- userwallet/features/userwallet-pairing-connecte.md
**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:**
- L'API d'ancrage échoue avec l'erreur "connect EADDRNOTAVAIL ::1:38332" lors des tentatives de connexion au nœud Bitcoin
- Les ancrages de documents ne peuvent pas être créés sans connexion RPC réussie
- Le problème persiste malgré l'utilisation de 127.0.0.1 dans la configuration
**Root causes:**
- Node.js peut préférer IPv6 lors de la résolution DNS, même si 127.0.0.1 est utilisé directement
- La bibliothèque bitcoin-core peut effectuer des résolutions DNS internes qui aboutissent à IPv6
- Le système peut avoir une préférence IPv6 qui influence la résolution DNS de Node.js
**Correctifs:**
- Ajout de dns.setDefaultResultOrder('ipv4first') au début de bitcoin-rpc.js pour forcer Node.js à préférer IPv4 lors de la résolution DNS
- Cette configuration garantit que même si le système préfère IPv6, Node.js essaiera IPv4 en premier
**Evolutions:**
- Configuration DNS Node.js pour forcer IPv4 en priorité
- Documentation mise à jour avec la nouvelle correction
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js : Ajout de la configuration DNS IPv4
- fixKnowledge/anchor-api-ipv6-connection-error.md : Documentation de la correction supplémentaire
**Motivations:**
- Renommer les boutons pour une meilleure clarté et cohérence
- "Actualiser (fichier)" → "Actualisation Rapide"
- "Charger depuis RPC (statuts complets)" → "Actualisation détaillée"
**Correctifs:**
- Modification des textes des boutons
- Ajout d'IDs uniques (refresh-fast-button, refresh-detailed-button) pour une meilleure gestion
- Remplacement de la vérification par texte (includes('fichier')) par une vérification par ID
**Pages affectées:**
- signet-dashboard/public/utxo-list.html
**Motivations:**
- Supprimer le message "Source : fichier utxo_list.txt (peut ne pas être à jour). Dernière modif. : ..." de la page UTXO list
**Correctifs:**
- Suppression de l'élément HTML avec id="source-note"
- Suppression du code JavaScript qui mettait à jour ce message
- Suppression du style CSS .source-note non utilisé
**Pages affectées:**
- signet-dashboard/public/utxo-list.html
**Motivations:**
- Supprimer la colonne "Numéro de bloc" dans la section Ancrages (toujours vide)
- Afficher le bouton de mise à jour des frais même quand la section est vide
- Permettre de charger les statuts et dates complets depuis RPC
**Root causes:**
- La colonne "Numéro de bloc" affichait toujours "-" car blockHeight n'est pas dans le fichier utxo_list.txt
- Le bouton de mise à jour des frais n'était visible que si des frais existaient déjà
- Les statuts (isSpentOnchain, isLockedInMutex) et certaines dates ne sont pas dans le fichier, nécessitent un chargement RPC
**Correctifs:**
- Suppression de la colonne "Numéro de bloc" dans la section Ancrages (header et données)
- Ajout du bouton "Récupérer les frais depuis les ancrages" même quand fees.length === 0
- Ajout d'un bouton "Charger depuis RPC (statuts complets)" pour obtenir les données complètes
- Ajout de la fonction loadUtxoListFromRPC() qui charge depuis /api/utxo/list au lieu de /api/utxo/list.txt
**Evolutions:**
- Nouvelle option de chargement depuis RPC pour obtenir les statuts complets (Dépensé onchain, Verrouillé, Disponible)
- Les dates complètes sont disponibles via le chargement RPC même si blockTime manque dans le fichier
**Pages affectées:**
- signet-dashboard/public/utxo-list.html
**Motivations:**
- Comprendre pourquoi Bloc Rewards affichent ~4700 BTC au lieu de 50 BTC
**Root causes:**
- Signet custom initialisé avec version modifiée Bitcoin Core (fork Easepay)
- Chain params différents avec subsidy de base ~4700 BTC au lieu de 50 BTC
- Le miner utilise coinbasevalue fourni par getblocktemplate (pas de modification)
**Correctifs:**
- Aucun (comportement attendu pour ce signet custom)
- Documenter la subsidy réelle du signet
**Evolutions:**
- Aucune
**Pages affectées:**
- fixKnowledge/signet-custom-subsidy-analysis.md
**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:**
- Afficher 50 🛡 comme récompense de bloc de base (protocole Bitcoin 4 premières années)
- Montants actuels (4700, 4250, etc.) incluent les frais de transaction
**Root causes:**
- Fichier stocke montant total UTXO coinbase (récompense + frais)
- Affichage montrait le montant total au lieu de la récompense de base
**Correctifs:**
- Bloc Rewards : afficher 50 🛡 comme récompense de base
- Si montant réel différent (frais), afficher aussi en plus petit : "50 🛡 (4700 🛡 avec frais)"
**Evolutions:**
- Aucune
**Pages affectées:**
- signet-dashboard/public/utxo-list.html
**Motivations:**
- Changes : supprimer colonne Type et Date (toujours vide en chargement fichier)
- Frais Nombre : 0 : clarifier que c'est attendu en chargement fichier (source RPC)
**Root causes:**
- Type/Date inutiles ou vides pour Changes depuis utxo_list.txt
- Frais non stockés dans le fichier (OP_RETURN / RPC uniquement)
**Correctifs:**
- Changes : en-têtes et cellules Type + Date supprimés
- Frais vide : message "Les frais ne sont pas disponibles en chargement fichier (source RPC uniquement)." si utxosFromFile
- Doc features/utxo-list-progressive-loading.md mise à jour
**Evolutions:**
- Aucune
**Pages affectées:**
- signet-dashboard/public/utxo-list.html
- features/utxo-list-progressive-loading.md
**Motivations:**
- Page utxo-list très longue à charger
- Utiliser le fichier utxo_list.txt (peut ne pas être à jour) au lieu de /api/utxo/list
- Proposer un chargement progressif avec barre de progression
**Root causes:**
- /api/utxo/list appelle getUtxoList (RPC + fichier), lent et peut bloquer
- Aucun retour visuel pendant le chargement
**Correctifs:**
- Chargement depuis /api/utxo/list.txt (fichier uniquement)
- Stream du fichier (getReader + TextDecoder), parsing ligne à ligne
- Barre de progression (bytes reçus / Content-Length)
- Content-Length et Last-Modified sur /api/utxo/list.txt
- Statut "—" quand source fichier (pas d'info dépensé/verrouillé)
- Note "Source : fichier utxo_list.txt (peut ne pas être à jour)"
**Evolutions:**
- Chargement plus rapide et non bloquant
- Feedback visuel (progression, lignes parsées)
- Documentation dans features/utxo-list-progressive-loading.md
**Pages affectées:**
- signet-dashboard/src/server.js
- signet-dashboard/public/utxo-list.html
- features/utxo-list-progressive-loading.md
**Motivations:**
- La liste des hash est très longue (17k+ hash) et difficile à naviguer
- Besoin de rechercher un hash spécifique
- La colonne confirmations prend trop de place
**Root causes:**
- Pas de pagination, tous les hash sont affichés d'un coup
- Pas de fonctionnalité de recherche
- Colonne confirmations affiche un nombre alors qu'une coche suffit
**Correctifs:**
- Ajout de la pagination (50 hash par page)
- Ajout d'un champ de recherche pour filtrer par hash (recherche partielle)
- Remplacement de la colonne Confirmations par Confirmé avec coche ✓ (vert) ou ✗ (rouge)
- Navigation avec boutons Précédent/Suivant et affichage du nombre de pages
**Evolutions:**
- Meilleure navigation dans la liste des hash
- Recherche rapide d'un hash spécifique
- Interface plus compacte et lisible
**Pages affectées:**
- signet-dashboard/public/hash-list.html
**Motivations:**
- La page home rame et ne s'affiche pas
- Les requêtes API timeout, la page reste blanche
**Root causes:**
- initializeFiles() au démarrage appelle getHashList() et getUtxoList()
- Cache UTXO obsolète force une mise à jour complète (37k+ UTXOs)
- Ces opérations bloquent la boucle d'événements Node.js
**Correctifs:**
- Suppression de l'initialisation au démarrage (initializeFiles)
- Suppression de la fonction initializeFiles (code mort)
- Mise à jour des fichiers à la demande via /api/hash/list et /api/utxo/list
**Evolutions:**
- Le serveur répond immédiatement au démarrage
- La home s'affiche correctement
**Pages affectées:**
- signet-dashboard/src/server.js
- fixKnowledge/dashboard-home-blocked-by-startup-init.md
**Motivations:**
- La home est très lente au premier lancement
- Tous les endpoints sont chargés en parallèle, y compris les plus lents
- L'endpoint /api/utxo/list est très lent car il charge toute la liste
**Root causes:**
- loadData() charge 10 endpoints en parallèle sans priorisation
- loadAvailableForAnchor() charge toute la liste UTXO juste pour obtenir un count
- Les données moins critiques (avg fee, avg tx amount) bloquent l'affichage initial
**Correctifs:**
- Chargement en 2 phases : données critiques d'abord, données secondaires ensuite
- Création d'un endpoint optimisé /api/utxo/count qui lit directement depuis le fichier texte
- loadAvailableForAnchor() utilise maintenant l'endpoint optimisé au lieu de /api/utxo/list
- Les données secondaires (avg fee, avg tx amount, avg block time) sont chargées en arrière-plan
**Evolutions:**
- Affichage initial plus rapide avec les données critiques
- Meilleure expérience utilisateur avec chargement progressif
- Endpoint optimisé pour obtenir le count sans charger toute la liste UTXO
**Pages affectées:**
- signet-dashboard/src/server.js : Nouvel endpoint /api/utxo/count
- signet-dashboard/public/app.js : Optimisation de loadData() et loadAvailableForAnchor()
**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:**
- L'API d'ancrage tentait de se connecter au nœud Bitcoin via IPv6 (::1:38332) alors que le nœud n'écoute que sur IPv4
- Les ancrages de documents échouaient à cause de cette erreur de connexion
**Root causes:**
- Le code utilisait 'localhost' comme valeur par défaut, qui peut être résolu en IPv6 (::1) selon la configuration système
- Le nœud Bitcoin n'écoute que sur IPv4 (127.0.0.1), pas sur IPv6
**Correctifs:**
- Remplacement de 'localhost' par '127.0.0.1' dans le constructeur BitcoinRPC (ligne 13)
- Remplacement de 'localhost' par '127.0.0.1' dans la fonction createAnchorTransaction (ligne 234)
- Mise à jour de .env.example pour utiliser 127.0.0.1 au lieu de localhost
- Documentation du problème dans fixKnowledge/anchor-api-ipv6-connection-error.md
**Evolutions:**
- Valeur par défaut sécurisée : le code utilise maintenant 127.0.0.1 par défaut, forçant IPv4
- Documentation : le fichier .env.example reflète la bonne pratique
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js
- api-anchorage/.env.example
- fixKnowledge/anchor-api-ipv6-connection-error.md
**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:**
- Mettre à jour la documentation pour refléter les nouvelles fonctionnalités UTXO
- Documenter les nouvelles routes API
- Expliquer les fonctionnalités de pagination, tri et consolidation
**Root causes:**
- La documentation n'était pas à jour avec les nouvelles fonctionnalités
- Les nouvelles routes API n'étaient pas documentées
- Les utilisateurs n'étaient pas informés des nouvelles capacités
**Correctifs:**
- Mise à jour de learn.html avec section sur la gestion des UTXOs
- Ajout de la documentation des nouvelles routes API dans api-docs.html
- Mise à jour de docs/DASHBOARD.md avec les nouvelles fonctionnalités
**Evolutions:**
- learn.html : Section sur la gestion des UTXOs (pagination, tri, consolidation, capacité d'ancrage)
- api-docs.html : Documentation des routes :
- GET /api/utxo/list : Liste des UTXOs avec compteurs
- GET /api/utxo/small-info : Infos sur les petits UTXOs
- POST /api/utxo/consolidate : Consolidation des petits UTXOs
- Documentation de l'erreur "too-long-mempool-chain" (503)
- docs/DASHBOARD.md : Mise à jour de la section UTXO avec pagination, tri, consolidation, capacité d'ancrage restante
**Pages affectées:**
- signet-dashboard/public/learn.html: Section gestion des UTXOs
- signet-dashboard/public/api-docs.html: Documentation des nouvelles routes API et erreur too-long-mempool-chain
- docs/DASHBOARD.md: Mise à jour fonctionnalités UTXO et endpoints
**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:**
- Afficher la capacité d'ancrage restante directement sur le dashboard principal
- Permettre un suivi rapide du nombre d'UTXOs disponibles pour l'ancrage
**Root causes:**
- La capacité d'ancrage restante n'était visible que sur la page de liste des UTXOs
- Pas de visibilité immédiate sur le dashboard principal
**Correctifs:**
- Ajout d'une carte "Capacité d'Ancrage Restante" dans le dashboard principal
- Affichage du nombre d'ancrages disponibles et du nombre d'UTXOs confirmés
**Evolutions:**
- Nouvelle carte dans la section "État de la Blockchain" affichant :
- Le nombre d'ancrages restants (format: "X ancrages")
- Le nombre d'UTXOs confirmés disponibles (sous-titre)
- Fonction loadAvailableForAnchor() qui charge les données depuis /api/utxo/list
- Spinner de chargement pendant la récupération des données
- Gestion d'erreur avec valeurs par défaut
**Pages affectées:**
- signet-dashboard/public/index.html: Ajout de la carte "Capacité d'Ancrage Restante"
- signet-dashboard/public/app.js: Fonction loadAvailableForAnchor() et intégration dans loadData()
**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:**
- API d'ancrage retournait une erreur "too-long-mempool-chain, too many unconfirmed ancestors [limit: 25]"
- Les transactions d'ancrage ne pouvaient pas être envoyées au mempool
**Root causes:**
- L'API utilisait des UTXOs non confirmés (confirmations = 0) pour créer les transactions
- Lorsqu'un UTXO provient d'une transaction non confirmée avec des ancêtres, Bitcoin Core limite la chaîne à 25 transactions
- L'appel listunspent utilisait params: [0], récupérant tous les UTXOs y compris non confirmés
- Aucun filtre n'excluait les UTXOs non confirmés
**Correctifs:**
- Changement de listunspent params: [0] à params: [1] pour ne récupérer que les UTXOs confirmés
- Ajout d'un filtre supplémentaire pour exclure les UTXOs avec confirmations = 0
- Amélioration des logs pour indiquer le nombre d'UTXOs non confirmés filtrés
- Ajout d'une gestion d'erreur spécifique pour "too-long-mempool-chain" avec code HTTP 503
**Evolutions:**
- Documentation de la correction dans fixKnowledge/api-anchorage-too-long-mempool-chain.md
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js: Filtrage des UTXOs non confirmés, changement minconf de 0 à 1
- api-anchorage/src/routes/anchor.js: Gestion d'erreur spécifique pour too-long-mempool-chain
- fixKnowledge/api-anchorage-too-long-mempool-chain.md: Documentation (nouveau)
**Motivations:**
- Complete documentation for dashboard, domains, ports and environment configuration
- Add new services (ClamAV API, Watermark API) to the infrastructure
- Enhance dashboard with new pages and improved functionality
- Improve deployment scripts and service configurations
**Root causes:**
- Missing comprehensive documentation for infrastructure setup
- Need for antivirus scanning service integration
- Need for watermark service integration
- Dashboard required additional pages and features
**Correctifs:**
- Added comprehensive documentation in docs/ (DASHBOARD.md, DOMAINS_AND_PORTS.md, ENVIRONMENT.md)
- Updated systemd service files with proper environment variables
- Enhanced nginx proxy configuration script
- Updated maintenance documentation
**Evolutions:**
- Added new ClamAV API service (api-clamav) for file scanning
- Added new Watermark API service (api-filigrane) for document watermarking
- Enhanced signet-dashboard with new learn.html page
- Improved dashboard UI with better styles and navigation
- Enhanced app.js with new functionality and better error handling
- Updated API documentation page with complete endpoint descriptions
- Added deployment scripts for watermark and nginx configuration
- Updated hash and UTXO lists with latest data
- Enhanced server.js with new routes and improved Bitcoin RPC integration
**Pages affectées:**
- docs/DASHBOARD.md: New comprehensive dashboard documentation
- docs/DOMAINS_AND_PORTS.md: New infrastructure domains and ports documentation
- docs/ENVIRONMENT.md: New environment variables documentation
- docs/MAINTENANCE.md: Updated maintenance procedures
- docs/README.md: Updated main documentation
- signet-dashboard/public/app.js: Enhanced with new features
- signet-dashboard/public/styles.css: Improved styling
- signet-dashboard/public/index.html: Enhanced main page
- signet-dashboard/public/learn.html: New educational page
- signet-dashboard/public/api-docs.html: Enhanced API documentation
- signet-dashboard/public/hash-list.html: Updated hash list page
- signet-dashboard/public/utxo-list.html: Updated UTXO list page
- signet-dashboard/public/join-signet.html: Updated join signet page
- signet-dashboard/src/server.js: Enhanced server with new routes
- signet-dashboard/start.sh: Updated startup script
- signet-dashboard/signet-dashboard.service: Updated systemd service
- api-anchorage/anchorage-api.service: Updated systemd service
- api-faucet/faucet-api.service: Updated systemd service
- configure-nginx-proxy.sh: Enhanced nginx configuration script
- add-watermark-certificate.sh: New watermark certificate script
- deploy-watermark-nginx.sh: New deployment script
- api-clamav/: New ClamAV API service
- api-filigrane/: New Watermark API service
- hash_list.txt, utxo_list.txt: Updated with latest data
- anchor_count.txt: Updated anchor count
