Fixed broken coinjoin display in transaction list and transaction details. This is more of a bug fix then a new feature.
Moved fAllFromMe and fAllToMe creation blocks up to the top. This changed the indentation of the below if blocks, breaking most of the diffs though the original code stayed the same. Added new vars anyFromMe and anyToMe. Added new condition for (anyFromMe && anyToMe && !fAllFromMe && !fAllToMe). Added type CoinJoin label.
Thanks! Would it be possible to write a RPC test that produces some coin-joins and could therefore be used to test/ensure that the fix does what is says?
I am not sure if you are wanting some c++ tests, or if so, how I would create those.
What I can offer is that you can import some watch only addresses from a transaction that was part of a coinjoin such as the following and do a rescan to see it in your list. dcc2d1a7b80838ed92a89771e411691b4d3c510c4c34a3766b1651b4b88a67c4
If you have joinmarket, you can run the regtests to generate coinjoin transactions. https://github.com/JoinMarket-Org/joinmarket/tree/master/test but note that in the case where you are running tests that create multiple JM clients to do a coinjoin transactions, the transaction is detected by bitcoin-qt as a "Pay to self" transaction and not a coinjoin because you own all the inputs and all the outputs.
Please don't label these transactions as "Coinjoin"-- coinjoin isn't the only reason you'd end up with inputs from outside of you wallets. Other examples are "anyonecanpay" style kickstarter transactions, or blockchain coinflips. I think calling them a "joint" or "multiparty" transaction would be preferable.
It would be really preferable to not make this functionality QT specific. The information is no less interesting in listtransactions. @sipa How does this compare to your recent work with foreign inputs and outputs for CT?
simplified to (anyFromMe && !fAllFromMe) before was ...
(anyFromMe && anyToMe && !fAllFromMe && !fAllToMe)
Catches the edge case where someone sends a coinjoin to an external address and they are getting no change back.
Ill take a look at listtransactions.
I am not sure if you are wanting some c++ tests, or if so, how I would create those.
Another reason to expose this information in RPC as well - then it can be tested in the functional tests in qa/rpc-tests. GUI tests are notoriously difficult, and besides that, the unit test framework things too low-level to be conveniently able to test high-level functionality such as transaction lists.
Beyond noting these as multiparty, can someone explain what this is intended to do? The only description in the PR display is "fix broken coinjoin display" -- but the only thing I am aware of being broken is that computation of the fees is wrong (counts other parties inputs as 'negative fees').
Raedah was describing it in the joinmarket IRC channel as making multiple entries that pay you to different show up as a single ledger entry, and that sounds almost certainly wrong to me.
I was working on this with the belief that a single txid would represent a single item in the transaction list. From the discussion in the joinmarket irc channel, it does make more sense that the expected behavior is to show one item per received with address, so I am closing this.