<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.

* 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.

* 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.

* 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.

hyc: Perhaps open a new issue on Monero Research Lab Github?

Will get more visibility in that case

Direct statement of Kraken's CEO

" in the UK until the regulator better understands its value or feels like they have better surveillance tools."

it's time for us to start circulating rumors that ciphertrace actually works

dEBRUYNE: the wallet thing doesn't seem like much of a research topic to me

pretty straightforward development, no groundbreaking tech involved

Perhaps an issue on the Monero repository will suit better then?

Just want to make sure no one forgets about it in a few weeks and it gets implemented actually

ah right, since there's already an issue in m2049r's repo

ok

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.

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

hyc: ty

I dumped out my ideas there. whoever wants to pick it up can fill in the blanks ;)

"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

.merges

.merge+ 8083 8084 8065

Added

seeing that the fast sync checkpoints for v0.17.3.0 are already one month old I'll update them again

<hyc> "I dumped out my ideas there..." <- escapethe3ra:

.merge+ 8085

Added

can someone review this? monero-project/monero #8085

luigi1111: merges today? :)

maybe :)

hello, quick question, how do you guys generate wallets ? with the rpc, with a library, with a wallet generator ?

Also luigi1111 it's very cool to be snooping trough your git and seeing you here.

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.

MyMonero uses 25 word seed.

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

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

no, but its something that I would look to at again

what is the most pressing thing, attempting to get it merged into monero-project/lws ?

or some other feature

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

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

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

exactly, would be nice but it's effectively leaking info to Google/Apple each time

which reminds me, the most important update is probably the efficient pull/poll change that ndorf has proposed for the API

checking in once an hour or so seems reasonable enough. certainly miles better than today

in that a poll only retrieves new txes instead of blasting the entire list back each time

would a wallet provide a most recently-checked block height in that request?

yes basically the wallet provides a height+hash and the server then filters the response

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

I personally view mempool support as a nice to have, not essential

thats probably the most annoying usability issue for people checking their phones when someone jsut sent them funds

most people aren't going to be connected to the nodes in those exact moment s

yeah, in an ideal case we could just push a mempool notification without downsides

I would bet ~90% of Cake Wallet users would choose that convenient option over a periodic refresh

is there a github issue somewhere that tracks the to-dos for this? I recall there being one but I can't find it

github.com/vtnerd/monero-lws/issues

there is none specific to what was discused here, or a general purpose checklist

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?

fake out selection you mean? the "real outs" are selected by the wallet itself and not lws

sgp_: if you have a light wallet, presumably it doesn’t know anything about the ledger so it can’t assemble rings

sgp_ @sgp_:monero.social: I believe jberman is also working on subaddress support for lws.. another v important feature

UkoeHB vtnerd when a wallet uses a remote node currently (not lws), does it rely on the node in entirety for decoy selection?

I'm trying to think about why lws vs remote would be materially different for decoy selection

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

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)

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

iirc, I would have to refactor that function (very slightly) to integrate better

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?

ok I see, yes the decoy selection can be pushed into the wallet with lws just being a pass-through for the rpc

lws is currently just adhering to the historical API at this point

okay

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

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

I suspect that array could be quantized for early blocks with little effect on the distribution.

ie, instead of sending blocks 0, 1, 2, 3, 4, send the sum of those.

Though coinbases might be a bit of a problem here...

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?

its been 5 hours btw

luigi1111w: ok so CLI + GUI merges today and tag tomorrow if now issues show up

no*

<WhiteFox[m]> "Hey, can anyone help me? I..." <- This is a dev discussion channel- please ask your question in the #monero:monero.social channel

<crypto_grampy[m]> "This is a dev discussion channel..." <- how does this even happen

anyways, anything to add to the meeting agenda for sunday?

selsta will be late tonight

WhiteFox[m]: monero.stackexchange.com/questions/…nsaction-to-in-the-gui-zero-balance

90% of problems seem to be "cant see balance" with the anser being "fully synced? set restore height lowe"

s/anser/answer/

s/anser/answer/, s/lowe/lower/

thanks boys trying to do so now. have a nice evening all

<hyc> "I dumped out my ideas there..." <- Posted a report for more visibility: monero.observer/libwallet-viewkey-b…ment-reduce-wallet-sync-time-bounty

Let me know if it needs any edits. I will update as it develops.

hyc: I'd rather take the discussion from 8082 here since it's largely off-topic for the issue anyway

which is probably my fault for bringing up there at all, though they are approaches to address a similar problem

I could have sworn Seth opened an issue a while back on the lws remote node scanning but I can't find it

sgp the fact that you haven't yet suggested anything to mitigate the security concerns is disturbing.

at any rate, since lws implementation already exists, sure, it can probably be integrated pretty quickly

hyc: it's me deciding to put the view key on my own node

that doesn't tell me at all that you've considered the security issues

hyc: Can you elaborate on this? the giving up your view key issue?

the point is that monerod is a *server* that will wind up accepting connections from *anywhere*

any of which could be malicious

we don't believe monerod has any vulnerabilities, but we can never be 100% certain

meanwhile the wallet is a *client* that never has to accept connections from anyone else

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

so it has a nearly zero attack surface overthe network

I mean, nodes can be locked down somewhat

monerobull[m]: sure. but I will keep pressing the issue until it has been fully discussed.

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

are we talking about the background scanning?

there are ways to mitigate node risks: harden the node

yeah different approaches to background scanning

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

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.

But I would love to have this other solution in monero GUI today

and configure monerod to only accept connections that have the client cert.

monerod already supports TLS and password logins, no?

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

yes that support already exists

well, most Cake users also have Facebook (and who knows what else) on their phones so, none of these situations are ideal

cross-process exploits are tough without root access

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

taking that lws approach is not a decision to be made lightly.

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

it's not a default or anything, it's an optional feature

polling once/hour is prob not a big deal

and even the lws approach will require the wallet to poll the server

so constant connectivity isn't really an issue

staying constantly connected is generally a bad idea on a phone. it prevents the phone from putting its radio into powersave mode

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

Lws becomes more valuable as tx numbers go up imo

yeah. as long as the usage model changes to "always run your own node"

which doesn't work for a lot of people whose home network is double-NAT'd by their ISP

enter i2p 😎 😏

again, other downsides, sure

yes, I think i2p will be a big help

connecting to a monero node through double-NAT gives me immense joy

just need to automate generating a server address and feeding it to the client

* through double-NAT with i2p gives me

lol.... was gonna say ...

haha

but i2p tunnel establishment is slow

so again, we're talking about instantaneous sync/usability

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

btw, since I was asked: the cachefile created by a viewkey-only wallet is totally interchangeable with the cachefile created by a full wallet

I just tried it out a few minutes ago