**Motivations:**
- website-skeleton needs a real service contract with valid UUIDs and validators
- Service wallet required for production use with configurable public key
- Iframe styling needs improvement to remove scrollbars and match UserWallet theme
**Root causes:**
- DEFAULT_VALIDATEURS used placeholder public key that cannot verify signatures
- No service wallet generation script for production deployment
- Iframe had fixed height causing scrollbars and visual mismatch with dark theme
**Correctifs:**
- Created real service contract in src/serviceContract.ts with dedicated UUIDs (skeleton-service-uuid-4nkweb-2026)
- Added service wallet generation script (generate-service-wallet.mjs) with .env and .env.private files
- Improved iframe container styling: increased height (800px), dark background (#1a1a1a), better shadows, hidden scrollbars
- Added .env.private to .gitignore for security
**Evolutions:**
- Service contract automatically loaded on startup and sent to UserWallet iframe
- Public key configurable via VITE_SKELETON_SERVICE_PUBLIC_KEY environment variable
- Added npm script 'generate-wallet' for easy wallet generation
- Enhanced iframe visual integration with UserWallet dark theme
**Pages affectées:**
- website-skeleton/src/serviceContract.ts (new)
- website-skeleton/src/config.ts
- website-skeleton/src/main.ts
- website-skeleton/generate-service-wallet.mjs (new)
- website-skeleton/index.html
- website-skeleton/package.json
- website-skeleton/.gitignore
- website-skeleton/.env (new)
- website-skeleton/.env.private (new)
**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:**
- 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:**
- 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)
