04:22:49 <duso> Thanks, I will have a look at it. Most people have an old smart phone laying around, it needs to be a dedicated POS app that integrates with other peoples phones so they can just 'paywave' over the device for payments.
04:24:33 <duso> hook up to the stores wifi, and use NFC to detect the customers wallet up open on the phone to exchange amount and payment address then customer just fingerprint or pin approves the transaction
04:31:20 <duso> another nice to have feature would be trusted transactions. I know this goes against privacy and anomynity kinda but a vendor and client could agree to a trust, in which the vendors device remember the customers device and approve the transfer after only 1 block (2 minutes). Or a customer could have an 'account' on the vendors device so regular small deductions like from a coffee shop could be deducted.
04:32:49 <duso> if the transaction fails, next time the customer returns to the vendor it remembers and deducts the new and old in a full transaction
05:01:36 <MoMo> Hey guys!
05:02:22 <MoMo> What do you think a I7 - 920 CPU would hash?
05:04:22 <MoMo> Or a Gigabyte ga EX58 ud3r CPU,  seems like they are too old to put in the calculators, anyone with a educated guess?
05:24:10 <niocbrrrrrr> MoMo the i7 maybe 1800 H/s at most which currently gets you about .0016 xmr/day
05:26:35 <niocbrrrrrr> how much less than that it will actually get I have no idea
07:38:08 <endor00[m]> <duso "another nice to have feature wou"> That could be done by simply adding some sort of device id that gets sent via nfc when the customer makes the payment. Not included in the transaction data, but simply as a separate string that gets sent over in parallel from the customer to the seller.
08:42:04 <goldmine_compact> when moon?
08:46:15 <d4ndo[m]> https://www.timeanddate.com/moon/phases/
08:50:41 <ErCiccione[m]> 21st of june, apparently
09:22:30 <miu5> Hello, i want to use Monero GUI with tor or i2p, can i do that by using the daemon startup flags?
12:08:24 <endor00[m]> Do you want to connect the wallet to the daemon through tor/i2p, or do you want the daemon to talk to the rest of the network through tor/i2p?
12:17:57 <miu5> endor00[m], not sure what you mean in the first part of your sentence. The wallet GUI starts up the daemon, but what i want is to connect (obviously the daemon) to the tor/i2p network.  But since the GUI starts up the daemon, will putting the commands in the "daemon startup flags" in the GUI work?
12:19:20 <dEBRUYNE> Easier to run it separately
14:07:52 <yanmaani> Is there any library for doing monero stuff? Like keeping accounts with balances and handling deposits and so on, interfacing with monerod?
14:08:38 <moneromooo> There is "monero integrations", high level interface between monero and... PHP I think ?
14:09:00 <yanmaani> ugh php
14:09:02 <moneromooo> Otherwise, various libs, see https://github.com/monero-ecosystem
14:09:50 <moneromooo> There is a python layer above RPC (and strictly RPC only) in the monero tree too, but that's low level.
14:10:08 <moneromooo> Some higher level python lib from the above link IIRC.
14:10:49 <yanmaani> the c++ lib sounds interesting. Does this scale well?
14:11:02 <yanmaani> Can I create a wallet upon a request with captcha and be safe?
14:11:20 <moneromooo> No idea. Ask whoever made it :)
14:13:46 <yanmaani> it seems to bind wallet2.h in monero
14:13:57 <yanmaani> If I make say a million accounts in monero, will it cause problems?
14:14:32 <moneromooo> Probably. IIRC 200 subaddresses per account by default, 80 bytes per subaddress.
14:14:41 <moneromooo> You can tune the 200 down though.
14:14:45 <yanmaani> so 80 mb?
14:14:55 <moneromooo> More than that.
14:15:04 <yanmaani> If I want to create a service where I can take deposits in XMR and someone spams it so it makes a million addresses, will I have a problem?
14:15:21 <yanmaani> 80 B * 1,000,000 = 80 MB
14:15:21 <moneromooo> 14 GB ? :)
14:15:34 <moneromooo> Ah, if you set accounts to one subaddress per, yes.
14:15:42 <yanmaani> Oh, I mean a million subaddresses.
14:15:51 <moneromooo> Ah. Then yes, 80 MB only.
14:15:52 <yanmaani> btw what's the difference? Is it just like derive paths?
14:16:01 <yanmaani> Will it cause horrible lag when scanning the chain?
14:16:04 <yanmaani> is it O(n)?
14:16:14 <moneromooo> Mostly O(1).
14:16:49 <moneromooo> There is no real difference between subaddress and account, it's just how they're interpreted by the wallet.
14:17:36 <yanmaani> so havign a million subaddr is fine?
14:17:42 <moneromooo> Should be.
14:18:10 <moneromooo> Might be slow to load/save the wallet I guess, since it will load/save all those addresses.
14:18:29 <yanmaani> if it'll be on a server (on 24/7), will it be a problem?
14:18:37 <yanmaani> how do the big boys like xmr.to do it? binaryFate
14:18:44 <moneromooo> Should not be, but you can try it easily.
14:19:14 <yanmaani> are there any security tradeoffs to pruned nodes?
14:19:53 <moneromooo> A pruned now can only serve an eigth of the chain to peers. So it decreases the overall "connectedness" of the chain a bit.
14:20:17 <yanmaani> monero can have watch-only wallets but it won't show balance accurately, right?
14:20:25 <moneromooo> For the local user, you can't access the pruned data if you want to look at it, but otherwise it's verified normally when synced.
14:20:47 <moneromooo> It will show accurate balance, assuming you correctly imported outputs/key images.
14:21:07 <yanmaani> Assuming I didn't?
14:21:13 <moneromooo> GIGO.
14:21:20 <yanmaani> Will I still see inputs?
14:21:38 <yanmaani> If I need to credit accounts but not support withdrawals, can I just not send them?
14:21:42 <moneromooo> You will see any incoming outputs.
14:22:08 <moneromooo> If you only receive and never spend, it will show a correct balance without having to do import/export.
14:22:25 <yanmaani> if I do spend, will the in amounts still be correct?
14:22:34 <moneromooo> Once you export/import.
14:22:41 <moneromooo> er
14:22:50 <yanmaani> if I don't export, will I see wrong incoming amounts?
14:22:50 <moneromooo> The *in* amounts will be correct always, yes.
14:23:05 <moneromooo> But you won't be able to see when some are spent.
14:23:10 <yanmaani> that's fine
14:23:56 <moneromooo> To be clear, and since this is of general interest:
14:24:21 <Mochi101> I have a read only wallet.... I haven't done the export/import... I can only WISH that I had that much Monero. :(
14:24:43 <yanmaani> Oh wait, will it cause problems with the change addresses?
14:24:58 <Mochi101> It just shows you the wrong balance.
14:25:12 <moneromooo> If Alice has a wallet, and makes a watch only wallet, and that watch only wallet is set with correct key images, and if Bob steals stuff from that wallet, Alice's watch only wallet *will* see the theft, without her having to re-import.
14:25:32 <yanmaani> is key images a one-time thing?
14:25:33 <moneromooo> Just mentioning this since it seems it's a big use case for watch only.
14:25:44 <moneromooo> It's for every time you receive a new output.
14:25:54 <yanmaani> so each utxo gets one?
14:25:57 <moneromooo> (if you want to know when they're spent)
14:26:11 <moneromooo> Every output gets one, yes, and yo need the secret spend key to calculate it.
14:26:21 <yanmaani> yeah OK that's fine. But if I have some XMR and I spend it, and it goes back to my change, will it randomly credit stuff?
14:26:25 <Mochi101> I use it for the MoneroIntegrations Worpress plugin. So I can see when people buy stuff from me in XMR.
14:27:02 <moneromooo> Only if the change goes to a subaddress set up for a client. By default change goes to subaddress 0, which will likely not be set up for a client.
14:27:24 <yanmaani> ok, so I'll need to make sure that subaddr 0 is not a change addr. good to know
14:27:47 <moneromooo> I am about 90% sure change goes to subaddress 0.
14:27:56 <yanmaani> is not a client addr*
14:28:08 <moneromooo> I have a doubt here. Is anyone sure of it ? :)
14:28:31 <Mochi101> I never watched for this.
14:28:33 <Mochi101> Hmmm
15:49:35 <binaryFate> <yanmaani> how do the big boys like xmr.to do it? binaryFate <--- no black magic required, just common backup practices. I would advise to record the index you last generated, so you have ground truth to work with if everything else crashes
15:51:28 <yanmaani> But you use something like subaddresses and a SQL database?
15:54:53 <Mochi101> binaryFate, does Minko just create 5 sub-addresses for each new user?
15:58:25 <binaryFate> yanmaani you asked about subaddresses, I answer about subaddresses :) SQL is unrelated
15:58:48 <binaryFate> Mochi101 yes afair
15:59:53 <yanmaani> The index you last generated will only help you recover your money, correct?
16:00:30 <Mochi101> I think on-chain stuff is really the best binaryFate. Now, when I see a gaming site where you have to create an account, I'm really turned off by it.
16:01:12 <binaryFate> yanmaani: you can never lose money as long as you don't lose seeds. The last generated will help you get back on track and have your service running again at the point you stopped
16:01:37 <yanmaani> Well, you can never lose *your* money, but you can lose your users' money
16:01:50 <binaryFate> No, you can just fail to "see" it
16:03:21 <Mochi101> That's why I hope we never lose integrated addresses.
16:03:34 <Mochi101> Never have to really worry about that binaryFate
16:04:53 <binaryFate> IMO it's not a major worry. Doesn't justify not using subaddresses just by itself
16:04:53 <Mochi101> but with sub-addresses if you want to provide a unique address for every tx you have to remember which you used last.
16:05:35 <Mochi101> Then if you change wallets... how do you handle that in your db if you store index number?
16:05:58 <binaryFate> Well (i) the wallet does that for you with convenient API calls and (ii) you can save the index you last generated and get back exactly to the same state by yourself if you wish so, at any point
16:06:25 <Mochi101> I know the wallet takes care of that for you.
16:06:32 <binaryFate> Subaddresses are very similar to Bitcoin HD wallets from the service perspective
16:07:32 <yanmaani> Surely not the same state?
16:07:33 <knaccc> you have to remember which you used last < if you have multiple servers and don't want to sync a global last-issued-subaddress between them, you just have a different account for the wallet for each server
16:07:45 <yanmaani> You still need idx <-> bitcoin addr mappings?
16:07:58 <Mochi101> But what if you for some reason need to store index number in your database... and then you rotate your wallet or something... then you'll have a couple of entries with the same index number
16:08:40 <binaryFate> Why would you record index number in your DB and not the specific subaddress?
16:08:48 <Mochi101> Whereas with an integrated address I just store the payment ID
16:08:58 <Mochi101> save space?
16:09:13 <binaryFate> Your customers should have a subaddress associated, not an index. The global index is just a way for you to recover wallet operation quickly if need be.
16:09:29 <yanmaani> you mean like the privkey?? that seems insane
16:10:14 <binaryFate> No, just the subaddress you give to them. Then you check incoming transactions, if it's to their subaddress it's for them.
16:10:28 <binaryFate> That's what every exchanges and services do.
16:10:35 <binaryFate> Same with BTC addresses
16:10:38 <yanmaani> Oh, so you discard the info on how to derive it
16:10:44 <yanmaani> hmm, yeah that makes sense
16:11:00 <binaryFate> all you need to derive it is the seed :)
16:11:23 <yanmaani> yeah I guess you don't need the specific way to derive that addr
16:11:41 <binaryFate> and remember that your last subaddress is, say, 2 millions something. Then re-create wallet, create 2 miliions something subaddresses and you're good to go again
16:12:05 <yanmaani> modulo those where you got the payment in but didn't send out.
16:12:11 <Mochi101> or just give some random payment id
16:12:25 <Mochi101> and not have to worry about create new addresses at all
16:13:27 <selsta> Don’t they get created automatically because of the subaddress lookahead?
16:13:42 <Mochi101> binaryFate, have you seen monero.win?
16:13:45 <binaryFate> <yanmaani> modulo those where you got the payment in but didn't send out. <-- I don't think it has anything to do with it? Or maybe I don't know what you want to do besides detecting payments
16:14:25 <yanmaani> binaryFate: If your server crashes to the point of losing all your database, then users' blanaces will be toast too
16:14:33 <yanmaani> on xmr.to, txns currently in flight will be gone
16:14:53 <binaryFate> selsta: they are unless you have a sufficiently long streak without incoming payments. Say you onboard 1000 customers who don't deposit anything, then your wallet will not by itself generate the addresses for customers 1001 and so on
16:15:03 <Mochi101> If I was using su-addresses and someone just made a script that "created a game ticket" and then never actually played it... I could be at 10 million sub addresses in no time.
16:15:19 <binaryFate> <yanmaani> on xmr.to, txns currently in flight will be gone <--- mmm no
16:15:26 <selsta> binaryFate: right but you could increase the lookahead
16:15:42 <Mochi101> but with payment IDs I can go and flush my db of created game tickets
16:15:47 <yanmaani> binaryFate: If your entire database dies except for the last ID info, txns awaiting confirms to send out XBT will never send
16:16:03 <binaryFate> selsta: yep indeed. It's just easy good practice to record the last index you generated. A single integer, makes life easier
16:16:10 <selsta> sure
16:16:24 <yanmaani> Mochi101: it's just gambling?
16:16:32 <Mochi101> just
16:16:46 <yanmaani> yes, what's the point
16:16:48 <moneromooo> Better than unjust gambling.
16:16:51 <binaryFate> yanmaani: I'm confused. If the DB dies, service can't work that's expected.
16:17:00 <yanmaani> yeah, so why save the last ID then?
16:17:07 <yanmaani> If the DB dies you're SOL anyway, right?
16:17:27 <Mochi101> yanmaani, you're talking to me?
16:17:32 <yanmaani> Mochi101: about gambling
16:17:35 <yanmaani> yes, what's the point
16:17:40 <yanmaani> is it your site?
16:17:45 <Mochi101> yes
16:17:54 <yanmaani> if you have a gambling license why not do something fun?
16:17:58 <yanmaani> like a prediction market on elections
16:18:15 <Mochi101> betmoose already does that
16:18:26 <Mochi101> I wanted something that did on chain for Monero.
16:18:38 <Mochi101> Fair... easy to prove that it's fair.
16:18:44 <yanmaani> no, betmoose has a garbage market structure
16:18:51 <yanmaani> > Please understand that it's your own responsibility to gamble responsibly - if you think you need help please click here.
16:18:56 <yanmaani> this link just goes to the frontpage dude
16:19:01 <binaryFate> I don't know how you intend to run your service, but generally it should be impossible that "your DB dies". You have regular backups etc. Anyway it still makes a difference. If you lose your DB entirely, and the last subaddress index used, generating the wallet from seed might not show the entire balance and you don't know how many subaddress to generate see everything again
16:19:07 <Mochi101> yeap yanmaani
16:19:14 <Mochi101> Personal responsibility
16:20:00 <yanmaani> binaryFate: That's my point: it should be impossible that "your DB dies". So why ever do this? It doesn't help you recover your customers' money, just your own. I guess it's better than nothing tho
16:20:18 <yanmaani> something here tells me that your site is not 100% compliant mochi
16:20:27 <binaryFate> I don't know what you mean by your money vs. your customers money
16:20:30 <Mochi101> Compliant to what?
16:20:35 <yanmaani> the law
16:20:41 <Mochi101> Which law?
16:20:47 <yanmaani> gambling laws
16:20:57 <Mochi101> For where though?
16:21:18 <yanmaani> binaryFate: If your DB totally collapses, then you will have no way of telling apart which customer had what money. So you can't give them their due, only take it for yourself.
16:21:29 <yanmaani> Mochi101: Your country of residence if it's not incorporated
16:21:45 <Mochi101> oh ok
16:21:59 <yanmaani> generally speaking there are laws, depends onw here you live though
16:22:11 <yanmaani> if you're from Costa Rica, there's no law as long as you block local IPs for example
16:22:24 <binaryFate> you're describing something service specific. I'm only giving you a general advise to save that one single integer of subaddress index. Just don't if you don't see the benefits