vjudeu at gazeta.pl [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-18 🗒️ Summary of this message: To fight spam, ...
📅 Original date posted:2023-02-18
🗒️ Summary of this message: To fight spam, a solution is needed to prune large NOPs in the chain. One possible solution is to store the first and last chunk of data in a hash function like SHA-256 and keep the internal state before entering the last chunk. This could allow for pruning of unused parts without invalidating signatures. However, banning specific script fragments may not be effective as spammers can use alternative methods.
📝 Original message:> By standardness rules (where you can have up to 80-byte pushes), a little over 1%. By consensus (520-byte pushes) less than 0.2%.
Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the number of dropping opcodes could be halved.
> I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript.
That means people can still reject an official alternative (for example commitments), so a different approach is needed to fight that spam. Assuming that transactions will be sent directly to the miners, they will be included, that way or another. So, the solution should assume that we will have large NOPs in the chain. And then, if we want to deal with them, some kind of pruning is needed. Switching from witness to non-witness node is not an option, because it would require additional witness validation, and because rules for OP_RETURN can be also lifted.
So, how to prune the Script? In a typical hash function, like SHA-256, data are splitted into smaller chunks, and then processed linearly. I think it is possible to store the first and the last chunk, and keep the internal state of SHA-256, before entering the last chunk. In this way, it should be possible to prune those OP_NOPs. Because that solution will also cover raw scripts (people can switch to them if witness will be more restricted than now).
Also, it gives us a hint, that if any Script upgrade will be considered in the future, we can think about doing it in a way, where unused parts can be pruned, without invalidating signatures.
On 2023-02-18 00:39:16 user Andrew Poelstra <apoelstra at wpsoftware.net> wrote:
> On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> If you ban any of these specific script fragments then spammers will
> just use `IF <anything> ENDIF` and provide the `FALSE` as a zero push.
> And banning *this* would ban legitimate use cases.
>
I realize this is confusingly worded. I mean, they'd provide the `FALSE`
as a separate witness element rather than being part of the witnessScript.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
🗒️ Summary of this message: To fight spam, a solution is needed to prune large NOPs in the chain. One possible solution is to store the first and last chunk of data in a hash function like SHA-256 and keep the internal state before entering the last chunk. This could allow for pruning of unused parts without invalidating signatures. However, banning specific script fragments may not be effective as spammers can use alternative methods.
📝 Original message:> By standardness rules (where you can have up to 80-byte pushes), a little over 1%. By consensus (520-byte pushes) less than 0.2%.
Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the number of dropping opcodes could be halved.
> I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript.
That means people can still reject an official alternative (for example commitments), so a different approach is needed to fight that spam. Assuming that transactions will be sent directly to the miners, they will be included, that way or another. So, the solution should assume that we will have large NOPs in the chain. And then, if we want to deal with them, some kind of pruning is needed. Switching from witness to non-witness node is not an option, because it would require additional witness validation, and because rules for OP_RETURN can be also lifted.
So, how to prune the Script? In a typical hash function, like SHA-256, data are splitted into smaller chunks, and then processed linearly. I think it is possible to store the first and the last chunk, and keep the internal state of SHA-256, before entering the last chunk. In this way, it should be possible to prune those OP_NOPs. Because that solution will also cover raw scripts (people can switch to them if witness will be more restricted than now).
Also, it gives us a hint, that if any Script upgrade will be considered in the future, we can think about doing it in a way, where unused parts can be pruned, without invalidating signatures.
On 2023-02-18 00:39:16 user Andrew Poelstra <apoelstra at wpsoftware.net> wrote:
> On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
>
> If you ban any of these specific script fragments then spammers will
> just use `IF <anything> ENDIF` and provide the `FALSE` as a zero push.
> And banning *this* would ban legitimate use cases.
>
I realize this is confusingly worded. I mean, they'd provide the `FALSE`
as a separate witness element rather than being part of the witnessScript.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster