Relay policy for small transactions #18296

issue Saicere opened this issue on March 8, 2020
  1. Saicere commented at 10:45 AM on March 8, 2020: none

    One (granted, fairly minor) issue I encountered lately was a "tx-size-small (code 64)" error when broadcasting a transaction to discard a small UTXO. The most efficient way to do this that I could see was to simply create a transaction with a single vout consisting of an empty OP_RETURN, but it turns out that such a transaction, while recognized as valid by decoderawtransaction, is below the MIN_STANDARD_TX_NONWITNESS_SIZE defined in policy.h and is therefore rejected for relaying.

    You can of course just add ~30 bytes of junk data to OP_RETURN to reach the size limit, which makes the transaction relayable and mineable with the current policy. Similarly, in the case of any other otherwise-standard transaction that is valid for relaying outside of the limit defined in MIN_STANDARD_TX_NONWITNESS_SIZE , you could just pad the transaction with another OP_RETURN or similar vout. Therefore, this restriction seems both rather pointless and wasteful.

    There are some valid reasons why you might want to junk a UTXO, such as if you do not want to combine it with other UTXOs for privacy reasons (say in the case of dust being sent to an address by a third party for de-anonymization purposes), or if the wallet is empty outside of said UTXO and it would be below the dust limit if you sent it elsewhere. You could of course just leave it, but many wallets do not have coin control or coin locking facilities, which means it might inadvertently be included in a transaction at a later point. As such, while I recognize that this is somewhat of an edge case, seeing as the size restriction does not really seem to fulfill its stated purpose of discouraging non-standard transactions anyway, would it not make sense to loosen this restriction to allow otherwise-standard transactions with just one single-byte vout?

  2. MarcoFalke commented at 10:17 PM on March 8, 2020: member

    If you sign the input with the appropriate script flags or use someone else's input with the appropriate script flags, you can combine them with no loss in privacy that would have otherwise existed. I think we lack the infrastructure to organize this exchange of inputs, but it shouldn't be too hard to write either.

    In any case you posted on the issue list of the Bitcoin Core software. If you have questions about how Bitcoin works, you can ask on the Bitcoin StackExchange or the #bitcoin IRC channel on freenode.

    If you want to suggest changes to Bitcoin, the bitcoin-dev mailing might be better suited.

  3. Saicere commented at 7:20 AM on March 9, 2020: none

    Thanks for the response, but it does not really seem to address the actual issue. Specifically, Bitcoin Core's default relay policy prevents a transaction with exactly one (P2WPKH) vin and exactly one OP_RETURN vout from being recognized as "standard" unless the OP_RETURN contains at least 30 bytes or so of (possibly junk) data, because of the minimum size limit for a transaction, and I believe this might be an oversight as this restriction was only committed less than two years ago .

  4. MarcoFalke commented at 2:02 PM on March 9, 2020: member

    This has not been an oversight; See #16885 for more information.

  5. instagibbs commented at 1:52 PM on March 10, 2020: member

    Now that it's public, can we not just make 64 byte stipped txns invalid?

    cc @jl2012

  6. MarcoFalke commented at 2:20 PM on March 10, 2020: member
  7. MarcoFalke closed this on Apr 28, 2020

  8. MarcoFalke locked this on Feb 15, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-29 03:14 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me