05:42:58 "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 * 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 * 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 * 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 hyc: Perhaps open a new issue on Monero Research Lab Github? 07:46:12 Will get more visibility in that case 07:59:50 https://www.reddit.com/r/Monero/comments/r1bm7b/binance_detects_abnormal_activities_after_xmr/hm4pluw/ 07:59:55 Direct statement of Kraken's CEO 08:36:57 " in the UK until the regulator better understands its value or feels like they have better surveillance tools." 08:37:10 it's time for us to start circulating rumors that ciphertrace actually works 08:38:01 dEBRUYNE: the wallet thing doesn't seem like much of a research topic to me 08:38:21 pretty straightforward development, no groundbreaking tech involved 08:40:47 Perhaps an issue on the Monero repository will suit better then? 08:40:57 Just want to make sure no one forgets about it in a few weeks and it gets implemented actually 08:42:24 ah right, since there's already an issue in m2049r's repo 08:42:25 ok 08:43:33 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 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 hyc: ty 08:55:19 https://github.com/monero-project/monero/issues/8082 08:55:42 I dumped out my ideas there. whoever wants to pick it up can fill in the blanks ;) 13:59:45 "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 .merges 17:00:24 -xmr-pr- 8055 8056 8070 8071 8072 8075 17:09:38 .merge+ 8083 8084 8065 17:09:38 Added 17:13:18 seeing that the fast sync checkpoints for v0.17.3.0 are already one month old I'll update them again 17:16:04 "I dumped out my ideas there..." <- escapethe3ra: 18:12:08 .merge+ 8085 18:12:09 Added 18:12:17 can someone review this? https://github.com/monero-project/monero/pull/8085 18:12:51 luigi1111: merges today? :) 18:17:58 maybe :) 18:19:10 hello, quick question, how do you guys generate wallets ? with the rpc, with a library, with a wallet generator ? 18:19:48 Also luigi1111 it's very cool to be snooping trough your git and seeing you here. 18:22:57 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 MyMonero uses 25 word seed. 20:00:26 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 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 no, but its something that I would look to at again 20:02:10 what is the most pressing thing, attempting to get it merged into monero-project/lws ? 20:02:14 or some other feature 20:04:10 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 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 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 exactly, would be nice but it's effectively leaking info to Google/Apple each time 20:07:07 which reminds me, the most important update is probably the efficient pull/poll change that ndorf has proposed for the API 20:07:19 checking in once an hour or so seems reasonable enough. certainly miles better than today 20:07:32 in that a poll only retrieves new txes instead of blasting the entire list back each time 20:08:11 would a wallet provide a most recently-checked block height in that request? 20:09:07 yes basically the wallet provides a height+hash and the server then filters the response 20:09:57 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 I personally view mempool support as a nice to have, not essential 20:10:40 thats probably the most annoying usability issue for people checking their phones when someone jsut sent them funds 20:10:51 most people aren't going to be connected to the nodes in those exact moment s 20:11:11 yeah, in an ideal case we could just push a mempool notification without downsides 20:11:59 I would bet ~90% of Cake Wallet users would choose that convenient option over a periodic refresh 20:12:54 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 github.com/vtnerd/monero-lws/issues 20:16:07 there is none specific to what was discused here, or a general purpose checklist 20:18:56 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 fake out selection you mean? the "real outs" are selected by the wallet itself and not lws 20:29:47 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 sgp_ @sgp_:monero.social: I believe jberman is also working on subaddress support for lws.. another v important feature 20:38:25 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 I'm trying to think about why lws vs remote would be materially different for decoy selection 20:40:38 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 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 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 iirc, I would have to refactor that function (very slightly) to integrate better 20:43:14 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 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 lws is currently just adhering to the historical API at this point 20:45:03 okay 20:45:13 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 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 I suspect that array could be quantized for early blocks with little effect on the distribution. 20:47:50 ie, instead of sending blocks 0, 1, 2, 3, 4, send the sum of those. 20:48:42 Though coinbases might be a bit of a problem here... 21:45:39 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 its been 5 hours btw 21:52:34 luigi1111w: ok so CLI + GUI merges today and tag tomorrow if now issues show up 21:52:39 no* 22:15:04 "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 "This is a dev discussion channel..." <- how does this even happen 22:31:46 anyways, anything to add to the meeting agenda for sunday? 22:43:20 selsta will be late tonight 22:44:29 WhiteFox[m]: https://monero.stackexchange.com/questions/6640/i-am-missing-not-seeing-a-transaction-to-in-the-gui-zero-balance 22:48:43 90% of problems seem to be "cant see balance" with the anser being "fully synced? set restore height lowe" 22:48:58 s/anser/answer/ 22:49:05 s/anser/answer/, s/lowe/lower/ 22:49:30 thanks boys trying to do so now. have a nice evening all 22:57:40 "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 Let me know if it needs any edits. I will update as it develops. 23:03:02 hyc: I'd rather take the discussion from 8082 here since it's largely off-topic for the issue anyway 23:03:26 which is probably my fault for bringing up there at all, though they are approaches to address a similar problem 23:03:55 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 sgp the fact that you haven't yet suggested anything to mitigate the security concerns is disturbing. 23:06:35 at any rate, since lws implementation already exists, sure, it can probably be integrated pretty quickly 23:06:45 hyc: it's me deciding to put the view key on my own node 23:07:34 that doesn't tell me at all that you've considered the security issues 23:08:01 hyc: Can you elaborate on this? the giving up your view key issue? 23:08:24 the point is that monerod is a *server* that will wind up accepting connections from *anywhere* 23:08:32 any of which could be malicious 23:08:47 we don't believe monerod has any vulnerabilities, but we can never be 100% certain 23:09:02 meanwhile the wallet is a *client* that never has to accept connections from anyone else 23:09:12 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 so it has a nearly zero attack surface overthe network 23:09:22 I mean, nodes can be locked down somewhat 23:09:57 monerobull[m]: sure. but I will keep pressing the issue until it has been fully discussed. 23:10:10 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 are we talking about the background scanning? 23:10:55 there are ways to mitigate node risks: harden the node 23:11:05 yeah different approaches to background scanning 23:12:22 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 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 But I would love to have this other solution in monero GUI today 23:13:56 and configure monerod to only accept connections that have the client cert. 23:14:40 monerod already supports TLS and password logins, no? 23:14:49 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 yes that support already exists 23:15:56 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 cross-process exploits are tough without root access 23:18:42 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 taking that lws approach is not a decision to be made lightly. 23:20:04 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 it's not a default or anything, it's an optional feature 23:20:56 polling once/hour is prob not a big deal 23:21:29 and even the lws approach will require the wallet to poll the server 23:21:51 so constant connectivity isn't really an issue 23:22:24 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 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 Lws becomes more valuable as tx numbers go up imo 23:23:14 yeah. as long as the usage model changes to "always run your own node" 23:23:40 which doesn't work for a lot of people whose home network is double-NAT'd by their ISP 23:23:58 enter i2p 😎 😏 23:24:14 again, other downsides, sure 23:24:40 yes, I think i2p will be a big help 23:25:01 connecting to a monero node through double-NAT gives me immense joy 23:25:07 just need to automate generating a server address and feeding it to the client 23:25:18 * through double-NAT with i2p gives me 23:25:33 lol.... was gonna say ... 23:26:01 haha 23:26:04 but i2p tunnel establishment is slow 23:26:25 so again, we're talking about instantaneous sync/usability 23:32:28 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 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 I just tried it out a few minutes ago