Published on: 2022-10-26T19:09:38+00:00
A competing pull request has been opened in response to feedback regarding the broadcasting of blocks that are 61, 62, or 63 bytes long but not 64 bytes. Greg Sanders initially opened an issue expressing concerns about the oddity of setting the limit at 64 bytes instead of the previously proposed values. However, Peter Todd commented that it is acceptable to restrict only blocks that are 64 bytes long due to a specific reason. It is important to note that this change is not a consensus change like the Great Consensus Cleanup, and it would only affect fairly technical use cases. Feedback is requested on the new pull request.In an email thread on October 20, 2022, Greg Sanders raised concerns about a proposal to limit the broadcasting of data packets larger than 64 bytes. He worried about people finding it odd that the limit was set at 64 bytes instead of the previously proposed values. Despite his concerns, he expressed willingness to modify his proposal and pull request if there were no strong objections. Peter Todd responded, stating that restricting only 64 bytes is justified because there is a specific reason for doing so, and it would only impact fairly technical use cases. The email thread included an attachment with Peter Todd's signature.Greg Sanders proposed relaxing the policy limit for transactions to be 85 non-witness serialized bytes in a message to the Bitcoin developers. He suggested effectively lowering the value to 65 non-witness bytes, which would allow a single input, single output transaction with 4 bytes of OP_RETURN padding. This proposal was made after considering various transaction types. The current policy limit was introduced as a covert fix for CVE-2017-12842, and the motivation behind the chosen "reasonable" constant was later revealed. Sanders wanted to ensure that his proposal did not face opposition due to the oddity of allowing blocks of 61, 62, or 63 bytes but not 64 bytes. Peter Todd responded, asking for clarification on any potential issues and suggesting that spending a single input to OP_RETURN with no payload is a valid use to eliminate dust in the UTXO set. Sanders was open to modifying his proposal if there were no strong objections.The current Bitcoin policy limit for transactions is set at 85 non-witness serialized bytes, introduced as a covert fix for CVE-2017-12842. Greg Sanders proposed relaxing this limit to 65 non-witness bytes, aligning with BlueMatt's proposal in the Great Consensus Cleanup. This change would allow for a single input, single output transaction with 4 bytes of OP_RETURN padding, eliminating the need to pad out 21 bytes to reach p2wpkh size. Alternatively, there is consideration for allowing anything below 64 non-witness bytes, although this may come with potential issues. Peter Todd suggests that spending a single input to OP_RETURN with no payload could serve as a valid use to eliminate dust in the UTXO set.On October 11, 2022, Greg Sanders proposed relaxing the minimum non-witness transaction size policy restriction from 85 to 65 non-witness bytes. This change is motivated by the need to support more exotic transaction types and address a covert fix for CVE-2017-12842. The proposed change would enable a single input, single output transaction with 4 bytes of OP_RETURN padding instead of having to pad out 21 bytes to reach p2wpkh size. However, there is also consideration being given to allowing anything below 64 non-witness bytes. Concerns were raised about backward compatibility for older clients like v0.18, which may not be able to receive transactions from newer clients requiring validation of 85 non-witness serialized bytes. The pull request for this proposed change can be found on GitHub. Until this change reaches a critical mass of 10%+ of the network, propagation of these types of transactions may be hindered.A proposal has been made to relax the current policy limit of 85 non-witness serialized bytes for Bitcoin transactions to 65 non-witness bytes. This change would enable a single input, single output transaction with 4 bytes of OP_RETURN padding instead of having to pad out 21 bytes to reach p2wpkh size. The current limit was introduced as a covert fix for CVE-2017-12842, but the chosen "reasonable" constant was not optimal. Consideration is also being given to allowing anything below 64 non-witness bytes, although this option may come with risks for only a small gain in bytes. The relevant pull request and alternative proposals can be found on GitHub, and feedback and concerns regarding this proposal are welcomed.
Updated on: 2023-08-02T08:04:33.278936+00:00