12:36:11 <DataHoarder[m]> I added decoding/matching of transaction inputs for available ones, see example https://blocks.p2pool.observer/tx/e8c950dd2d501ed24f9ab1b3fe97cf4f55bf966b5a882f0de4f83971b93990a5
12:36:14 <DataHoarder[m]> https://mrelay.p2pool.observer/m/monero.social/QrPrVlWtfUowXwWKpQUuYuOL.png (image.png)
12:37:14 <DataHoarder[m]> For the ongoing FUD about OVK allowing something that is not possible now, well, it's possible (and has been always possible) to do so with high certainty even with just incoming view keys.
12:38:38 <DataHoarder[m]> And after FCMP++ even without OVK (legacy wallets) you can detect incoming payments vs outgoing payments entirely via the "change"  or "payment" output tag, with just incoming view keys https://stressnet.p2pool.observer/tx/c56b191c58f194fe24e5933a929f316c5453365b57943b2922f271692d3d6825
12:38:42 <DataHoarder[m]> https://mrelay.p2pool.observer/m/monero.social/THcbtiUIsjEshzQIYtcMOjFN.png (image.png)
14:05:16 <br-m> <rbrunner7> Cool!
14:10:50 <br-m> <hbs:matrix.org> DataHoarder[m]: "high certainty" can keep you out of jail
14:12:17 <DataHoarder> in the linked case, 0.00000 XMR output is only produced by known wallets as change output for a sweep, meaning all inputs would be owned by the source wallet
14:14:22 <DataHoarder> in other examples you end up with 142 inputs where all rings have at least one input owned by the recipient wallet (be it > 0 XMR or 0 case)
14:15:10 <DataHoarder> in the FCMP++ case, without OVK (just incoming), wallets will only only produce a "change" output (these are tagged) in case they own the inputs/transaction
14:16:03 <DataHoarder> that answers the same question, "is this transaction produced by this wallet (change, even 0 XMR), or are they receiving a payment?"
15:04:26 <DataHoarder[m]> See one of the general fund donations to CCS, for example https://blocks.p2pool.observer/tx/9c4c1a9c47f739916d8d591100869ffd831f572364bfe45381cc4b646fdb519e
15:05:38 <DataHoarder[m]> all inputs have exactly one owned output, and even if recipient was unknown, you'd also know the amount as input and amount as output via addition
15:08:26 <DataHoarder[m]> or pool payments https://blocks.p2pool.observer/tx/b9fc621fa59032a02a40ff94daf90d3b47b2719bc45bab366454cf2a88fd32f5
15:31:37 <br-m> <slowbeardigger:matrix.org> I’m working on carrot for xmrpay.
15:31:37 <br-m> <slowbeardigger:matrix.org> the new key hierarchy, k_v should still validate external invoice payments without seeing normal internal change, right? Also, since enote_type is sender selected, I assume gateways should not reject an valid invoice output just because it was tagged change.
15:34:38 <DataHoarder> internal self-sends cannot be produced without keys that sender doesn't have
15:36:08 <DataHoarder> tagging it change would be against how current wallets construct them in stressnet for example
15:38:34 <br-m> <slowbeardigger:matrix.org> I mean a custom sender.
15:38:34 <br-m> <slowbeardigger:matrix.org> just checking that xmrpay shouldn’t rely on the tag to credit an otherwise valid external payment.
15:39:35 <DataHoarder> even if it's tagged change it's still incoming XMR. Usually the change will arrive at index 0 of each account, whatever that is (account 0 index 0 is main address)
15:39:51 <br-m> <slowbeardigger:matrix.org> ty
15:39:58 <DataHoarder> exception is 0.000 XMR which can land in a random index.