anchorage_layer_simple/fixKnowledge/signet-custom-subsidy-analysis.md

# Analyse : Signet Custom avec Subsidy Différente (4700 BTC au lieu de 50 BTC)

**Auteur** : Équipe 4NK  
**Date** : 2026-01-26  
**Version** : 1.0

## Problème

Les Bloc Rewards affichent ~4700 BTC au lieu des 50 BTC attendus pour un signet standard (ou mainnet dans les 4 premières années).

## Observations du Diagnostic

Le script `diagnose-bloc-rewards.mjs` a analysé 5 transactions coinbase :

1. **Transaction d7696ca7...** : 4699.99907 BTC
2. **Transaction 497df5d5...** : 4249.99916 BTC
3. **Transaction 1cfd9dbd...** : 4099.99919 BTC
4. **Transaction 27811083...** : 3949.99922 BTC
5. **Transaction 3d662b33...** : 3599.99929 BTC

**Constats** :
- ✅ Toutes sont des transactions **coinbase** (confirmées par `getrawtransaction`)
- ✅ Les montants dans `utxo_list.txt` correspondent aux montants dans `getrawtransaction`
- ✅ Les montants sont **cohérents** entre le fichier et le nœud RPC
- ⚠️ Les montants sont **~4700 BTC** au lieu de 50 BTC standard

## Analyse Technique

### 1. Source de la Subsidy

La subsidy (récompense de bloc) est calculée par **Bitcoin Core** dans la fonction `GetBlockSubsidy()`, pas par le miner.

**Flux de création de bloc** :
1. Le miner appelle `getblocktemplate` via RPC
2. Bitcoin Core calcule `coinbasevalue = subsidy + fees`
3. Le miner utilise `tmpl["coinbasevalue"]` pour créer la coinbase
4. Le miner ne modifie **pas** la subsidy, il utilise la valeur fournie par le nœud

**Code du miner** (`miner`, ligne 210) :
```python
cbtx = create_coinbase(height=tmpl["height"], value=tmpl["coinbasevalue"], spk=reward_spk)
```

Le miner utilise directement `tmpl["coinbasevalue"]` fourni par `getblocktemplate`.

### 2. Bitcoin Core Utilisé

**Dockerfile** (ligne 3) :
```dockerfile
ARG BITCOIN_VERSION=${BITCOIN_VERSION:-30.2}
```

Bitcoin Core 30.2 est téléchargé depuis `bitcoincore.org` (ligne 18-22) :
```dockerfile
BITCOIN_URL="https://bitcoincore.org/bin/bitcoin-core-${BITCOIN_VERSION}/bitcoin-${BITCOIN_VERSION}-${TRIPLET}.tar.gz"
```

**Conclusion** : Bitcoin Core n'est **pas modifié** dans ce projet, c'est la version officielle.

### 3. Chain Params du Signet

Pour un signet custom, Bitcoin Core utilise des **chain parameters** spécifiques définis dans le code source.

**Fonction `GetBlockSubsidy()` dans Bitcoin Core** :
- Pour mainnet/signet standard : 50 BTC pour les blocs 0-209999
- Pour regtest : 50 BTC avec halving tous les 150 blocs
- Pour signet custom : dépend des chain params compilés

### 4. Hypothèses sur la Subsidy ~4700 BTC

**Hypothèse 1 : Signet Custom avec Chain Params Modifiés**
- Le signet custom pourrait avoir été créé avec des chain params modifiés dans une version custom de Bitcoin Core
- Si le nœud a été compilé avec des chain params différents, la subsidy serait différente
- **Mais** : Le Dockerfile utilise Bitcoin Core officiel, donc cette hypothèse est peu probable

**Hypothèse 2 : Accumulation de Frais Exceptionnelle**
- La coinbase = subsidy + fees
- Si les frais sont très élevés (~4650 BTC), cela expliquerait le montant total
- **Mais** : Les frais de transaction ne peuvent pas être aussi élevés sur un signet (pas assez de transactions)

**Hypothèse 3 : Signet Fork avec Subsidy Custom**
- Le signet pourrait être un fork d'un autre projet (ex. Easepay mentionné dans README)
- Le README mentionne "Custom Easepay Bitcoin Signet"
- Easepay pourrait avoir modifié les chain params pour une subsidy différente
- **Probable** : Le signet a été initialisé avec une version custom de Bitcoin Core qui a des chain params modifiés

**Hypothèse 4 : Bug ou Configuration Anormale**
- Un bug dans la configuration du signet ou dans les chain params
- Une configuration anormale qui multiplie la subsidy
- **Peu probable** : Les montants sont cohérents et stables

## Conclusion

**Cause la plus probable** : Le signet custom a été initialisé avec une **version modifiée de Bitcoin Core** (probablement un fork Easepay) qui a des **chain parameters différents** avec une subsidy de base beaucoup plus élevée (~4700 BTC au lieu de 50 BTC).

**Preuves** :
1. Le miner utilise la valeur fournie par `getblocktemplate` (pas de modification côté miner)
2. Bitcoin Core actuel est officiel (30.2), mais le signet a été initialisé avant
3. Le README mentionne "Custom Easepay Bitcoin Signet"
4. Les montants sont cohérents et stables (pas de bug aléatoire)

**Impact** :
- Les Bloc Rewards affichent ~4700 BTC car c'est la subsidy réelle de ce signet custom
- Ce n'est **pas une erreur**, c'est le comportement attendu pour ce signet
- Le dashboard doit afficher les montants réels, pas forcer 50 BTC

## Recommandations

1. **Documenter la subsidy réelle** : Le signet custom a une subsidy de ~4700 BTC par bloc (ou une formule différente)
2. **Ne pas forcer 50 BTC** : Afficher les montants réels depuis `getrawtransaction`
3. **Vérifier l'historique** : Si possible, vérifier avec quel Bitcoin Core le signet a été initialisé
4. **Adapter l'affichage** : Si nécessaire, ajouter une note expliquant que ce signet custom a une subsidy différente

## Commandes de Vérification

```bash
# Vérifier la coinbasevalue actuelle
curl -s --user bitcoin:bitcoin --data-binary '{"jsonrpc":"1.0","id":"test","method":"getblocktemplate","params":[{"rules":["signet"]}]}' -H 'content-type: text/plain;' http://127.0.0.1:38332/wallet/custom_signet | jq -r '.result.coinbasevalue'

# Vérifier une transaction coinbase
curl -s --user bitcoin:bitcoin --data-binary '{"jsonrpc":"1.0","id":"test","method":"getrawtransaction","params":["d7696ca795fe16dfa8516f5267d476c755a8f2bdb93f5ff0dc14a2599c070cce", true]}' -H 'content-type: text/plain;' http://127.0.0.1:38332/wallet/custom_signet | jq -r '.result.vout[0].value'
```

## Références

- Bitcoin Core `GetBlockSubsidy()` : Fonction qui calcule la subsidy selon les chain params
- `getblocktemplate` : RPC qui retourne `coinbasevalue = subsidy + fees`
- README.md : Mentionne "Custom Easepay Bitcoin Signet"
- Dockerfile : Utilise Bitcoin Core 30.2 officiel (mais le signet a été initialisé avant)