02:51:27 <LucasSoares[m]> good night i would like to know how i am part of monero i used google translator i am brazilian help me my country is in shit a lot of misery
02:55:35 <LucasSoares[m]> please someone
02:56:36 <sethforprivacy> Wrong channel, Lucas Soares,, but feel free to join #monero instead!
02:57:37 <LucasSoares[m]> how am i part
03:03:43 * LucasSoares[m] uploaded an image: (43KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/QNTYciakwmpJNhrZNaMgAOCE/216428908_1821864024650399_5149314823520407419_n.jpg >
03:04:21 <LucasSoares[m]> I need to give the little one a better life
04:22:25 <Steven_M> Hi all, I have 3 feature suggestions, should I talk about them here or submit them somewhere else (eg the Monero Subreddit)?
05:50:07 <Steven_M> Hi all, I have 3 feature suggestions, should I talk about them here or submit them somewhere else (eg the Monero Subreddit)?
08:04:39 <moneromooo> File a request on github.
08:06:07 <moneromooo> Assuming it's well formed enough. Otherwise, you can talk about it in #monero too.
09:42:18 <Steven_M> moneromooo: Thanks, will do.
14:07:17 <Siren[m]> Since subaddresses are stored in the wallet file and some merchants depend on it, wouldn't it make sense to have a way of forgetting a subaddresses?
14:13:09 <Siren[m]> <Siren[m]> "Since subaddresses are stored in..." <- If we have a bunch of subaddresses that we no longer use, afaik our only option currently is restoring the wallet from seed
14:13:51 <Siren[m]> It would be very convenient to have another way of ignoring/removing these addresses from the wallet file without having to restore
14:15:41 <moneromooo> Why would you want that ?
14:16:25 <Siren[m]> Aren't integrated addresses getting deprecated?
14:16:49 <wernervasquez[m]> Siren: Can you describe the use case in very general terms? Is this an issue that has affected you?
14:17:09 <Siren[m]> There are some payment gateways/processors that generate new subaddresses per invoice/transaction
14:17:19 <moneromooo> Some people would like to deprecate integrated addresses. It's not clear whether they're going to be.
14:17:57 <Siren[m]> In theory shouldn't it be a problem if someone were to abuse this feature and generate a bunch of subaddresses?
14:19:01 <moneromooo> Ah, you mean if a merchant lets a user request a new address repeatedly ?
14:19:04 <Siren[m]> Some wallet rpc methods seem to loop over subaddresses
14:19:10 <Siren[m]> moneromooo: Yes
14:19:25 <moneromooo> Yes, if they allow that indefinitely, it could become annoying.
14:20:21 <Siren[m]> Is it possible to have a wallet rpc method in the future to forget these addresses?
14:20:38 <Siren[m]> Maybe forget isn't the right term here, I hope the point gets through
14:20:46 <moneromooo> Yes. Not sure it'd be a good idea though.
14:21:06 <moneromooo> Just don't allow a user to make you generate them.
14:21:33 <moneromooo> Forgetting sounds like papering over the cracks of the problem in the first place.
14:21:48 <Siren[m]> Right, it's more of a responsibility of the higher level application
14:22:30 <wernervasquez[m]> moneromooo: Was there a conversation about encoding the address index in jamtis somehow so that a payment reciever would know what address it went to without a lookup table?
14:22:59 <Siren[m]> I think for this to occur naturally without abuse is unlikely
14:23:07 <moneromooo> What could be useful maybe is a "did this address ever receive anything" flag. Then a merchant can allow a new address iff the current address received something.
14:23:19 <Siren[m]> spirobel
14:23:27 <moneromooo> Though there's not really much point in generating a new address. We're not bitcoin, that's the point.
14:23:46 <moneromooo> wernervasquez[m]: I do not know.
14:26:15 <Siren[m]> moneromooo: This could be implemented by an higher level application as well. Stnby what do you think?
14:26:24 <Siren[m]> I think we should do this
14:27:18 <Siren[m]> Allocate a certain amount of time for the transfer to be made, in case we don't receive anything after the time has passed we should reuse that address
14:28:16 <moneromooo> I think the flag I mentioned is already there, in a way: check transfers, whether spent or not, and their address, which I think is available. Might be slow though.
14:29:02 <moneromooo> Then again, is there a good reason to give a user power to generate a new address ?
14:29:13 <moneromooo> If you can find a good reason, adding such a flag may be of use.
14:29:45 <moneromooo> (if checking for transfers is too slow)
14:31:34 <Stnby[m]> Siren[m]: That wouldn't work, we cant wait to see if we can reuse the subaddress because if 5 clients come at the same time we have to generate 5 subaddresses no matter what
14:31:56 <Stnby[m]> We can't just put clients on hold for 4 minutes or so
14:32:37 <Siren[m]> Stnby[m]: We can ignore the last ever created subaddress and look for previous ones
14:32:43 <Siren[m]> Shouldn't block? No?
14:32:54 <Stnby[m]> The question is when we create a bunch of subaddresses aren't they all stored in runtime memory?
14:32:59 <Siren[m]> s/block/blockfor too long/
14:33:09 <Siren[m]> * Shouldn't block for too long? No?
14:34:03 <Siren[m]> I think they are
14:34:35 <Stnby[m]> So what do we do with them after a successful payment for a service?
14:34:57 <moneromooo> Subaddresses are in RAM. They do not *need* to be though, but moving them to storage would take some change in the way the wallet scans.
14:35:27 <Stnby[m]> How do we remove them from cache as we no longer care if someone actually sends something on that long forgotten subaddresses
14:35:38 <moneromooo> ie, scan 1e5 txes, generate their subaddresses, then stream your local subaddress store looking for them.
14:35:39 <Siren[m]> Stnby[m]: I don't see how it can be a privacy issue to reuse those but some people did not like the idea of it
14:36:48 <Stnby[m]> If we had a feature to get rid of them from cache it would be a perfect solution in my opinion
14:37:07 <Siren[m]> I think the best way would be that, yes
14:42:27 <spirobel[m]> <Siren[m]> "I don't see how it can be a..." <- if you read the original PR you can see that recycling subaddresses would defeat their purpose: https://github.com/monero-project/monero/pull/2056 just use integrated addresses and forget about this whole mess. Subadddresses are not the right tool for this kind of merchant usecase. xmr.to also used integrated addresses for this reason:
14:42:27 <spirobel[m]> https://www.reddit.com/r/Monero/comments/9aevri/comment/e4vf47p/?utm_source=share&utm_medium=web2x&context=3
14:43:10 <Siren[m]> spirobel[m]: We are not using subaddresses for the sake of anonymity and privacy
14:43:27 <Siren[m]> Neither the 99% of the merchants out there do
14:44:15 <spirobel[m]> Siren[m]: you use them because somebody said that integrated addresses might be deprecated for unclear reasons?
14:44:24 <Siren[m]> Why would you care about your subaddresses being linked to your applications?
14:44:27 <binaryFate> Actually xmr.to moved to subaddress only later on, it did the job perfectly
14:44:57 <Stnby[m]> spirobel[m]: Reasons are, having a Payment ID is a waste of space on everyone Hard Drive
14:45:05 <Siren[m]> spirobel[m]: I will not explain that to you a fourth time
14:45:07 <Stnby[m]> Because su addresses exist
14:45:29 <Stnby[m]> * Because subaddresses exist
14:45:30 <Stnby[m]> * Reasons are, having a Payment ID is a waste of space on everyone's Hard Drive
14:49:26 <spirobel[m]> binaryFate: yeah xmr.to might not be the best example for this. I think where it really makes a difference is when it comes to non custodial marketplaces. 
14:50:10 <moneromooo> I can see a use case for this: generate a subaddress on every page load, for accountless things. But in this case I think the high level code should remember what's "used", as it seems fairly dependent on what you're doing.
14:51:09 <moneromooo> And you'd need to make it clear to the clients that there'd be a timeout for using such an address.
14:52:14 <moneromooo> Maybe the ability to set a "used/unused" flag in the monero wallet to support this might be useful. Unclear.
14:52:51 <moneromooo> What you'd do if an old customer sends to an address that'd been reused though, that'd be entirely up to the merchant, nothing monero can do there.
14:53:28 <Siren[m]> Sounds like it's not the merchant's responsibility
14:53:43 <Siren[m]> As it's not logical for an old customer to do that
14:54:06 <moneromooo> People do non logical things. You gotta expect it :)
14:54:24 <Siren[m]> Accept it as a donation :)
14:54:58 <moneromooo> As long as it's clear at the outset, that's a perfectly acceptable solution.
14:55:14 <moneromooo> But you have to ebsure it doesn't monkey with the new user's usage too.
14:55:18 <moneromooo> ensure*
14:55:47 <Siren[m]> We will be implementing the "used/unused" flag in our high level application, shouldn't be too hard since we already keep track of the total amount received and the amount we expected.
14:55:50 <Siren[m]> Thanks
14:56:44 <spirobel[m]> the question is if it is worth to go through all of this. I dont think this issue is as bad if you used integrated addresses. 
14:57:19 <Siren[m]> We have to do little work to get a flag like that to work for us
14:57:56 <Siren[m]> Integrated addresses are risky to implement currently and would require us to rewrite the polling part of our application
14:58:28 <Siren[m]> When there's a clear decision to keep them or to deprecate them, then we might consider it
15:05:51 <wernervasquez[m]> Siren: If a customer requests a new subaddress, but hasnt used the last one given to them, do you / would you give them the same address, or generate a new one?
15:06:31 <Siren[m]> The way how things are currently, we are generating new addresses
15:06:43 <Siren[m]> We haven't experienced anything negative related to this
15:14:37 <UkoeHB> Jamtis allows you to generate addressed randomly. There is no subaddress lookup table.
15:26:07 <plowsof[m]> btc/bch wallets (electrum/electron) create payment requests ( a sub address which is considered 'used' for x minutes ) . generating a new sub address there is 'getting an un-used address' - and after x minutes without payment, its marked as being unused again. They have a look-ahead value (sometimes 20) where - if 20 consecutive addresses are found with 0 balance it will stop searching and consider the wallet synced which is why they care
15:26:08 <plowsof[m]> so much about re-using addresses. 
15:26:08 <plowsof[m]> Personally, i consider the customer/donators experience more than the merchants so i generate unique addresses each time and just handle it on the back end.
15:26:08 <plowsof[m]> The problem of customers spamming 'create new address' requests to your website == ddos  , so i just try to mitigate that - e.g. 1 ip can request 20 per day . max 1 per second (ip database deleted every 24 hours) 
15:29:48 <binaryFate> note it's easy to generate millions of addresses in advance, or on a different server than where your wallet for the webservice is running. Then you don't need to hit wallet-rpc with an address creation request each time, you just grab the next one from those you've saved to your DB
15:35:19 <plowsof[m]> Perfect solution ^ for scaling / anti ddos binaryFate, (ill have to implement that myself) probably useful for customers also - to verify that the address theyve been given belongs to the merchant also (if there was some front end where they can input it to access that pre-generated DB - or the merchant provides the address  + index 
15:45:34 <spirobel[m]> <binaryFate> "note it's easy to generate..." <- seems clunky but okay. 🙂
16:10:36 <Halver[m]> <Siren[m]> "Is it possible to have a..." <- Each time there is a new wanabee customer, my merchant website proposes him a (new) subaddress (SA).
16:10:42 <Halver[m]> However this SA is only removed from being proposed when it is really used, ie it gets a real payment.
16:11:21 <Halver[m]> Notice also that, from the merchant side, quite everything can be done using SA indexes.
16:12:53 <Halver[m]> <moneromooo> "What could be useful maybe is a..." <- That's exactly what I'm doing.
16:15:18 -xmr-pr- tobtoht opened pull request #8169: rpc: add explicit restricted flag to /get_info
16:15:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8169
17:24:48 <jeffro256[m]> Hey what is the general sentiment around adding docstrings in the code, specifically in src/cryptonote_basic?
17:56:44 <moneromooo> Do you mean... comments ? If so, if the comments are good, they're a good thing. If they're bad, they're a bad thing.
17:58:57 <jeffro256[m]> Do yall have a certain format for the comments that you try to adhere to?
18:00:59 <moneromooo> Well, /* */ for C, for C++ typically // but /* */ also works. The important part is the content, which should be useful.
18:03:05 <moneromooo> As a general rule, we tend to recommend using the style of the code you're changing, if that helps.
18:03:35 <moneromooo> Of course, some code you might want to modify might be horrendous enough that a new style could be warranted :D
18:04:48 <moneromooo> The following is a personal preference, but I really hate huge comment walls that prevent me from reading the code. Be succint. Don't write pointless stuff that anyone with a clue can infer from reading the code. It just wastes space.
18:05:53 <moneromooo> Useless shite like: uint64_t amount; // the amount
18:05:55 <moneromooo> is useless.
18:06:53 <moneromooo> Useful comments like void foo(uint64_t amount) /* if 0, the amount was not set and we use a default value */ is useful.
18:08:10 <moneromooo> Apologies if this is all obvious, but it's not to everyone and I don't know you :)
18:08:24 <moneromooo> In general, adding useful comments would be good.