15:40:25 <roooooocc[m]> Hi, I want to use sub-addresses to keep track of transactions for orders, how much ram usage do they use, or how do they slow performance?
15:41:33 <moneromooo> ~80 bytes per subaddress, negligible performance impact when scanning, but a bit of a hit when generating them to begin with.
15:42:29 <moneromooo> You may want to tune the lookahead to match your shop's behaviour.
15:43:16 <cryptogrampy[m]> I.e. if you generate subaddress at index 10,000,000 for an order, you need to make sure you're wallet is actually watching up to that index
15:43:19 <moneromooo> And prevent people from causing you to generate millions of subaddresses (ie, if you have a trivial way to say "I'm a new customer" that can be script-spammed..
15:43:55 <cryptogrampy[m]> ***laughs in payment id
15:44:18 <roooooocc[m]> cryptogrampy[m]: is it watched automatically? I
15:44:45 <roooooocc[m]> * automatically? I'd rather have cronjobs manually track orders, and delete them from the db if they aren't being paid
15:46:16 <moneromooo> It's watching up to the lookahead. If you generate an address normally, it'll always be watched [1].
15:46:47 <moneromooo> [1] assuming the wallet is saved after generating the address: if it crashes after that, it won't remember it needs to watch.
15:48:16 <selenze[m]> can we say a wallet is cable of scanning from multiple points of the BLK...I kind of imagine to be able like an octupus?!
15:50:37 <roooooocc[m]> moneromooo: So, is there any way I can generate the address, and only check it manually, let's say every 5 minutes and maybe even remove it after some time?
15:52:05 <moneromooo> Yes. Find the right RPC.
15:52:22 <moneromooo> Except for removing. There is no removal RPC.
15:52:44 <moneromooo> However, the thrust of your question makes me think what you want is not that, but instead deleting a mapping in your shop DB.
15:53:23 <moneromooo> If your orders are timed, then you may decide to map subaddres to order in your DB, and genrate a new subaddress if you don't have any left available.
15:53:40 <moneromooo> Then an order times out, delete the mapping in your DB, so the subaddress is available for reuse.
15:53:53 <moneromooo> However, if hte customer pays late, you have to decide what to do.
15:54:09 <moneromooo> So reuse should be after a fairly long delay.
15:54:13 <moneromooo> Or never reuse.
15:54:29 <moneromooo> But reuse is the same as deleting really.
15:54:53 <moneromooo> (ie, someone who pays after a timeout gets to deal with you manmually to work out what to do with the monero)
15:56:38 <cryptogrampy[m]> <roooooocc[m]> "So, is there any way I can..." <- I'd recommend taking a look at MoneroPay's implementation: https://github.com/moneropay/moneropay
16:07:11 * roooooocc[m] uploaded an image: (102KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/OGYnZPCEqHlmhywyZGOzpYsG/image.png >
16:07:24 <roooooocc[m]> I'm not sure there's anything like that in moneropay, it seems to create an address and "rollback" if there's a problem
16:10:35 <roooooocc[m]> <moneromooo> "Yes. Find the right RPC." <- I'm not sure there is one that generates an address but doesn't make it be "watched"
16:10:35 <roooooocc[m]> Thanks for the rest of the explaination, I figured it out already though, but it's almost exactly like you said
16:11:52 <roooooocc[m]> create_address seems to be the only method for subaddress, which would be perfect, except it being "watched" automatically
16:13:53 <moneromooo> It will watch it. But you can ask the wallet manually.
16:14:27 <moneromooo> I suppose you can create one outwith the lookahead, then close the wallet without saving. Not super useful though.
16:15:15 <moneromooo> I think you're asking the wrong question.
16:16:08 <roooooocc[m]> Actually wait, is this "watching" being done automatically? If not, I could just getbalance with address_indices set to my subaddress, right?
16:16:28 <moneromooo> Yes and yes, resp.
16:17:18 <moneromooo> Well, you can turn auto refresh off and refresh manually. The "watching" will be done when you refresh manually then. And you can call getbalance and other RPC when you want for those subaddresses.
16:18:18 <woodser[m]> when `unlock_time` returns a unix timestamp instead of block height, what does that timestamp represent? expected unlock date/time instead of height?
16:21:49 <moneromooo> A UNIX timestamp in unlock_time represents an unlock time, yes :P Seconds since the epoch as usual. It's necessarily be "fuzzy" as it depends on the node's time, but any rejection will be short lived.
16:28:04 <roooooocc[m]> <moneromooo> "Well, you can turn auto refresh..." <- There is no option to "refresh" only for some subaddresses, right?
16:28:04 <roooooocc[m]> Also, how do I turn off the automatic refresh then?
16:32:37 <moneromooo> There is no option to scan just some subaddresses. Not sure why you'd want that. Let me go look at the RPC list for you for hte second question..
16:32:56 <moneromooo> "auto_refresh"
16:33:00 <moneromooo> The well named.
16:33:32 <moneromooo> (then call "refresh" manually)
16:33:47 <roooooocc[m]> moneromooo: 🤦‍♂️oh yeah
16:35:16 <moneromooo> Your questions suggest you might be assuming scanning is done once per subaddress. If so, this is not the case. It is done once, for all subaddressses you have. There is no loop (hence the negligible performace impact).
16:35:59 <roooooocc[m]> moneromooo: Oh I understand, then subaddresses wouldn't have a performance impact besides ram anyway?
16:36:30 <moneromooo> Yes, negligible means that, pretty much.
16:37:08 <roooooocc[m]> Awesome, you're right I was thinking about how it works wrong, thanks!
16:37:08 <roooooocc[m]> So one more question, I've searched in the rpc docs, there's no way to delete subaddresses, right?
16:37:30 <moneromooo> I said negligible rather than none since there's a hash table lookup and technically that's like log2(num_subaddresses) lightweight operations somewhere.
16:37:39 <moneromooo> Yes, as I said above.
16:37:53 <roooooocc[m]> Okay, thank you so much
16:38:57 <moneromooo> Subaddresses are deterministic. If you'd regen (x,y) after deleting it (if you could), you'd get the same subaddress.
16:40:07 <roooooocc[m]> When an invoice is unpaid for 24 hours, I delete it.
16:40:07 <roooooocc[m]> Would it be a good idea to just store unused subaddresses and just reuse them?
16:40:07 <roooooocc[m]> Or have a cycle of let's say 1000, make sure there aren't ever more orders that this at the same time, and just reuse them?
16:42:11 <moneromooo> It seems easier not to reuse, but it depends on want you want really.
16:42:35 <moneromooo> Not reusing makes it easy to know who paid late if you want to refund them.
16:43:05 <moneromooo> If you reuse, then receive an address on that address, there's always a possibility the sender is the orignal custoer who had timed out.
16:43:31 <moneromooo> If you say "if you send after the timeout, thanks for the monero", then reusing it fine.
16:44:27 <moneromooo> Note that a timeout can be due to tx relay failing due to a temp network issue, and the tx would be auto re-sent after 4 hours IIRC. So it's quite plausible to be done in good faith.
16:45:40 <roooooocc[m]> moneromooo: I mean I'm providing VPS (and some other digital items), and after 30 days reusing doesn't sound bad since the buyer used all of their time, there shouldn't be a reason for refunds
16:45:40 <roooooocc[m]> But your points are good, I'll spend some more time of thinking about this myself (I want to release the source code when it's done anyway so anyone could change how it works tbh)
16:46:09 <roooooocc[m]> Thanks again for everything
16:46:38 <tevador> With Seraphis, "subaddresses" will work like a payment id without the privacy drawbacks. No lookahead needed.
16:48:17 <roooooocc[m]> tevador: So when in the future if it gets implemented, creating even millions of addresses would still be fine?
16:50:08 <tevador> Yes. Up to 2^128 if your database can handle it.
16:51:08 <roooooocc[m]> Awesome, then implementing it with a new subaddy like a transaction id seems the way to go, it is much simpler, thanks to both of you so much
17:39:03 <selsta> .merge+ 8547 8548
17:39:04 <xmr-pr> Added
18:15:16 <stretch1> @devs, is it worth it setting up a strong nym to hide the person behind to guard from state despotism & co ?
18:15:16 <stretch1> do you have weak nyms behind a simple vpn, not even changing the mail for github signup etc etc; 
18:15:16 <stretch1> can someone experienced put light on this please?
19:23:09 <hyc> sounds lie it's up to you and your risk tolerance
19:23:30 <hyc> but sure, prob a good idea
19:28:28 <hyc> when I worked on RTMPdump, a couple contributors signed their stuff with a hexadecimal hash. presumably of their name or email address, i have no idea.
19:30:04 <hyc> I would suggest taking that into consideration here too, if you care about provencance or ownership. some way of asserting your identity without revealing it, in case you ever need to prove ownership.
22:03:02 <baro77[m]> Hi again everybody! Wanting to check which protocol version we have reached, I checked /src/hardforks/hardforks.cpp ...why just one day of version 13 and 15 ?
22:10:50 <merope> it's a double hardfork
22:11:25 <merope> first one enables the new transaction format, the second one (720 blocks/24h later) disables the old format
22:12:28 <merope> this gives a "grace period" to any transactions that were still in the mempool at the time of the hardfork, to spare users from having to resubmit them after the fork (and possibly reveal their true spend, if they don't pick the same ring members)
22:13:03 <baro77[m]> uh! clever! Got it, thanks endor00