I'm running the latest version (0.17.1.6) of monerod, yet my node fell 2 blocks behind again... it worked fine for a few days, just noticed this now. Are there still any holes left that need to be fixed? Height: 2250141/2250143

Do you have the ban list applied?

No.. they said it's not required with 0.17.1.6 anymore so I happily removed it again

algo_max[m]: it will be required for one or two more releases

Has anyone here used the "Feather Wallet" client? The beta was released in October I believe and it's essentially an Electrum clone for Monero (a very good one). I'm throwing everything I have it it via the terminal, using different addresses indices on a hardware wallet... it seems to be totally solid. I'm considering using it as a portable client since it plays nice with hardware wallets and syncs very quickly. Got a look at the codeba

se and there's certainly nothing malicious, but I haven't been able to audit it 100% yet. Wondering if anyone else has had a chance to test it out and has any feedback

It's not created by the official Monero team FYI (unless they're being super anonymous).

it was created by someone who used to work on the GUI

AIUI it's not an electrum clone, just inspired by it

Yeah it's legit I've been using it as an intermediary wallet since the alpha. couldn't in good conscience recommend beta software for storing large amounts of funds but the devs themselves are solid they work on wownero too

the advanced coin control is nice

Yes! Love the advanced coin control. Sorry, I did mean to say alpha. It's a very slick wallet.

no you were right the beta was released recently

just saying I was using it in alpha as well

they've got an IRC channel on OFTC you might've found it already

Yes, thank you I did see that on the site.

Good to know the devs are standing members of the community, appreciate all the feedback.

<ConsciousFlesh "Has anyone here used the "Feathe"> I thought Feather didn't support hardware wallets?

But yes I also use it - is awesome

Love the integration of Morphtoken and xmr.to

I think its cool having the reddit and ccs pages on there too

Overall a great wallet and super lightweight

selsta: alright, I'll enable the ban-list again. thanks

I'm trying to download the current version of the cli wallet for Linux amd64, but it's still v0.17.1.3. Other downloads, like Linux x64 or FreeBSD amd64, are v0.17.1.6. Is there a reason for the Linux amd64 version being older?

*Linux x86

The CLI v0.17.1.6 is definitely available. You may have a stale cache. I think ctrl+F5 forces a full refresh?

codesoap: Use a private / incognito window, probably a local caching issue

or wget :)

And if that doesn't work, here's a direct download link: downloads.getmonero.org/cli/monero-linux-x64-v0.17.1.6.tar.bz2

Firefox caching really seems uhh, a little too aggressive ngl, we see people with this issue regularly heh

dunno if other browsers are as bad

Thanks for your help! ctrl+F5 didn't help, but a private window did work. That' indeed weird caching of Firefox...

cool :)

download accelerator plus from tucows works best

lol is that a joke

tucows still exists?

probally :D

Is there a good reason for the download link pointing to downloads.getmonero.org/cli/linux64 instead of /downloads.getmonero.org/cli/monero-linux-x64-v0.17.1.6.tar.bz2? I guess Firefox wouldn't have problems, if the link changed with every release. It would also be better for downloading with wget, since the output file would have a meaningful name, instead of "linux64".

I would presume the idea is to have a permanent URL that always redirects to the most recent version. Maybe makes updating the site for new releases easier as well? but yeah Ig that's probably the source of the caching issues too

use wget --trust-server-names and it'll use the expected filename

@hyc cool, thanks for the tip!

always read the manpages...

@Lyza: OK, that sounds plausible. I guess downloads.getmonero.org/cli/linux64 could be useful for some scripts, but this link could be kept, besides changing the links on the webpage. Though I undestand, that updating the HTML on every release could be annoying...

Aha! In the Firefox dev console I can see, that the redirects are cached. I guess some cache-control-headers are missing here. I'm going to take a look at github.com/monero-project/monero-site and maybe propose a pull request.

that would be dope

who can share Feather Wallet link?

Does it have mac version. I'll give it a shot.

And it has a mac version.

on featherwallet.org firefox says: "featherwallet.org has been reported as containing harmful software. You can ignore the risk and go to this unsafe site."

Damn javascript is everywhere nowadays, isn't it.

@Lyza @hyc: JFYI: I created github.com/monero-project/monero-site/pull/1366. I think this should stop the download caching problem.

kinda blows my mind that the server can control the client

My monerod is still reporting 2 blocks missing from the attack. Anything else i can do besides using the banlist?

Use latest. Those blocks aren't missing fwiw, they don't exist and never have.

Or wait for .7, which should be out soon.

moneromooo, I´m aware they don´t exist, but they do prevent proper syncing/unlocking of the wallet.

I just want my node to run optimally to support the network and mitigate the effect of the attacks.

Does my monerod also report the chain length of +2 or does it report the actual block height to my outgoing connections?

I assume the actual current node block height gets sent, but i´m not 100% certain.

Can this not be mitigated like this? my node receives a fake +2 block height from malicious node, requests these blocks from any of these nodes that have this block height, fetching blocks obviously fails, either because they are invalid blocks or don´t get send at all. Then receive a time-out and fall back to the lower, actual block height?

<bobandback> u running on Linux?

Lyza, yes.

I wrote a little script to get the latest ban list and add any new entries without restarting monerod, might help you out here

I'm running it with cron every 24 hours, haven't seen the issue crop up

I´m using the latest blocklist which doesn´t seem to help (enough)

you're on 0.17.1.6?

Maybe i should clear my p2pstate.bin?

Lyza, yes.

ehhh I mean it won't hurt but prolly would only be a temorary sol'n. I wish I had more advice like I said this has been sufficient mitigation for me. Next version should have further mitigations.

if you need to transact there's the CLI or feather which are unaffected but the +2 issue

by*

Why are those not affected? They don´t lock the wallet if the blockchain isn´t fully synced to the highest reported block height?

Haven´t used CLI in ages.

yeah that's basically my understanding though I'm not a dev. the GUI or some reason uses different logic for this while the CLI and feather ise libwallet directly or some such? I'm sure somebody will correct me :D

Deleting the p2pstate helped for now. May not last though, we will see. At least i can do a transaction.

How does it feel to be in the queue to be the bottom bitch in a harem of a narcissistic fraud?

If you really want to learn an outdated programming language like C you can just take a course instead of sucking off "the Saviour of NASA"

yo, why does monero use gpg hashes and electrum wallet uses signatures to verify?

like for example fro the electrum site, "(Note that an attacker would be able to create valid hashes, this is why we do not publish hashes of our binaries here, it does not bring any security)."

just tryin to knowledge up on pgp

The hashes are signed

I don't know what threat they're trying to describe

They are correct that merely posting hashes is not sufficient

fluffypony: If someone modifies the plain hashes

I think that's what they are referring to

ah ok

List plain SHA256 hash -> attacker will modify both the hash and the binary

So verifying the listed hash is insufficient in that sense

hmmm. so, is verifying with hashes adding another step? here's what i did to verify electrum: gpg --verify electrum-4.0.7-x86_64.AppImage.asc electrum-4.0.7-x86_64.AppImage

thanks!

That should be enough to verify it as long as you properly imported and verified the key that was used to sign it

yes. thanks so much. didn't mean to ask for electrum support just tryin to understand to difference. PEACE TO ALL. enjoy the apocolypse

omega, It´s essentially the same process. I find signed hashes more useful. Only need to verify the entire list once and can then just check hashes of the binaries.

thank you!

Is Kastelo still being worked on?

I just wanna say the option for "human readable date format" on the GUI is really funny. are there non-humans using the GUI? =P

where's the Klingon date format?

lol brb starting a CCS for translation to klingon

is non-human date format unix time?

I don't think I ever used gui for more than 5 min

yyy-mm-dd hh:mm:ss

"human readable" is like, "10 days ago"

Why does the Monero website recommend the Edge app? Is the Edge app fully open source and reviewed for security?

<Lyza> lol brb starting a CCS for translation to klingon

That's a good idea. Monero is like a cloaking device for money.

hello, does the AppImage version of monero-gui have an auto updater?

or like... what's the best way to auto update it? Should I best download the new version every time?

The best way is to use your package manager tbh

anchor: uh, but don't a lot of distros have like _really_ outdated packages in their repos?

Debian stable comes to mind

Only the garbage ones

Debian stable is meant for servers

...or for desktop users looking for maximum stability.

If you're looking for maximum stability don't use appimages or snaps or flatpaks

what? AppImage files are built by devs and contain all of the dependencies as meant for by the devs themselves, no?

Yes but you get a mess of a system if you use appimages. The only real benefit I can see is portability.

not entirely related but snaps and flatpaks are the devil

I don't use those but for certain key apps I do use AppImage

you can use appimages as much as you like but it's not the best way

I'm pretty sure Monero devs ship normal binaries too

what is then the difference of a really big static binary vs. AppImage?

The binaries aren't really big.

AppImages are, they're basically glorified ISOs

but they can be compiled with everything including the kitchen sink, thus making them equivalent to said ISOs

iirc it's computationally easier to just run a binary rather than to mount an ISO every time

at which point I fail to see any benefit to AppImages

well that could be but I don't really care about CPU usage, I'd just like it to get timely (auto) updates to stay up with the latest patches.

can appimages do autoupdates? I don't know

I don't believe so

if you wanna stay up to date just check Monero's news

so, manual updates then.

yep

Sorry if I came off like an ass, I just have a gripe with 'universal' package manager snakeoil. And I've had a long day lol

I didn't get that impression, more that the answers weren't thought through sufficiently.

A repo / PPA would be best in my case but I'm not sure if Monero devs offer that

a quick google shows that there are ways to get updater functionality for appimages, if you really want that

it sounds bloated though.

then there wouldn't be much difference between AppImage and Snap/Flatpak (as the latter offer the auto-update functionality)

When it comes to Monero distributions I would ONLY trust getmonero.org and your official distro package repositories

in fact, you can't even turn them off in Snaps :p

I can't even find an AppImage on the site

it's included in the tar files

Ah okay

I got the binaries from my repo

<span data-mx-spoiler>I use Arch btw</span>