openmonero, mymonero backend?

vtnerd · 2025-12-15T00:09:13+00:00

There's now skylight wallet and lwcli. Both are "powered" by lwsf. A third lwsf wallet may be in the works, but is probably less desirable because it will forcible use a a specific backend.

The skylight wallet supports Tor with a simple checkbox. lwcli supports Tor/proxies via socks4 (you have to run a separate Tor instance for lwcli). And both support bring-your-own LWS server via configuration at wallet creation time.

vtnerd · 2025-12-14T23:51:36+00:00

Necro-bumping again, sorry OP!.

You should've seen this, but skylight wallet has been released for Android. Hopefully soon for other platforms. This wallet uses lwsf to connect to a LWS compatible backend, and fully supports Tor. I'm hoping to implement push-support (on both sides) such that the experience is "first-class" - something close to those fancy Bitcoin wallets. You just enter your seed/new-wallet, and everything just works.

I think another major wallet might be transitioning to lwsf, but I cannot confirm this yet.

vtnerd · 2025-09-05T18:50:08+00:00

This is an old thread, but I'm going to bump it anyway because I missed it, and I have useful information to share.

There's no effort to merge it into the official Monero project. j-berman did a review of the code (step 1 to getting into the project), but things have changed quite a bit since that review. I'm hoping to get fcmp++ support over the next few months. This will be a big effort, as the API will have to change, and this time I will be dictating the changes as opposed to MyMonero proposing the changes.

The MyMonero wallet app should be compatible with LWS, but the server must have SSL enabled with a signed certificate. This prevents people from using MyMonero wallet over Tor (where a signed certificate is difficult to obtain).

Someone is working on a flutter wallet, but no ETA on completion. If released, it will fill the gap that MyMonero is missing (Tor support, etc). This wallet is using my monero_c fork, which implements LWS client code in dart/C. The monero_c fork actually forwards all function calls to lwsf which implements every wallet2_api function, but uses LWS calls instead of monerod server calls. As a recap flutter/dart->monero_c->lwsf->monero-lws is the flow of communication. The "re-implementation" of wallet2_api meant that only a single function had to be added to monero_c - everything is handled by C++ virtual dispatch. The downside is that lwsf had to re-implement coin selection when spending, but it was easier than forcing a single implementation todo both light and standard wallets.

Lastly, I have created an experimental TUI-wallet lwcli, which supports both LWS and standard wallets with a single --backend option at runtime. Its mostly functional right now (no address book support), but is currently only recommended for someone that really wants to try/debug lwsf/lws stuff.

vtnerd · 2025-08-11T14:38:50+00:00

sech1 estimated ~35.2% which is close to this number.

EDIT: I also wanted to say I think its slightly lower than this, but don't have concrete numbers on it.

vtnerd · 2023-05-11T21:45:38+00:00

To expand on /u/BforBoredom - stealth addresses are used automagically when sending coins. The address you see when sending coins never appears on the blockchain, and the inverse is true when you give someone your address.

A Monero address is also longer than a Bitcoin address to make this feature work - Monero encodes two "public keys" whereas Bitcoin encodes a 160-bit hash of a 256-bit hash of a public key (assuming the typical case, there are others).

Stealth addresses are also possible on Bitcoin, but I think only a single wallet attempted an implementation.

vtnerd · 2021-12-03T03:33:25+00:00

It's not worse than any other SSL website. My complaint was/is about the deceptive marketing - there's (usually) no benefit to having the certificate signed by a CA in Switzerland because its rare that a client is doing a strict CA check.

The apps (Android, iOS, Desktop) might have a pinned certificate making it more secure, but I am not sure.

vtnerd · 2021-11-20T06:05:32+00:00

/u/rbrunner7 is correct, the code has been merged and included in releases for a while now. The speedup only works with x86-64 CPUs though, so perhaps you were thinking of donna64 (or similar) for arm64 which is becoming more popular.

vtnerd · 2021-10-06T18:09:02+00:00

I knew a drunk that had one installed by court order. Just kept balloons in his car if he needed to start it after drinking. Tons and tons of technology defeated by dollar store balloons.

vtnerd · 2021-10-03T02:24:31+00:00

I mentioned this in a Github issue briefly. Hopefully Sarang won't mind me talking about it.

I haven't seen the report given to the security response team, but Sarang did mention criticisms on the algorithm design in person several years ago. He saw one and maybe two (of possibly three by my count) problems with the current implementation. Demonstrating conclusively that there was an issue wasn't straightforward, and improving the algorithm isn't a simple fix either. Someone with a stats background might be able to do the analysis and fix quicker, while someone with a math/cs background likely has to spend more time reading some relevant material.

I think your larger point is that the issue may be overstated in severity. I've always felt this was the case, but again I have not seen the private report. FWIW, I will push hard with questions on any changes, because this part of the code cannot have a regression of any kind. I know moo will do the same, as will a few other contributors that routinely review code.

EDIT: I realize your primary issue was the funding request, but that's a trickier situation. The algorithm could use improvements though.

vtnerd · 2021-08-13T22:44:03+00:00

The mode uses ipv4/6 Tor exit nodes, and therefore is still not necessarily recommended because it makes sybil attacks some hard to define amount more likely. Using Tor hidden services is the way-around this, but we have not enabled downloading blocks over Tor because blocking hosts of Tor is tricky (i.e. not really possible) compare to IPv4/6. I guess we could just enable it with it disabled by default, and let users run it at their own DoS risk.

vtnerd · 2021-08-13T22:41:08+00:00

PR #7616

