xmr: Download required monero client tools.

[dev-warrior777]

Completes #3383

• Removed tools configuration

Some more cleanup to do before review.

[JoeGruffins]

Sorry reviewing before you are ready.

So, what's the flow? I guess I would expect:

1. Try to get the hashes file at https://www.getmonero.org/downloads/hashes.txt and verify that with some public key somewhere. I guess we check every start up? Anyway when they first download for now is fine.

2. Parse the list and pick out the version and hash of the os and arch we should have.

3. Check if we have that version. If yes done. If no continue. Also continue if we have nothing downloaded yet.

4. Further check we can use the version in the list. We would accept any version v0.n.n.x. x, or patch can be higher than what we have hard coded. All other numbers must be the same. If we already have a valid version and the one in the list is not valid, stop and do not update.

5. If we have nothing and the version from the list is not valid, we must have a hard coded version and hash to download an earlier version and continue. We would also jump here if we had a problem getting or reading the list and have nothing.

6. Download the file and check hash.

7. Decompress to where we will keep it.

8. Use.

[buck54321]

This seems like a bad idea to me. If people want a full node wallet, they can run a node and handle the rpc api configuration through the ui. I thought we were implementing a monero light wallet first.

[JoeGruffins]

@buck54321 it's like running dcrwallet but dcrd is remote. One can set up a full node to connect to as you say.

I think it is a light wallet. please see https://docs.getmonero.org/interacting/monero-wallet-rpc-reference/#json-rpc-interface

Wallet uses your private keys to understand your total balance, transactions history, and to facilitate creating transactions.

However, wallet does not store the blockchain and does not directly participate in the p2p network.

We don't have any golang libraries to use this technology is why we are downloading the binaries for now.

[dev-warrior777]

So, what's the flow? I guess I would expect:

Just follow Download.Run func. It is essentially laid out as the steps .. rejection of invalid version is handled by moneroVersionV0 - reject if < v0.18.4.3 or does not start with 'v0' since it never has in monero recent history.

Since this all happens only in create and we always want the latest version from hashes.txt there is no initial check for "have we got it already" since we almost always do not.

However there are exported functions to do those kind of checks .. mostly for later.

[dev-warrior777]

Sorry reviewing before you are ready.

No that's fine. It gives me the chance to explain where I am going.

Run download_test.go

This is the relevant part of hashes.txt:

## CLI
7c2ad18ca3a1ad5bc603630ca935a753537a38a803e98d645edd6a3b94a5f036  monero-android-armv7-v0.18.4.4.tar.bz2
eb81b71f029884ab5fec76597be583982c95fd7dc3fc5f5083a422669cee311e  monero-android-armv8-v0.18.4.4.tar.bz2
bc539178df23d1ae8b69569d9c328b5438ae585c0aacbebe12d8e7d387a745b0  monero-freebsd-x64-v0.18.4.4.tar.bz2
2040dc22748ef39ed8a755324d2515261b65315c67b91f449fa1617c5978910b  monero-linux-armv7-v0.18.4.4.tar.bz2
b9daede195a24bdd05bba68cb5cb21e42c2e18b82d4d134850408078a44231c5  monero-linux-armv8-v0.18.4.4.tar.bz2
c939ea6e8002798f24a56ac03cbfc4ff586f70d7d9c3321b7794b3bcd1fa4c45  monero-linux-riscv64-v0.18.4.4.tar.bz2
7fe45ee9aade429ccdcfcad93b905ba45da5d3b46d2dc8c6d5afc48bd9e7f108  monero-linux-x64-v0.18.4.4.tar.bz2
8c174b756e104534f3d3a69fe68af66d6dc4d66afa97dfe31735f8d069d20570  monero-linux-x86-v0.18.4.4.tar.bz2
645e9bbae0275f555b2d72a9aa30d5f382df787ca9528d531521750ce2da9768  monero-mac-armv8-v0.18.4.4.tar.bz2
af3d98f09da94632db3e2f53c62cc612e70bf94aa5942d2a5200b4393cd9c842  monero-mac-x64-v0.18.4.4.tar.bz2
7eb3b87a105b3711361dd2b3e492ad14219d21ed8fd3dd726573a6cbd96e83a6  monero-win-x64-v0.18.4.4.zip
a148a2bd2b14183fb36e2cf917fce6f33fb687564db2ed53193b8432097ab398  monero-win-x86-v0.18.4.4.zip
84570eee26238d8f686605b5e31d59569488a3406f32e7045852de91f35508a2  monero-source-v0.18.4.4.tar.bz2
#

