Pourquoi les transactions Bitcoin peuvent être lentes

Le bitcoin est conçu avec un moyen temps du bloc ≈ de 10 minutes, mais ce moyen, et non la garantie. Si votre transaction est bloquée, c'est presque toujours la faute à un mem....surchargé et/ou des frais d'octets trop bas. Ajoutez à cela les exigences du destinataire pour le nombre de confirmations, la taille de la transaction elle-même (en octets virtuels) et la stratégie de portefeuille - et obtenez des différences notables dans le délai de livraison.

Bref : d'où vient le « lent »

1. C'est un memphul plein. Quand il y a plus de transactions non confirmées que de transactions dans les blocs les plus proches, les enchères de commissions commencent.

2. Faible taux de fee (sat/vB). Les mineurs prennent dans le bloc de transaction avec le prix le plus élevé pour l'octet virtuel - pas le montant total de la commission.

3. C'est une grosse transaction. Beaucoup d'entrées (UTXO), anciens formats d'adresse (Legacy) → plus de poids → plus cher/plus long avec le même taux fee.

4. Variabilité du temps du bloc. Les intervalles « natifs » fluctuent : ils peuvent arriver dans 20 secondes, ou peut-être dans 40 + minutes.

5. Stratégies du destinataire. Les échanges/services attendent 1 à 6 confirmations et parfois plus aux heures de pointe.

6. Limites du portefeuille. Tout le monde ne soutient pas le RBF/PCFP, ne sait pas surestimer adéquatement fee, met un profil « économique » par défaut.

Comment ça marche « sous le capot »

Mem....est un tampon de transactions non confirmées dans tous les nœuds. Les nœuds peuvent rejeter des transactions trop bon marché.

Le poids de la transaction est mesuré en vB (virtual bytes). L'inclusion est influencée par le prix par vB (sat/vB).

L'unité a une limite de poids (unités weight), donc les mineurs trient par avantage sat/vB, formant un « seuil d'entrée » dans l'unité la plus proche.

RBF (Replace-By-Fee) permet à l'expéditeur de remplacer une transaction non confirmée par une version plus élevée.

Le PCFP (Child-Pays-For-Parent) permet au destinataire/propriétaire de la sortie d'accélérer la confirmation : dépenser la sortie « parent » reçue en mettant une commission élevée dans la transaction « fille ».

Causes fréquentes de retards et quoi faire

La raison	À quoi ressemble	La solution
Fourni faible sat/vB	« Accroché » pendant des heures/jours	Si la RBF est maintenue avec fee élevé ; sinon - attendre ou demander au bénéficiaire de faire le PFPC
Pic de charge (mem....plein)	Le seuil dans le bloc a augmenté de façon spectaculaire	Attendre le déclin ; porter le fee au niveau actuel ; pour l'avenir - envoyer en dehors des pics
Entrées multiples (UTXO consolidation)	Une transaction « épaisse », coûteuse à accélérer	Consolider UTXO à l'avance lorsque la mémoire est vide ; utiliser le SegWit/bech32
Adresses legacy	Plus de poids dans des conditions égales	Passer à bech32 (bc1... )/SegWit → moins de poids et de commission
Politique de confirmation rigide de la Bourse	Il y en a déjà dans le bloc, mais il n'y a pas d'inscription	Vérifier les exigences (1-6 + conf) ; attendre ; pour l'avenir - traduire plus tôt/via Lightning
Portefeuille sans RBF/CPFP	Tu ne peux pas « faire » une commission	Utiliser un portefeuille RBF ; pour les entrants - négocier le PCFP

Pratique : Comment évaluer correctement une commission

1. Ne voyez pas « commission en satoshi », mais le prix pour le poids est sat/vB.

2. Choisissez la cible par confirmation (dans le bloc suivant/dans le bloc 1-3/économique).

3. Tenez compte du poids de la transaction. Beaucoup d'entrées = supérieure à vB → besoin du prix le plus élevé pour vB pour la même vitesse.

4. Utilisez le SegWit/bech32. Cela réduit le poids sans risques supplémentaires.

5. Gardez votre stock sur fee. Surtout si vous envoyez au moment du pic de charge.

Accélérer les traductions bloquées : méthodes de travail

1) RBF (Replace-By-Fee)

Disponible si la transaction d'origine a été marquée comme replacable.

Envoyer un « remplacement » avec sat/vB supérieur. Les nœuds et les mineurs préfèrent la nouvelle version.

2) CPFP (Child-Pays-For-Parent)

Convient lorsque vous contrôlez la sortie d'une transaction « parent ».

