Monkey Test Feature (MTF) #29389

issue ThunderCat1000 openend this issue on February 5, 2024
  1. ThunderCat1000 commented at 10:54 pm on February 5, 2024: none

    Monkey Test Feature (MTF)

    Consider the following scenario:

    Say Chad has a Bitcoin wallet and wants to send a large amount of Bitcoins to another wallet. Chad decides to send a smaller test amount first to make sure everything is OK. Chad proceeds to sign and send the transaction, however, the software has two bugs that transmit his entire balance to a wallet that is not under Chads control. Wouldn’t it be nice to be able to perform a formal test (what i call a Monkey Test) that leverages the logic of the send utilities with a predefined amount (the minimal amount of Bitcoin one can conceivably send) that way these two theoretical bugs don’t wipe out the entire wallet, allowing you to test one piece of functionality in isolation?

    MTF can also stand for M%%%%er F%%%er!, which is what we say when these two bugs compound one another to create total loss of funds when we are also trying to be responsible.

  2. ThunderCat1000 added the label Feature on Feb 5, 2024
  3. achow101 commented at 11:44 pm on February 5, 2024: member

    I don’t see how this is at all useful. If you are concerned about the existence of such a bug, then you can make the test transactions yourself. However I don’t see how such test transactions would safeguard the sender anyways - if there exists a bug that can send all funds in the wallet to someone else, then making a test transaction could hit that bug and send all funds regardless.

    A better method is to split up the steps of unsigned transaction creation, transaction signing, and transaction broadcast, and inspect the transaction after each step to verify that the transaction is indeed what you want. This can be done with PSBTs. You can create an unsigned transaction with walletcreatefundedpsbt. You can inspect the result with decodepsbt and check that the output addresses and amounts are what you expect them to be. You can sign by using walletprocesspsbt and then result again to make sure it hasn’t changed except that signatures have been added. And then you can broadcast using sendrawtransaction. There are GUI counterparts for all of these too.

  4. ThunderCat1000 commented at 0:57 am on February 6, 2024: none
    The idea was that there can exist 2 bugs that work together to deplete your wallet when you are merely sending a dust transaction using a normal wallet. A standard feature for wallets to test one part of the transaction in isolation (the send to address function) without being impacted by other code that has a dynamic amount for the transaction, would give peace of mind without the complexity of the process you are suggesting. Hence the name “Monkey Test”
  5. maflcko added the label Wallet on Feb 6, 2024
  6. maflcko removed the label Feature on Feb 6, 2024
  7. maflcko added the label Questions and Help on Feb 6, 2024
  8. maflcko commented at 10:06 am on February 6, 2024: member

    I also don’t understand your “test”. If there is a bug in the wallet, calling the wallet code with a different amount is not going to fix the bug. If you are worried about the created transaction, my recommendation would be to inspect it before broadcasting, as mentioned above.

    In any case, no one is holding anyone back from implementing a “test”. Pull requests are welcome, but I am going to close the issue for now, unless there is something specific to discuss.

  9. maflcko closed this on Feb 6, 2024

  10. ThunderCat1000 commented at 1:16 am on February 7, 2024: none
    It’s hard to understand, but it’s obvious in hindsight. The problem is that if I go to send a test transaction, and one bug is in the amount field, and another is in the recipient field, you could lose all funds for simply trying to test a dust transaction. Wouldn’t it be nice if this were mitigated with a test feature in the wallet interface? The idea is that you could test the recipient field with a predefined HARD CODED DUST AMOUNT so that these two bugs don’t compound, then you can proceed to use the amount field as well. It’s actually a HUGE ISSUE for institutions, and A LOT more money will pump in once fixed. So please, let’s not close this issue!

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

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