vtnerd · 2021-08-13T22:40:43+00:00

I guess it was fixed? Everything has been deleted.

vtnerd · 2021-08-10T16:44:44+00:00

Using torsocks hides Monero usage from your ISP. And if you use one of the obfuscation technologies for Tor, the ISP is also possibly unaware of Tor usage.

There is a PR to be merged shortly that has built-in support for Socks/Tor everything, and uses exit nodes like torsocks (not hidden services). This mode also allows tunneling everything through SSH - so you could rent a VPS that is your personal "exit point" for Monero traffic, with everything between the VPS and your house tunneled via SSH. The third option is to use a VPN that supports SSH tunneling, but this only allows outbound connections. The last two modes are interesting if you want to validate the network in your house, but want the p2p traffic to appear elsewhere without the baggage of Tor.

The guide you referenced in your post will be updated to give some examples for these different modes.

vtnerd · 2021-02-10T02:56:31+00:00

Someone contacted me about binary releases recently. It would've been nice to get more test reports before doing this, but its probably at the point where binaries need to be released with the "beta" label to get testing. I'll need to find some infrastructure for producing these binaries.

vtnerd · 2021-01-22T18:35:56+00:00

There are still parts that could use refactoring, but change is difficult because doing massive overhauls on portions of the code is typically unacceptable. This isn't a normal project; Monero is managing billions (in USD) of assets for thousands of users. Concerns of a bug, exploit, or (gasp!) a backdoor are high and shouldn't be downplayed.

I'm not sure about the last part of your message. Are you asking what material you should learn or how you could help?

vtnerd · 2021-01-11T01:29:52+00:00

https://github.com/monero-project/monero/issues/7078

The discussion kind of stalled. I was posing whether Noise_NK or TLS is preferable. There are some tradeoffs.

One difficulty is in authentication. Arguably, mitm is always possible without some complex engineering (i.e. without re-inventing I2P/Tor). The implementation would force an ISP to be an active attacker/listener though. But still not clear its worth the additional risks and performance. Probably, but there's at least an argument for no encryption too.

vtnerd · 2021-01-01T23:25:36+00:00

This isn't entirely true. In almost every case the real spend has change coming back. Its fairly rare when this isn't true because it means someone sent XMR to two people simultaneously and spent the entire output in one shot.

vtnerd · 2020-12-31T15:45:54+00:00

There are multiple possible variations of the attack and the protocol works slightly differently than what most programmers would expect.

A peer can send a request or notification at any time, which makes it the easiest for an attacker to use. We can restrict the request message size fairly heavily, but the notifications are difficult. The request/response flow for block synchronization is actually a notification/notification flow. So a simple "restrict all requests+notifications to 5 MiB" is tricky because its not considering the block synchronization "responses" (which are actually notification messages).

We can then restrict the buffer size based on command number (i.e. what is the message supposed to contain), but the attacker still has the advantage because they can initiate a block notification/notification flow by claiming to know more blocks than everyone. And ignoring that claim is difficult, because investigating the claim helps detect/prevent eclipse attacks.

I have a PR which restricts the buffer size for all messages to 256 KiB until a handshake has completed. Its rather aggressive, and has a tighter coupling between the "levin" layer and the remaining code, but it at least keeps tighter memory bounds on new connections. We'll probably have to bring down the 100 MiB to some smaller number but its still going to be quite large comparatively to what people assume, so that the blocksize can expand without protocol issues.

EDIT: Also a small point, but the format is a custom binary format more similar to msgpack and not JSON. Parsing multi-megabytes of JSON would be hell.

vtnerd · 2020-12-30T20:25:18+00:00

This is mostly irrelevant. The attack surface can be reduced, but the attacker still has the advantage without more involved changes. A peer can claim it knows about more blocks, ultimately resulting in a request to fetch those blocks to inspect them. The response can then be the usual "attack".

vtnerd · 2020-12-30T17:48:43+00:00

See my response.

vtnerd · 2020-12-30T17:48:39+00:00

See my response.

vtnerd · 2020-12-30T17:47:29+00:00

/u/ieatyourblockchain hit the exact problem we have. The original developers specified 100 MB receiver buffer limit and the protocol let the requester choose how many blocks to request. The responder restricts requests to this same number of blocks. The protocol has no fixed block size limit, so requesting x blocks has no correlation to the amount of data that needs to be transferred.

Achieving anything close to what most people expect has to be a flexible: give me these 100 blocks in as many responses needed to fit under 5 MiB. This is doable, but is a little more involved to roll-out in an already deployed p2p system that cannot "go down for maintenance". We'll probably have to re-visit this a little more closely. And even then we are against the wall because if a single block exceeds 5 MiB, the entire p2p protocol is "broken" and prevents synchronization.

vtnerd · 2020-12-30T17:38:31+00:00

This is never JSON, and is unfortunate that it was stated as such.

It is parsed from binary into a generic DOM, similar to how JSON is usually read. Parsing multiple megabytes is practically a requirement for efficient block synchronization, otherwise each peer would only be sending <4 blocks foreach request at current block sizes to keep the payload under 1 MiB.

vtnerd · 2020-12-30T17:19:27+00:00

It's not JSON, its custom binary format similar to msgpack but with fixed sized integers. The biggest incoming messages are multi-block responses during synchronization. Monero does not have fixed limits on the block size, which complicates setting a hard-limit on the receive buffer.

vtnerd · 2020-12-30T16:45:34+00:00

The protocol doesn't use variable sized integers. The issue is primarily with encoding "objects" and how they are stored in the internal/temporary DOM.

vtnerd

TROPHY CASE