Créez une « fille » avec un sat/vB très élevé pour que le paquet total devienne rentable pour le mineur.

3) Pools accélérateurs (à la discrétion)

Certains pools de maining offrent des accélérateurs payants/partenaires. Évaluer les risques et les conditions.

Comment réduire les risques de retards à l'avance

Utilisez bech32 (bc1...) et SegWit - moins de poids = moins cher et plus rapide au même prix par vB.

Consolidez UTXO en périodes calmes (commissions basses) : combinez les petites entrées en une seule.

Planifiez l'heure. Envoyez les traductions en dehors des pics (lorsque le mem....est déchargé).

Mettez un profil fee adéquat. Pour « au prochain bloc » - payer le prix du marché pour vB.

Sélectionnez un portefeuille RBF et personnalisez manuellement la commission. Sans cela, il est difficile de contrôler la vitesse.

Discutez des exigences du destinataire. Si la Bourse attend 3 ou 6 confirmations, tenez-en compte dans la date limite.

Pour les petits paiements/paiements urgents, considérez Lightning (si pris en charge par les deux parties).

Lightning et L2 comme « plan B »

Lightning Network donne les traductions en secondes et en centimes, mais nécessite le soutien de l'expéditeur et du destinataire, et a des limites de canal.

Certains sites acceptent le BTC par Lightning ou par des intégrations castodiales - c'est une bonne option pour les petites sommes urgentes.

Pour l'écosystème ETH - L2 (Arbitrum/Optimisme/Polygon) : si vous transférez des steiblcoins/tokens au lieu de BTC, cela peut être plus rapide et moins cher.

Chèques-feuilles

Avant d'envoyer BTC

L'adresse du destinataire a été vérifiée ; le format bech32 est préféré.
Le portefeuille prend en charge RBF et la sélection manuelle sat/vB.
Je comprends les confirmations requises du destinataire (bourse/service).
Un taux de rendement adéquat a été choisi pour la cible « au bloc suivant/1-3 ».
Pas de douzaines de petits UTXO ; si nécessaire - consolidation à l'avance.

Si la transaction est « bloquée »

J'ai vérifié dans le navigateur (s'il y a des conflits/remplacements, combien de temps il y a dans le mem....).
RBF est disponible → a envoyé un remplacement avec un sat/vB plus élevé.
Le PCFP est possible → a créé une filiale avec une haute fée.
Si rien, j'attends une baisse de charge ; avisé le bénéficiaire du statut/plan.

Erreurs fréquentes et comment les éviter

Erreur	Pourquoi c'est mauvais	Que faire
Focus sur le « montant de la commission » plutôt que sur le sat/vB	Le prix par octet est important pour les mainers, pas le montant absolu	Voir sat/vB, prendre en compte le poids de la transaction
Adresses legacy et un tas d'entrées	Transaction « épaisse », priorité faible	Passez à l' SegWit/bech32, consolidez UTXO à l'avance
Portefeuille sans RBF	Rien à accélérer	Choisissez vos portefeuilles avec RBF/CPFP
Envoi à l'heure de pointe	Trop ou retard	Planifier le temps, miser sur le marché fee
Ignorer les exigences du destinataire	« Pas d'argent », bien que 0 conf existe déjà	Découvrez combien de confirmations sont nécessaires à l'avance

FAQ (court)

Combien est « normal » d'attendre la confirmation ?

Par temps calme et avec un sat/vB adéquat - 10-60 minutes (1-3 confirmations). Les heures de pointe sont plus longues.

Si je mets une énorme commission - sera instantané ?

Il n'y a aucune garantie en raison de la variabilité du temps du bloc, mais les chances d'entrer dans le prochain bloc sont nettement plus élevées.

Est-il possible de « faire » une commission après l'envoi ?

Oui, si la transaction était RBF-replacable. Sinon, seulement le PCFP (si vous contrôlez la sortie reçue) ou attendre.

Pourquoi la Bourse ne crédite-t-elle pas si ma transaction est déjà dans le bloc ?

La Bourse peut exiger plusieurs confirmations. C'est sa politique de risque.

Les transferts de Bitcoin lents ne sont pas une « panne de réseau », mais un modèle de vente aux enchères de commissions sur le marché et une capacité limitée de blocs. Surveillez le sat/vB, utilisez le SegWit/bech32, planifiez l'heure, gardez la RBF/PCFP à portée de main et tenez compte des règles du bénéficiaire. Vos transactions BTC seront alors aussi prévisibles que possible - sans trop de nerfs et un « Pending » prolongé.