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