Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-11 📝 Original message:Hello fellow Bitcoiners, ...
📅 Original date posted:2022-10-11
📝 Original message:Hello fellow Bitcoiners,
After looking at some fairly exotic possible transaction types, I ran into
the current policy limit requiring transactions to be 85 non-witness
serialized bytes. This was introduced as a covert fix to policy fix
for CVE-2017-12842. Later the real motivation was revealed, but the
"reasonable" constant chosen was not.
I'd like to propose relaxing this to effectively the value BlueMatt
proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
allow a single input, single output transaction with 4 bytes of OP_RETURN
padding, rather than padding out 21 bytes to get to p2wpkh size.
The alternative would be to also allow anything below 64 non-witness bytes,
but this seems fraught with footguns for a few bytes gain.
The PR is here with more relevant background and alternatives included in
the thread:
https://github.com/bitcoin/bitcoin/pull/26265
Please let us know if there's a fundamental issue with this approach, or
any other feedback.
Best,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221011/709d9a5c/attachment.html>
📝 Original message:Hello fellow Bitcoiners,
After looking at some fairly exotic possible transaction types, I ran into
the current policy limit requiring transactions to be 85 non-witness
serialized bytes. This was introduced as a covert fix to policy fix
for CVE-2017-12842. Later the real motivation was revealed, but the
"reasonable" constant chosen was not.
I'd like to propose relaxing this to effectively the value BlueMatt
proposed in the Great Consensus Cleanup: 65 non-witness bytes. This would
allow a single input, single output transaction with 4 bytes of OP_RETURN
padding, rather than padding out 21 bytes to get to p2wpkh size.
The alternative would be to also allow anything below 64 non-witness bytes,
but this seems fraught with footguns for a few bytes gain.
The PR is here with more relevant background and alternatives included in
the thread:
https://github.com/bitcoin/bitcoin/pull/26265
Please let us know if there's a fundamental issue with this approach, or
any other feedback.
Best,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221011/709d9a5c/attachment.html>