I added decoding/matching of transaction inputs for available ones, see example blocks.p2pool.observer/tx/e8c950dd2…f4f55bf966b5a882f0de4f83971b93990a5

mrelay.p2pool.observer/m/monero.social/QrPrVlWtfUowXwWKpQUuYuOL.png (image.png)

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.

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 stressnet.p2pool.observer/tx/c56b19…16c5453365b57943b2922f271692d3d6825

mrelay.p2pool.observer/m/monero.social/THcbtiUIsjEshzQIYtcMOjFN.png (image.png)

<rbrunner7> Cool!

<hbs:matrix.org> DataHoarder[m]: "high certainty" can keep you out of jail

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

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)

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

that answers the same question, "is this transaction produced by this wallet (change, even 0 XMR), or are they receiving a payment?"

See one of the general fund donations to CCS, for example blocks.p2pool.observer/tx/9c4c1a9c4…ffd831f572364bfe45381cc4b646fdb519e

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

or pool payments blocks.p2pool.observer/tx/b9fc621fa…d3b47b2719bc45bab366454cf2a88fd32f5

<slowbeardigger:matrix.org> I’m working on carrot for xmrpay.

<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.

internal self-sends cannot be produced without keys that sender doesn't have

tagging it change would be against how current wallets construct them in stressnet for example

<slowbeardigger:matrix.org> I mean a custom sender.

<slowbeardigger:matrix.org> just checking that xmrpay shouldn’t rely on the tag to credit an otherwise valid external payment.

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)

<slowbeardigger:matrix.org> ty

exception is 0.000 XMR which can land in a random index.