Quel devrait être l'objectif prévu des paramètres par défaut de la politique (mempool) dans une implémentation de nœud complète comme Bitcoin Core  ?

  • Objectif des paramètres par défaut de la politique (mempool) : anti-DoS, sécurité, crochets de mise à niveau, pro-décentralisation, paternalisme, processus de soft-fork sécurisé
  • Contrôle pour fermer les vecteurs DoS et sécuriser les futurs changements de consensus
  • Compromis entre protection contre les attaques et maximisation des frais pour les protocoles L2 dans le réseau Bitcoin Core

Tout d’abord, il convient de noter qu’il semble y avoir un certain désaccord sur ce point au moment de la rédaction (février 2024).

instagibbs a déclaré dans son document politique sur le zoo  :

Il existe N motivations politiques que je connais  :

Quel devrait être l'objectif prévu des paramètres par défaut de la politique (mempool) dans une implémentation de nœud complète comme Bitcoin Core  ?

Anti-DoS  : seules les choses « bon marché » à valider sont inondées sur le réseau

Sécurité  : certains types de transactions peuvent perturber certains systèmes sans raison valable

de sorte que si nous leur trouvons une utilité plus tard par exemple, une dépense ou une transaction pré-signée.

Pro-décentralisation  : Faites en sorte qu'il soit simple/peu coûteux pour les mineurs de construire des blocs bien rémunérés

est pas « d'attaquer le réseau »  ! ).

Processus de soft-fork sécurisé  : Parfois, le seul mécanisme empêchant un mineur non mis à niveau d'extraire un bloc qui serait considéré comme invalide par les mineurs mis à niveau (mais valide par les mineurs non mis à niveau) est le découragement politique.

Permettez aux gens de payer des frais pour effectuer des transactions dans une API acceptable

Cela correspond à deux des objectifs visés par Suhas dans son message Stack Exchange.

Le but des contrôles de politique est généralement de (a) fermer les vecteurs DoS et (b) de rendre le déploiement des futurs changements de consensus plus sûr, en empêchant le relais de transactions qui violeraient ces futurs changements de consensus bien à l'avance.

Gloria Zhao parle du compromis entre la protection de l'utilisateur Bitcoind contre les attaques (par exemple, l'épuisement du processeur) et la maximisation de la fiabilité de l'augmentation des frais pour les protocoles L2 dans sa présentation sur la « Politique de relais de transactions pour les développeurs L2 » à Adopting Bitcoin 2021.

Jusqu’à présent, ces perspectives semblent relativement alignées, même si elles peuvent comporter de légères différences dans la priorisation.

Un désaccord plus fort concerne ceux qui pensent que la politique est et devrait être utilisée comme un outil pour restreindre la propagation de certains cas d'utilisation (ordinaux, inscriptions, etc.) même lorsque ces transactions sont valables par consensus et ont un taux de frais élevé. De plus, Luke Dashjr estime (sur X) que  :

« L'épinglage des transactions » AFAIK est le résultat d'efforts de centralisation politique, pas un réel problème. L'alternative consiste à encourager diverses politiques et, au niveau technique, à préparer plusieurs variantes de transaction alternatives pour garantir que le rejet d'une transaction ne posera pas de problème.

Cela fait allusion à un désaccord différent sur la question de savoir si la politique par défaut (mempool) doit être standardisée dans les implémentations de nœuds complets pour tenter d'atteindre les objectifs visés. Les opérateurs de nœuds complets sont toujours libres de modifier les valeurs par défaut (la politique ne constitue pas un consensus), mais la standardisation dans ce cas signifierait des valeurs par défaut cohérentes dans les différentes implémentations.