17:41:52 <m-relay> <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.
17:41:53 <m-relay> <s​eekdalooper:matrix.org> Would love feedback:
17:41:55 <m-relay> <s​eekdalooper:matrix.org> https://github.com/seekloops/monero-for-merchants
18:43:31 <m-relay> <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
18:55:09 <m-relay> <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>
18:55:11 <m-relay> <j​effro256:monero.social> he LWS, couldn't the LWS get the balance ?
18:57:19 <endogenic> the issue is that get addr txs doesnt currently supply what i call recv_outputs
18:57:28 <endogenic> this hinders real rigorous balance calc
18:57:43 <endogenic> currently lwsf fudges this slightly by calling get unspent outs in the poll
18:57:44 <endogenic> aiui
18:57:58 <endogenic> but that doesnt actually cover all output cases aiui
18:58:07 <endogenic> i've been trying to write this up, but some pretty terrible things have happened to me recently so I've been delayed
18:58:23 <endogenic> I've had a fully working version of this for a couple years, but like I said, some pretty terrible things have happened
18:59:00 <endogenic> 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.
18:59:07 <endogenic> if people are interested, then I'll place this into a proposal
18:59:28 <endogenic> I think we can probably eliminate get unspent outs and definitely can remove get addr info
19:03:17 <Cindy> vtnerd: that's what i wanted, the ability to differeniate between spent and unspent outputs
19:03:36 <Cindy> without carrot, as it's not coming out for at least a few years
19:04:47 <m-relay> <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
19:05:07 <Cindy> ah i see
19:06:23 <Cindy> that's fair, i don't know what other way to display the correct balance in a fully transparent way
19:06:29 <Cindy> without giving the user a chance to spend the outputs
19:16:58 <m-relay> <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.
19:18:41 <Cindy> well.. i was overestimating :P
19:18:50 <Cindy> just in case