Add maxrelaytxfee #27983

issue carnhofdaki openend this issue on June 27, 2023
  1. carnhofdaki commented at 8:30 am on June 27, 2023: contributor

    Please describe the feature you’d like to see added.

    Just an example (this feature request is not related to mutinynet in any way) - https://mutinynet.com/tx/68be05aec97b7d114e978185f0df76e494196e2b160330c97870b284f444e1c4

    Let’s suppose the miner wants to recycle coins (and shrink the total number of UTXOs) by making an all-fee transaction and eventually mining it. Any other miner would be happy to mine such a transaction if it is relayed to the network.

    No response

    Describe the solution you’d like

    Add maxrelaytxfee parameter, similar to its min equivalent which is present at least since 9d14e689c8, later it became a configurable.

    The value could be in percentage of the amount sent. An absolute number (like the other similar configurables use) may be less helpful here when tho point is to stop broadcasting mostly all-fee transactions.

    Describe any alternatives you’ve considered

    The usual way how UTXOs work is that they retain their full history back to the block from whose coinbase they come.

    Please leave any additional context

    In case of large-scale recycling maybe the chainstate can get back below 6 GiB (at the moment it is 6.3 GiB big). Also the “ordinals theory” may require some rethinking.

  2. carnhofdaki added the label Feature on Jun 27, 2023
  3. carnhofdaki commented at 5:01 pm on June 27, 2023: contributor

    mutinynet com_tx_68be05aec97b7d114e978185f0df76e494196e2b160330c97870b284f444e1c4

    Adding the screenshot in case that explorer will need to switch to pruned mode.

    This is the raw hex transaction:

    00200000000010238662df9105edbfc3bc1afb921e3bd382098624f9b2f5b3efa3144fb6c0c95340000000000fdffffffbb5667fde0eb1f0e169b85377ec7b79c07adfd680f84b0bc5e36180912abdf000000000000fdffffff0100000000000000000f6a0d746561636820426974636f696e0247304402202a9db30eae0197c835093b2837aec99634ab2d9c3d9a24020e4c29cb39f52685022047537dd6bd2c625eed89ea4c64d94a08ac6ed33228addfb2062abb364e3ecf1001210229cce6ae4a3d2d87e88b7c512492d303fd76dde474313d808591ba898c997ae202473044022041f04a1fa9419d133d98ede55472b2f826a4233eb5eb6845ab22454b80924148022060424744d44b7241943c3a81efae13fa44819cd0eb9b9d1deb97a22a00d78bc501210229cce6ae4a3d2d87e88b7c512492d303fd76dde474313d808591ba898c997ae200000000
    

    Decoded by bitcoin-cli:

     0{
     1  "txid": "68be05aec97b7d114e978185f0df76e494196e2b160330c97870b284f444e1c4",
     2  "hash": "ea1436afe745b8990c75ab44f21e12ed92205eb3ae0399f79a425b25f582c06b",
     3  "version": 2,
     4  "size": 332,
     5  "vsize": 170,
     6  "weight": 680,
     7  "locktime": 0,
     8  "vin": [
     9    {
    10      "txid": "34950c6cfb4431fa3e5b2f9b4f62982038bde321b9afc13bfcdb5e10f92d6638",
    11      "vout": 0,
    12      "scriptSig": {
    13        "asm": "",
    14        "hex": ""
    15      },
    16      "txinwitness": [
    17        "304402202a9db30eae0197c835093b2837aec99634ab2d9c3d9a24020e4c29cb39f52685022047537dd6bd2c625eed89ea4c64d94a08ac6ed33228addfb2062abb364e3ecf1001",
    18        "0229cce6ae4a3d2d87e88b7c512492d303fd76dde474313d808591ba898c997ae2"
    19      ],
    20      "sequence": 4294967293
    21    },
    22    {
    23      "txid": "00dfab120918365ebcb0840f68fdad079cb7c77e37859b160e1febe0fd6756bb",
    24      "vout": 0,
    25      "scriptSig": {
    26        "asm": "",
    27        "hex": ""
    28      },
    29      "txinwitness": [
    30        "3044022041f04a1fa9419d133d98ede55472b2f826a4233eb5eb6845ab22454b80924148022060424744d44b7241943c3a81efae13fa44819cd0eb9b9d1deb97a22a00d78bc501",
    31        "0229cce6ae4a3d2d87e88b7c512492d303fd76dde474313d808591ba898c997ae2"
    32      ],
    33      "sequence": 4294967293
    34    }
    35  ],
    36  "vout": [
    37    {
    38      "value": 0.00000000,
    39      "n": 0,
    40      "scriptPubKey": {
    41        "asm": "OP_RETURN 746561636820426974636f696e",
    42        "desc": "raw(6a0d746561636820426974636f696e)#k6nf9k2p",
    43        "hex": "6a0d746561636820426974636f696e",
    44        "type": "nulldata"
    45      }
    46    }
    47  ]
    48}
    

    Similar all-fee transaction can be done on any network (main, test, signet, regtest), one thing to note when submitting via sendrawtransaction is the extra 0 parameter which denotes no limit on the fee.

  4. maflcko commented at 6:14 am on June 28, 2023: member
    I don’t understand this. If the inputs are signed by someone other than the miner, they may (or should) have broadcast the transaction already, making this setting useless. Also, once it is included in a block, the transaction can be fee-sniped by another miner in a re-org. And obviously implementing the setting as suggested by you will also apply it to network transactions, which doesn’t make sense either.
  5. carnhofdaki commented at 10:21 am on June 28, 2023: contributor

    @MarcoFalke Thank you for feedback.

    Last thing first: Yes, it does not make sense to implement it in the same way as minrelaytxfee. Such code would just add one more processing step to each transaction before it is broadcast further.

    Back to your first concern: The miner may have a contract with someone who pays the fees for such recycling service off-chain.

    In my view, a re-org after the other miner (fee-sniper) gets the block from the P2P network and uses its all-fee transaction in blocktemplate of a new block but same height is close to impossible. This miner (fee-sniper) would not be able to prepare any chain of blocks ahead of time and the other miners would be mining on top of the already existing block in the meantime (see chapter 11. Calculations).

  6. maflcko commented at 10:31 am on June 28, 2023: member

    The miner may have a contract with someone who pays the fees for such recycling service off-chain.

    If the fee is paid off-chain anyway and doesn’t exists within the tx, then this whole feature request doesn’t make sense either, because there is no fee to check.

    Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange or the #bitcoin IRC channel on Libera Chat.

  7. carnhofdaki commented at 11:48 am on June 28, 2023: contributor
    OK, thanks.
  8. carnhofdaki closed this on Jun 28, 2023

  9. bitcoin locked this on Jun 27, 2024

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: 2024-12-21 15:12 UTC

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