Change Details

Previously, pad_tx was overpadding transactions by at least 1 byte. This was caused by at least 2 reasons: - the byte encoding the data length after the OP_RETURN was not taken into - the additional byte required by OP_PUSHDATA1 when the data length exceeded 0x4c was not taken into account This is an attempt to make the resulting length match the required length in most situation often. Now, it should only differ in cases where the request size is less than one empty vout above the current tx size or a multiple of one full 220 bytes OP_RETURN. It would be possible to fix the function to make it exact all the time, by handling the transitions when an addition vout is needed, by removing between 0--10 bytes from the previous vout before adding a new one. But there is no use case for such a feature at the moment. `pad_tx` is almost exclusively used in the tests with the default size of 100 bytes, and all but one use (D10199) does not rely on an exact size. The situations in which the exact size cannot be reached are documented and covered by unit tests.

Previously, `pad_tx` was overpadding transactions by at least 1 byte. This was caused by at least 2 reasons: - the byte encoding the data length after the `OP_RETURN` was not taken into - the additional byte required by `OP_PUSHDATA1` when the data length exceeded 0x4c was not taken into account This is an attempt to make the resulting length match the required length in most situation often. Now, it should only differ in cases where the request size is less than one empty `vout` above the current tx size or a multiple of one full 220 bytes OP_RETURN. It would be possible to fix the function to make it exact all the time, by handling the transitions when an addition `vout` is needed, by removing between 0--10 bytes from the previous vout before adding a new one. But there is no use case for such a feature at the moment. `pad_tx` is almost exclusively used in the tests with the default size of 100 bytes, and all but one use (D10199) does not rely on an exact size. So it is probably not worth adding additional complexity at the moment. The situations in which the exact size cannot be reached are documented and covered by unit tests.

Previously, `pad_tx` was overpadding transactions by at least 1 byte. This was caused by at least 2 reasons: - the byte encoding the data length after the `OP_RETURN` was not taken into - the additional byte required by `OP_PUSHDATA1` when the data length exceeded 0x4c was not taken into account This is an attempt to make the resulting length match the required length in most situation often. Now, it should only differ in cases where the request size is less than one empty `vout` above the current tx size or a multiple of one full 220 bytes OP_RETURN. It would be possible to fix the function to make it exact all the time, by handling the transitions when an addition `vout` is needed, by removing between 0--10 bytes from the previous vout before adding a new one. But there is no use case for such a feature at the moment. `pad_tx` is almost exclusively used in the tests with the default size of 100 bytes, and all but one use (D10199) does not rely on an exact size. and all but one use (D10199) does not rely on an exact sizeSo it is probably not worth adding additional complexity at the moment. The situations in which the exact size cannot be reached are documented and covered by unit tests.