Rubriques tendance
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Je vois quelques commentaires demandant ce qui peut être fait à propos de ce type d'incorporation de données (qui existe depuis longtemps).
C'est un peu long, mais j'espère que cela sera utile comme référence à la question plus générale de savoir si vous pouvez aborder les "problèmes" au niveau du protocole au niveau des mineurs / des politiques.
De manière réaliste, à part un soft fork, il y a très peu de choses qui peuvent être faites techniquement, et même cela aurait de sérieuses limitations et conséquences (c'est tout l'intérêt de ce design de protocole défectueux).
La première réaction évidente est de demander aux mineurs d'arrêter de miner des choses comme ça. Il y a quelques façons, mais l'une d'elles serait d'augmenter leur -dustrelayfee.
Par défaut, c'est 0.00003 BTC/kB (3 sat/vB), ce qui entraîne une limite de sortie de poussière de 330 sats pour P2WSH.
Pour cette transaction avec 1859 telles sorties, le total bloqué dans des sorties non dépensables est de 1859*330 = 613,470 sats (736 $ à 120k/BTC).
Disons que vous parvenez à convaincre la grande majorité (95%) des mineurs de multiplier cette valeur de configuration par 10, l'expéditeur devrait choisir entre payer 6.1M sats (7k $) ou envoyer tel quel et attendre jusqu'à ce que la petite proportion de mineurs (5%) utilisant l'ancien défaut. Ils feraient probablement ce dernier choix car cela représente suffisamment de hashrate pour trouver 7 blocs/jour en moyenne, et quelle est l'urgence ?
Ayant échoué à arrêter cela au niveau des mineurs, vous pourriez maintenant être tenté de convaincre les opérateurs de nœuds de changer leur défaut et/ou de changer le défaut dans le core v31.
Disons que vous réussissez, et que le core v31 contient un défaut plus élevé. L'expéditeur peut simplement se connecter préférentiellement pour essayer d'atteindre les mineurs dans le protocole.
Donc, vous doublez la mise et vous simulez un peering préférentiel de sorte qu'il ne soit pas suffisamment fiable.
L'expéditeur n'a maintenant d'autre choix que de payer un mineur OOB - s'ils doivent le faire, autant que chaque sortie soit de 0 sats. Cela pourrait en fait être financièrement bénéfique pour l'expéditeur et le mineur, car au lieu que les sats soient brûlés en tant que frais, ils iraient au mineur / seraient économisés par l'expéditeur.
Pour être juste, il faudrait un effort pour établir ces rails directs vers des mineurs qui sont exclusivement motivés financièrement, mais c'est un coût fixe, et je n'ai aucun doute que cela serait fait, puis intégré via API à des services de minting centralisés.
Ainsi, le problème serait probablement pire que la situation que nous avons aujourd'hui.
Meilleurs
Classement
Favoris