**Motivations:**
- Consolider automatiquement les petits UTXOs avant un ancrage si les fonds sont insuffisants
- Améliorer l'efficacité en réduisant le nombre d'inputs dans les transactions
- Permettre l'ancrage même avec des fonds répartis sur plusieurs petits UTXOs
**Root causes:**
- Le wallet contient souvent de nombreux petits UTXOs (2500 sats) créés par le provisioning
- Les fonds sont répartis sur plusieurs petits UTXOs, rendant difficile la création d'ancrages avec provisioning complet
- La consolidation manuelle via le dashboard n'est pas automatique
**Correctifs:**
- Ajout d'une méthode attemptAutoConsolidation() qui appelle l'API du dashboard pour consolider
- Intégration de la consolidation automatique dans createAnchorTransaction() avant la réduction du provisioning
- Protection contre les abus : cooldown de 5 minutes, limite à la première tentative
**Evolutions:**
- Consolidation automatique déclenchée si au moins 5 petits UTXOs ET (fonds insuffisants OU > 10 petits UTXOs)
- Réessai automatique de l'ancrage après consolidation
- Fallback sur la réduction du provisioning si la consolidation échoue ou n'est pas suffisante
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js
- features/api-anchorage-automatic-consolidation.md
**Motivations:**
- Permettre l'ancrage même si les fonds sont insuffisants pour le provisioning complet
- Réduire automatiquement le provisioning si nécessaire au lieu d'échouer
- Garantir qu'un ancrage minimal peut toujours être créé si les fonds sont suffisants
**Root causes:**
- Le système échouait si les fonds étaient insuffisants pour le provisioning complet (7 UTXOs)
- Aucune logique de fallback pour réduire le provisioning ou permettre un ancrage minimal
- Les utilisateurs devaient manuellement réduire le provisioning ou obtenir plus de fonds
**Correctifs:**
- Ajout d'une logique de réduction automatique du provisioning si les fonds sont insuffisants
- Réduction progressive : 7 → 6 → 5 → 4 → 3 → 2 → 1 → 0 UTXOs de provisioning
- En dernier recours, permet un ancrage sans provisioning (juste l'ancrage du hash)
- Récursion avec provisioning réduit si l'essai initial échoue
**Evolutions:**
- Le système essaie maintenant automatiquement avec un provisioning réduit si nécessaire
- L'ancrage est toujours créé si les fonds sont suffisants pour au moins l'ancrage minimal
- Les logs indiquent quand le provisioning est réduit automatiquement
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js
- fixKnowledge/api-anchorage-utxo-robustness-improvements.md
**Motivations:**
- Corriger le bug de calcul des frais qui empêchait l'utilisation de tous les UTXOs disponibles
- Améliorer la robustesse de la gestion des UTXOs pour les ancrages avec provisioning
- Utiliser tous les UTXOs disponibles si nécessaire au lieu de limiter à 20
- Améliorer les messages d'erreur avec des suggestions de solutions
**Root causes:**
- Bug de calcul des frais : la condition utilisait totalNeeded + estimatedFeeForMultipleInputs alors que totalNeeded inclut déjà estimatedFee (double comptage)
- Limitation à 20 UTXOs maximum empêchait d'utiliser tous les UTXOs disponibles
- Messages d'erreur peu informatifs ne suggéraient pas de solutions
**Correctifs:**
- Correction du bug de calcul des frais : utilisation de totalOutputAmount + currentEstimatedFee au lieu de totalNeeded + estimatedFeeForMultipleInputs
- Utilisation de tous les UTXOs disponibles si nécessaire (au lieu de limiter à 20)
- Augmentation de la limite de combinaison de 20 à 100 UTXOs
- Recalcul correct des frais avec le nombre réel d'inputs à chaque étape
**Evolutions:**
- Amélioration des messages d'erreur avec suggestions de solutions (faucet, mining, consolidation, réduction du provisioning)
- Calcul du déficit (shortfall) pour informer l'utilisateur du montant manquant
- Logique de fallback pour utiliser tous les UTXOs disponibles si la première tentative échoue
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js
- fixKnowledge/api-anchorage-utxo-robustness-improvements.md
**Motivations:**
- Synchronisation des modifications sur l'API anchorage, les services et le website skeleton
- Ajout de scripts de monitoring et de diagnostic pour l'API anchorage
- Documentation des problèmes de mutex et de provisioning UTXO
**Root causes:**
- N/A (commit de synchronisation)
**Correctifs:**
- N/A (commit de synchronisation)
**Evolutions:**
- Ajout de scripts de monitoring et de diagnostic pour l'API anchorage
- Amélioration de la gestion des mutex et des UTXOs
- Mise à jour de la documentation
**Pages affectées:**
- api-anchorage/src/bitcoin-rpc.js
- api-anchorage/src/routes/anchor.js
- api-anchorage/src/routes/health.js
- api-anchorage/src/server.js
- api-anchorage/README-MONITORING.md
- api-anchorage/cleanup-stale-locks.mjs
- api-anchorage/diagnose.mjs
- api-anchorage/unlock-utxos.mjs
- service-login-verify/src/persistentNonceCache.ts
- signet-dashboard/src/server.js
- signet-dashboard/public/*
- userwallet/src/hooks/useChannel.ts
- userwallet/src/services/relayNotificationService.ts
- userwallet/src/utils/defaultContract.ts
- website-skeleton/src/*
- docs/DOMAINS_AND_PORTS.md
- docs/INTERFACES.md
- features/*
- fixKnowledge/*
**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:**
- 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:**
- 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:**
- 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:**
- 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:**
- 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
**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
**Motivations:**
- Fix 401 error on anchorage API due to .env not being loaded correctly
- Fix 502 error on dashboard due to service not running
- Add backup script for mining keys and wallet descriptors
- Improve service management with startup scripts and systemd services
**Root causes:**
- dotenv.config() was called without explicit path, causing .env to be loaded from wrong directory
- Services were not started automatically, causing 502 errors
- No backup mechanism for critical keys and wallet data
**Correctifs:**
- Improved .env loading in api-anchorage/src/server.js with explicit path
- Improved .env loading in signet-dashboard/src/server.js with explicit path
- Added backups/ directory to .gitignore to prevent committing sensitive data
- Created export-backup.sh script for backing up mining keys and wallet descriptors
**Evolutions:**
- Added api-anchorage/start.sh script for proper service startup
- Added api-anchorage/anchorage-api.service systemd service file
- Added fixKnowledge/api-anchorage-401-error.md documentation
- Added fixKnowledge/dashboard-502-error.md documentation
- Updated mempool submodule
**Pages affectées:**
- .gitignore (added backups/)
- api-anchorage/src/server.js (improved .env loading)
- api-anchorage/start.sh (new)
- api-anchorage/anchorage-api.service (new)
- signet-dashboard/src/server.js (improved .env loading)
- export-backup.sh (new)
- fixKnowledge/api-anchorage-401-error.md (new)
- fixKnowledge/dashboard-502-error.md (new)
- mempool (submodule updated)