[JoeGruffins]

Just follow Download.Run func.

Can you humor me. Is it very different than what I would expect and why?

Since this all happens only in create and we always want the latest version from hashes.txt there is no initial check for "have we got it already"

It would be done from different networks and different build dirs. It's one dir forbthe user currently. We also don't want latest of the Major version is higher.

[JoeGruffins]

Itvlooks like the main difference is that you aren't checking if we already have it. If I made a simnet wallet then a mainnet wallet I would already have it. If we add a wallet delete like btc we would already have it. if restoring feom seed may already have it.

[dev-warrior777]

It looks like the main difference is that you aren't checking if we already have it. If I made a simnet wallet then a mainnet wallet I would already have it. If we add a wallet delete like btc we would already have it. if restoring feom seed may already have it.

Even if we have 0.18.4.3 we want to update to 0.18.4.4 (and for now) the old one would not be overwritten)

I see no circumstance where we would have it before wallet creation
Added a test latestToolsNeeded before starting a download

[dev-warrior777]

Can you humor me.

I did not mean like that ...

The Download.Run function drives the sequencing and is a pure list of steps for the download/extract process. Scanning that was my way of pointing you to an easy way to grok the download process.

[dev-warrior777]

Yeah, not quite right .. I really need --appdata but only DataDir available at Driver.Create time. Working ..

[dev-warrior777]

Got a couple minor edge cases for architectures/OS's I want to look at but I think ready to review

[JoeGruffins]

Some comments.

[dev-warrior777]

The MAV stuff can be easily pulled out if it is not what you meant.

Another way of hard coding an acceptable version would be to package one version of the monero zip set in dex. We need 7 os/arch files to cover the intersection of os/arch's we support in dex so 7x80MB for the full zipped set. But could also make a versioned dir of the extracted tools which would be 7x56MB which is actually quite large due to good compression I guess.

[JoeGruffins]

Very involved, looks like you thought of every angle here. Just a few more nits.

[dev-warrior777]

Then I tried adding a go.mod in xmr/cmd/mkJson:

errors

~/dex/dcrdex/client/asset/xmr/cmd/mkjson (xmr-tools-dl)$ cat go.mod

module decred.org/dcrdex/client/asset/xmr/cmd/mkjson

go 1.25.4

~/dex/dcrdex/client/asset/xmr/cmd/mkjson (xmr-tools-dl)$ go mod tidy

go: finding module for package decred.org/dcrdex/client/asset/xmr/toolsdl
go: finding module for package github.com/decred/slog
go: finding module for package decred.org/dcrdex/dex/dexnet
go: finding module for package github.com/PuerkitoBio/goquery
go: finding module for package decred.org/dcrdex/dex
go: downloading decred.org/dcrdex v1.0.5
go: found decred.org/dcrdex/dex in decred.org/dcrdex v1.0.5
go: found decred.org/dcrdex/dex/dexnet in decred.org/dcrdex v1.0.5
go: found github.com/PuerkitoBio/goquery in github.com/PuerkitoBio/goquery v1.11.0
go: found github.com/decred/slog in github.com/decred/slog v1.2.0
go: finding module for package decred.org/dcrdex/client/asset/xmr/toolsdl
go: decred.org/dcrdex/client/asset/xmr/cmd/mkjson imports
	decred.org/dcrdex/client/asset/xmr/toolsdl: module decred.org/dcrdex@latest found (v1.0.5), but does not contain package decred.org/dcrdex/client/asset/xmr/toolsdl

So that will not work. I guess because not merged yet?

I will try to find another html->text tool ..

Edit: Found anaskhan96/soup which can manipulate HTML DOM

[JoeGruffins]

Looks good to me. A few more requests inline but after some testing I think good to go. Thanks for making the tool.

[JoeGruffins]

Locally I'm seeing a problem rebasing. Can you rebase and force push? You could flatten everything into one commit first which would make it easier.