Oui enfin ne nous emballons pas. C'est très loin de faire consensus. De plus l'urgence est moindre puisque l'on est redescendu proche des 20 sat/vB.
Ton lien pointe vers un mail assez sporadique, qui dit notamment :
It's a mistake that the existing filters weren't extended to Taproot transactions.
Mes connaissances sont trop limitées pour savoir exactement de quels filtres il s'agit, mais en lisant d'autres emails du même fil, on tombe aussi sur ce genre de choses :
There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [ 0 ]:
"If we ban "useless data" then it would be easy for would-be data storers to instead embed their data inside "useful" data such as dummy signatures or public keys. Doing so would incur a ~2x cost to them, but if 2x is enough to disincentivize storage, then there's no need to have this discussion because they will will be forced to stop due to fee market competition anyway. [...]
But if we were to ban "useful" data, for example, saying that a witness can't have more than 20 signatures in it, then we are into the same problem we had pre-Taproot: that it is effectively impossible construct signing policies in a general and composeable way, because any software that does so will need to account for multiple independent limits. We deliberately replaced such limits with "you need to pay 50 weight for each signature" to makes this sort of analysis tractable."
[ 0 ]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.htmlEt si l'on décide de faire quelque chose, alors se posent toujours les deux mêmes questions :
- quelles données sont légitimes, et lesquelles ne le sont pas ? (+ la censure est-elle légitime, elle aussi ?)
- comment peut-on (d'un point de vue technique) censurer les transactions '"inutiles" sans impacter les transactions "utiles" ?
I'm curious about what you believe to be "non-economic" txs. As far as I can tell, any transaction included in the blockchain is economically motivated by the very evidence of fees paid. [...]
Even if we eliminate small UTXOs, OP_RETURN, or whatever other vector of the day that is currently being used to propagate such "non-economic" information, we will always have the potential variance in the signature data to do so. The best you can hope for is to make such means so inefficient that the real cost-per-bit is expensive enough that there are fewer distinct use cases. However, this isn't enough to actually *prevent* the "spam". By increasing the cost-per-bit, it may limit it to only "non-economic" information of extremely high value (note the contradiction), it limits the number of use cases while also increasing the impact of the use cases that make it past that threshold. Thus, it isn't the impact of spam that is being reduced so much as it is reducing the number of distinct use cases that result in "spam". [...]
IMO the proper way to handle things like this isn't to introduce consensus or relay policy to incentivize the expansion of the chain weight these "non-economic" use cases require, but rather to reduce the necessary chain footprint of supposed "economically motivated" transactions, which incidentally is the entire point of all layered scaling tech. [...] If our layered protocols can't survive the current fee environment, the answer is to fix the layered protocols.
Parmi les solutions proposées, certaines inciteraient surtout les émetteurs de transactions "non-économiques" à les envoyer directement aux mineurs plutôt que de les faire passer par le réseau. Je ne suis pas sûr que ce soit souhaitable.
Par ailleurs, interdire quelque chose, c'est inciter à trouver des contournements. Comme dit dans la citation au-dessus, s'ils ne peuvent plus faire leurs Inscriptions comme actuellement, ces utilisateurs essaieront sûrement de faire ça autrement, d'une manière potentiellement encore plus impactante pour le réseau. Par exemple inclure les données dans des clés publiques, ce genre de choses. C'est extrêmement inefficace pour eux car très coûteux, mais en même ça ferait exploser l'UTXO-set.
Bref, rien n'est aussi simple que "la mise en route de l'antispam sur taproot pourrait résoudre le problème". C'est pas méchant hein, mais comme tout problème complexe, ça ne peut pas être résumé en une phrase. Cela dit, merci pour le lien, la lecture était intéressante.
