Steps to reproduce on 48efbdb:
0-> settxfee 0.04
1<- true
2
3-> sendtoaddress mwEHWzBhaPYiErWWhmWW7QCjGoKNPaQQax 16
4<- Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here. (code -4)
If the mempool treats wallet transactions any differently then it becomes possible to fingerprint nodes (or worse). On Sep 26, 2015 2:16 AM, “MarcoFalke” notifications@github.com wrote:
Steps to reproduce on 48efbdb https://github.com/bitcoin/bitcoin/commit/48efbdbe986355bd2478f0fdd366b20952fbf30a :
-> settxfee 0.04 <- true
-> sendtoaddress mwEHWzBhaPYiErWWhmWW7QCjGoKNPaQQax 16 <- Error: The transaction was rejected! This might happen if some of the coins in your wallet were already spent, such as if you used a copy of wallet.dat and coins were spent in the copy but not marked as spent here. (code -4)
— Reply to this email directly or view it on GitHub #6725.
@pstratem Can you elaborate? There is already rpc and/or command-line parameters in place to tell the mempool (implicitly) to treat one or more transactions differently when doing a fee-sanity-check. As the node who wants to fingerprint you does not know which params you run, fingerprinting would be hard? Am I missing something?
Nonetheless, #6726 limits the scope of REJECT_HIGHFEE to raw transactions. Once this is merged, a follow up commit will remove the fee check from the mempool completely and place it in the rawrpcwallet code. Effectively, the mempool should then no longer distinguish p2p, raw and wallet txs.
agree with @pstratem. If you know would broadcast transactions that would normally be invalid to accept to a mempool, other nodes could track these transactions.
The mempool should not treat own wallet transaction different. I think even for mempool cleaning i should be avoided.
What’s the use case of accepting local wallet transactions to the mempool where we can be pretty sure that it won’t be broadcasted through other nodes?
@jonasschnelli What’s the use case of accepting local wallet transactions to the mempool where we can be pretty sure that it won’t be broadcasted through other nodes?
Such transactions have enough fee so they will be broadcast by the network…
What’s the use case of having the mempool take care of fee-capping? Shouldn’t this be part of the module which passes the transactions to the mempool?
Such transactions have enough fee so they will be broadcast by the network…
Right. I was just referencing to your PR title (“Mempool should not reject wallet created transactions”). In a world where the wallet and the mempool/node is decoupled, this won’t work (out of the box) and would require a different concept of “privileged transaction” in the mempool (which i’m not sure if this would even make sense).
I agree that the bool fRejectAbsurdFee-check does not belog to the mempool and was very likely done that way because there is currently now way to check wether a transaction would get accepted or rejected (tx inputs check).
@jonasschnelli @pstratem Can you share your thoughts on how the mempool should treat wallet transactions in the context of something like #6557 or #6722?
I think one reason that users could want their own wallet’s transactions accepted into their mempool is if they think they might be running with a smaller mempool / higher effective relay fee than the rest of the network. If that were the case, then they might expect their wallet (which hopefully is using reasonable fee estimates) to generate transactions that should be relayable and mineable by others, even if they happen to run with a configuration that might cause their own mempool not to accept it.
However I can see the tradeoff with potential fingerprinting, and that sounds pretty bad as a potential outcome if a user is generating stuff that is non-relayable by their peers.
Any suggestions on how we should handle this? It’s not clear to me exactly what functionality we want, and what the wallet user experience should be like for either of these situations:
I agree with @pstratem.
If we priories transaction in the men pool it should be independent from the wallet. Like an additional rpc command. But as said, this open door for fingerprinting nodes.
A wallet can keep track of what happens to one of its transaction and resends it (and perhaps after RBF or CPFP).
Wrapping this up, there seems several more or less unrelated issues to solve:
(partly copied from @sdaftuar post)
a wallet tx **wouldn't qualify** for entry into the user's own mempool (probably needs UI improvement mentioned by [@morcos](/bitcoin-bitcoin/contributor/morcos/) in issue [#6972 (comment)](/bitcoin-bitcoin/6972/#issuecomment-155256471) )
