05:42:58 <Elijah[m]> <hyc> "would be nice to have a way to..." <- There's this thing called keyring. Theoretically, the wallet can be decrypted upon logging in. The only downside is that other programs could also theoretically retrieve the password from keyring. I think it's a good feature for a desktop wallet, if I were to implement one. If a program can maliciously retrieve the keyring, then it could've key logged you either way. 
05:43:27 <Elijah[m]> * There's this thing called keyring. Theoretically, the wallet can be decrypted upon opening the Gui without user input. The only downside is that other programs could also theoretically retrieve the password from keyring. I think it's a good feature for a desktop wallet, if I were to implement one. If a program can maliciously retrieve the keyring, then it could've key logged you either way. 
05:43:41 <Elijah[m]> * There's this thing called keyring. Theoretically, the wallet can be decrypted upon opening the Gui without user input, if the user is logged in. The only downside is that other programs could also theoretically retrieve the password from keyring. I think it's a good feature for a desktop wallet, if I were to implement one. If a program can maliciously retrieve the keyring, then it could've key logged you either way. 
05:43:55 <Elijah[m]> * There's this thing called keyring. Theoretically, the wallet can be decrypted upon opening the Gui without user input, if the user is logged into their computer. The only downside is that other programs could also theoretically retrieve the password from keyring. I think it's a good feature for a desktop wallet, if I were to implement one. If a program can maliciously retrieve the keyring, then it could've key logged you either way. 
07:46:05 <dEBRUYNE> hyc: Perhaps open a new issue on Monero Research Lab Github?
07:46:12 <dEBRUYNE> Will get more visibility in that case
07:59:50 <dEBRUYNE> https://www.reddit.com/r/Monero/comments/r1bm7b/binance_detects_abnormal_activities_after_xmr/hm4pluw/
07:59:55 <dEBRUYNE> Direct statement of Kraken's CEO
08:36:57 <hyc> " in the UK until the regulator better understands its value or feels like they have better surveillance tools."
08:37:10 <hyc> it's time for us to start circulating rumors that ciphertrace actually works
08:38:01 <hyc> dEBRUYNE: the wallet thing doesn't seem like much of a research topic to me
08:38:21 <hyc> pretty straightforward development, no groundbreaking tech involved
08:40:47 <dEBRUYNE> Perhaps an issue on the Monero repository will suit better then?
08:40:57 <dEBRUYNE> Just want to make sure no one forgets about it in a few weeks and it gets implemented actually
08:42:24 <hyc> ah right, since there's already an issue in m2049r's repo
08:42:25 <hyc> ok
08:43:33 <hyc> Elijah[m]: yeah, the notion of a keyring works for some dektop environments. not necessarily all. and I don't think it does anything for mobile.
08:44:00 <hyc> I think it's better to build the feature I described so it is entirely self-contained in the monero code base and works uniformly across all platforms
08:46:56 <dEBRUYNE> hyc: ty
08:55:19 <hyc> https://github.com/monero-project/monero/issues/8082
08:55:42 <hyc> I dumped out my ideas there. whoever wants to pick it up can fill in the blanks ;)
13:59:45 <john_r365> "The point is to allow the wallet to stay sync'd with the blockchain without leaving the private spendkey exposed or leaving the main wallet cache in decrypted state." <- love the concept hyc
17:00:24 <selsta> .merges
17:00:24 -xmr-pr- 8055 8056 8070 8071 8072 8075
17:09:38 <selsta> .merge+ 8083 8084 8065
17:09:38 <xmr-pr> Added
17:13:18 <selsta> seeing that the fast sync checkpoints for v0.17.3.0 are already one month old I'll update them again
17:16:04 <crypto_grampy[m]> <hyc> "I dumped out my ideas there..." <- escapethe3ra: 
18:12:08 <selsta> .merge+ 8085
18:12:09 <xmr-pr> Added
18:12:17 <selsta> can someone review this? https://github.com/monero-project/monero/pull/8085
18:12:51 <selsta> luigi1111: merges today? :)
18:17:58 <luigi1111> maybe :)
18:19:10 <IanNiculescu[m]> hello, quick question, how do you guys generate wallets ? with the rpc, with a library, with a wallet generator ?
18:19:48 <IanNiculescu[m]> Also luigi1111 it's very cool to be snooping trough your git and seeing you here.
18:22:57 <moneromooo> They should all be compatible, except possibly mymonero and feather wallet, which may be using differnt seed schemes. I *think* mymonero does not use a different scheme anymore, but not 100% sure. Feather has a new scheme, it's also optional AFAIK.
18:24:24 <selsta> MyMonero uses 25 word seed.
20:00:26 <sgp_> vtnerd: have you been able to work on the monero-lws work recently? The vision of allowing a remote node store view keys and scan wallets there instead of on the wallet side is a really strong vision imo
20:01:31 <sgp_> it's far more efficient to scan on the node side and check in with the wallet periodically instead of scanning on the wallet side
20:01:54 <vtnerd> no, but its something that I would look to at again
20:02:10 <vtnerd> what is the most pressing thing, attempting to get it merged into monero-project/lws ?
20:02:14 <vtnerd> or some other feature
20:04:10 <sgp_> You will have a better idea of the most pressing steps to get here, but I'm envisioning Cake Wallet and other wallets allowing the sharing of view keys with remote nodes. So the whole processes of securely receiving the view key, scanning locally 24/7, and communicating updates with the wallet
20:04:45 <sgp_> I think it would make more sense to just have the wallet connect to the remote node periodically instead of the remote node reaching out to the wallet every time a transaction comes in for example
20:06:06 <vtnerd> yeah the pull vs push issue - the difficulty with push is that the most efficient method is to use the phones built-in OS routines, but in android and iOS those go through google and apple servers respectively iirc
20:06:53 <sgp_> exactly, would be nice but it's effectively leaking info to Google/Apple each time
20:07:07 <vtnerd> which reminds me, the most important update is probably the efficient pull/poll change that ndorf has proposed for the API
20:07:19 <sgp_> checking in once an hour or so seems reasonable enough. certainly miles better than today
20:07:32 <vtnerd> in that a poll only retrieves new txes instead of blasting the entire list back each time
20:08:11 <sgp_> would a wallet provide a most recently-checked block height in that request?
20:09:07 <vtnerd> yes basically the wallet provides a height+hash and the server then filters the response
20:09:57 <vtnerd> the other big change I need to add is mempool support, which I've avoided simply because its a pain since it differs from chain scanning slightly
20:10:26 <sgp_> I personally view mempool support as a nice to have, not essential
20:10:40 <vtnerd> thats probably the most annoying usability issue for people checking their phones when someone jsut sent them funds
20:10:51 <sgp_> most people aren't going to be connected to the nodes in those exact moment s
20:11:11 <sgp_> yeah, in an ideal case we could just push a mempool notification without downsides
20:11:59 <sgp_> I would bet ~90% of Cake Wallet users would choose that convenient option over a periodic refresh
20:12:54 <sgp_> is there a github issue somewhere that tracks the to-dos for this? I recall there being one but I can't find it
20:15:52 <vtnerd> github.com/vtnerd/monero-lws/issues
20:16:07 <vtnerd> there is none specific to what was discused here, or a general purpose checklist
20:18:56 <sgp_> why does -lws have a different selection algo than the core monero wallet? How is the process different for a wallet sending txs via lws compared to sending txs via a remote node?
20:28:31 <vtnerd> fake out selection you mean? the "real outs" are selected by the wallet itself and not lws
20:29:47 <UkoeHB> sgp_: if you have a light wallet, presumably it doesn’t know anything about the ledger so it can’t assemble rings
20:33:31 <crypto_grampy[m]> sgp_ @sgp_:monero.social:  I believe jberman is also working on subaddress support for lws.. another v important feature
20:38:25 <sgp_> UkoeHB vtnerd when a wallet uses a remote node currently (not lws), does it rely on the node in entirety for decoy selection?
20:38:59 <sgp_> I'm trying to think about why lws vs remote would be materially different for decoy selection
20:40:38 <vtnerd> no, the wallet asks the remote node for the number of outputs-per-block (returned in an array), selects the decoys, then asks the remote node for public keys for the decoys+real outs (the real out isn't leaked in that rpc call
20:41:43 <vtnerd> lws doesn't use the exact code the standard wallet uses because the code is mostly wrapped in `wallet2` which tries to manage all keys (so it cannot be used for lws)
20:42:42 <vtnerd> there's since been some refactoring where it may be possible to leverage the expoential selection portion specifically, Id have to look to see if that portion is reusable
20:43:13 <vtnerd> iirc, I would have to refactor that function (very slightly) to integrate better
20:43:14 <sgp_> why can't wallets ask the same information from lws that they currently ask of remote nodes, so that they can perform the same process in both cases? Does that make sense?
20:44:13 <vtnerd> ok I see, yes the decoy selection can be pushed into the wallet with lws just being a pass-through for the rpc
20:44:34 <vtnerd> lws is currently just adhering to the historical API at this point
20:45:03 <sgp_> okay
20:45:13 <vtnerd> the only negative is the array returned to the client is quite large, and its typically easier for the server to work with, but it should be doable if coded correclty
20:45:49 <sgp_> In my mind I'm just trying to keep everything consistent so we don't (even accidentally) have 3 different selection algos for the same wallet depending on what nodes they use :p
20:47:29 <moneromooo> I suspect that array could be quantized for early blocks with little effect on the distribution.
20:47:50 <moneromooo> ie, instead of sending blocks 0, 1, 2, 3, 4, send the sum of those.
20:48:42 <moneromooo> Though coinbases might be a bit of a problem here...
21:45:39 <WhiteFox[m]> Hey, can anyone help me? I sent XMR from binance to my new monera wallet. The payment was completed (shows in binance 3/3 steps of the payment are completed). The xmr is not in my wallet. I tried to restore my xmr back through binance when it does not reach its destination. But it is rejected, it says that xmr has to be in my wallet and if its not it's not their problem but the wallet itself. What should I do? 
21:49:04 <WhiteFox[m]> its been 5 hours btw
21:52:34 <selsta> luigi1111w: ok so CLI + GUI merges today and tag tomorrow if now issues show up
21:52:39 <selsta> no*
22:15:04 <crypto_grampy[m]> <WhiteFox[m]> "Hey, can anyone help me? I..." <- This is a dev discussion channel- please ask your question in the #monero:monero.social channel
22:30:17 <monerobull[m]> <crypto_grampy[m]> "This is a dev discussion channel..." <- how does this even happen
22:31:46 <monerobull[m]> anyways, anything to add to the meeting agenda for sunday?
22:43:20 <luigi1111> selsta will be late tonight
22:44:29 <dEBRUYNE> WhiteFox[m]: https://monero.stackexchange.com/questions/6640/i-am-missing-not-seeing-a-transaction-to-in-the-gui-zero-balance
22:48:43 <monerobull[m]> 90% of problems seem to be "cant see balance" with the anser being "fully synced? set restore height lowe"
22:48:58 <monerobull[m]> s/anser/answer/
22:49:05 <monerobull[m]> s/anser/answer/, s/lowe/lower/
22:49:30 <WhiteFox[m]> thanks boys trying to do so now. have a nice evening all
22:57:40 <escapethe3ra[m]> <hyc> "I dumped out my ideas there..." <- Posted a report for more visibility: https://www.monero.observer/libwallet-viewkey-based-background-refresh-enhancement-reduce-wallet-sync-time-bounty/
22:58:03 <escapethe3ra[m]> Let me know if it needs any edits. I will update as it develops.
23:03:02 <sgp_> hyc: I'd rather take the discussion from 8082 here since it's largely off-topic for the issue anyway
23:03:26 <sgp_> which is probably my fault for bringing up there at all, though they are approaches to address a similar problem
23:03:55 <sgp_> I could have sworn Seth opened an issue a while back on the lws remote node scanning but I can't find it
23:05:27 <hyc> sgp the fact that you haven't yet suggested anything to mitigate the security concerns is disturbing.
23:06:35 <hyc> at any rate, since lws implementation already exists, sure, it can probably be integrated pretty quickly
23:06:45 <sgp_> hyc: it's me deciding to put the view key on my own node
23:07:34 <hyc> that doesn't tell me at all that you've considered the security issues
23:08:01 <crypto_grampy[m]> hyc: Can you elaborate on this?  the giving up your view key issue?
23:08:24 <hyc> the point is that monerod is a *server* that  will wind up accepting connections from *anywhere*
23:08:32 <hyc> any of which could be malicious
23:08:47 <hyc> we don't believe monerod has any vulnerabilities, but we can never be 100% certain
23:09:02 <hyc> meanwhile the wallet is a *client* that never has to accept connections from anyone else
23:09:12 <monerobull[m]> hyc: now i could have no idea what im talking about but for all i know, sgp isnt a dev and i wouldnt expect him to have as deep of knowledge on nodes as you have
23:09:13 <hyc> so it has a nearly zero attack surface overthe network
23:09:22 <sgp_> I mean, nodes can be locked down somewhat
23:09:57 <hyc> monerobull[m]: sure. but I will keep pressing the issue until it has been fully discussed.
23:10:10 <sgp_> none of the solutions are ideal if there's a hot view key in any situation, whether on one's node or running on one's phone that probably has facebook installed in most people's cases, lol
23:10:48 <monerobull[m]> are we talking about the background scanning?
23:10:55 <sgp_> there are ways to mitigate node risks: harden the node
23:11:05 <sgp_> yeah different approaches to background scanning
23:12:22 <crypto_grampy[m]> I do think monero-lws is a good long term solution and coupled with a nice UI in monero GUI could lead to more people running their own nodes/connecting to those nodes over Tor/i2p with MyMonero style wallets
23:13:43 <hyc> the only approach I can see to limit attack surface is to use TLS on the rpc port with an explicitly created client & server TLS cert.
23:13:53 <crypto_grampy[m]> But I would love to have this other solution in monero GUI today
23:13:56 <hyc> and configure monerod to only accept connections that have the client cert.
23:14:40 <sgp_> monerod already supports TLS and password logins, no?
23:14:49 <hyc> and that might be good enough. but if you didn't know enough to suggest it yourself sgp, then I doubt most users will know enough to protect themselves
23:15:45 <hyc> yes that support already exists
23:15:56 <sgp_> well, most Cake users also have Facebook (and who knows what else) on their phones so, none of these situations are ideal
23:16:26 <hyc> cross-process exploits are tough without root access
23:18:42 <hyc> also there's some indication that the current tls support is buggy, since it's often suggested to disable it when people have connection issues
23:19:51 <hyc> taking that lws approach is not a decision to be made lightly.
23:20:04 <sgp_> I want to see both of these ideas implemented fwiw. I don't personally want to have my phone constantly receiving blocks and scanning with my CPU if I can avoid it personally
23:20:20 <sgp_> it's not a default or anything, it's an optional feature
23:20:56 <hyc> polling once/hour is prob not a big deal
23:21:29 <hyc> and even the lws approach will require the wallet to poll the server
23:21:51 <hyc> so constant connectivity isn't really an issue
23:22:24 <hyc> staying constantly connected is generally a bad idea on a phone. it prevents the phone from putting its radio into powersave mode
23:22:37 <sgp_> lws has the option (which has other downsides) of pushing updates to the phone, and the workload is lighter if the scanning is on the server side
23:22:43 <crypto_grampy[m]> Lws becomes more valuable as tx numbers go up imo
23:23:14 <hyc> yeah. as long as the usage model changes to "always run your own node"
23:23:40 <hyc> which doesn't work for a lot of people whose home network is double-NAT'd by their ISP
23:23:58 <sgp_> enter i2p 😎 😏
23:24:14 <sgp_> again, other downsides, sure
23:24:40 <hyc> yes, I think i2p will be a big help
23:25:01 <sgp_> connecting to a monero node through double-NAT gives me immense joy
23:25:07 <hyc> just need to automate generating a server address and feeding it to the client
23:25:18 <sgp_> * through double-NAT with i2p gives me
23:25:33 <hyc> lol.... was gonna say ...
23:26:01 <sgp_> haha
23:26:04 <hyc> but i2p tunnel establishment is slow
23:26:25 <hyc> so again, we're talking about instantaneous sync/usability
23:32:28 <sgp_> I like all of these ideas because user experience is super important to me. I've been thinking of maybe adding an optional weekly push notification in cake as a reminder to open/sync, but hopefully it doesn't come to that
23:39:22 <hyc> btw, since I was asked: the cachefile created by a viewkey-only wallet is totally interchangeable with the cachefile created by a full wallet
23:39:31 <hyc> I just tried it out a few minutes ago