<s​eekdalooper:matrix.org> [@rbrunner7:monero.social](https://matrix.to/#/@rbrunner7:monero.social) thanks for the docs suggestion the other day. Heres a draft for a "Monero for Merchants" guide.

<s​eekdalooper:matrix.org> Would love feedback:

<s​eekdalooper:matrix.org> github.com/seekloops/monero-for-merchants

<v​tnerd:monero.social> You mean could lws be given the _real_ key image to compute a balance? No. However, carrot provided a view-balance-key, such that lws only replies with the real spends, making it super easy for frontends to compute balance

<j​effro256:monero.social> Why not? Isn't that how a full wallet computes balance? Maybe I'm misunderstanding the question. You need scanned incoming enotes and spent key images to get a balance, but ostensibly a LWS already has the scanned incoming enotes by virtue of having the view-incoming private key. If the LW client sent the spent key images, with associations to its corresponding incoming enote to t<clipped message>

<j​effro256:monero.social> he LWS, couldn't the LWS get the balance ?

the issue is that get addr txs doesnt currently supply what i call recv_outputs

this hinders real rigorous balance calc

currently lwsf fudges this slightly by calling get unspent outs in the poll

aiui

but that doesnt actually cover all output cases aiui

i've been trying to write this up, but some pretty terrible things have happened to me recently so I've been delayed

I've had a fully working version of this for a couple years, but like I said, some pretty terrible things have happened

anyway, I would like to suggest this. I think it's a much better situation. At the same time we can also simplify the API in a couple other ways. things like possibly setting a mempool flag on outs etc. it simplifies the client too.

if people are interested, then I'll place this into a proposal

I think we can probably eliminate get unspent outs and definitely can remove get addr info

vtnerd: that's what i wanted, the ability to differeniate between spent and unspent outputs

without carrot, as it's not coming out for at least a few years

<v​tnerd:monero.social> Yes it could, but I was framing it as there is no API for this. I'm not sure its worth doing because it requires the frontend to compute key images, at which point why not just so the filtering too? In other words, the frontend doesn't want to provide the spend key, which is really what the API would want

ah i see

that's fair, i don't know what other way to display the correct balance in a fully transparent way

without giving the user a chance to spend the outputs

<r​brunner7:monero.social> Cindy: "without carrot, as it's not coming out for at least a few years" Wait, what, at least a few years? Maybe you confuse something there? We have something like an alpha FCMP++ plus Carrot network running already.

well.. i was overestimating :P

just in case