Not sure if you have talked about this issue. The logo is very big in new page getmonero.org/community/team

ziyzhou[m]: seems to be a caching issue, try in a private browser

selsta: It works good in private mode. Thanks.

our css caching seems too aggressive

.merge+ 7075 7074

Added

huzzah! 8 hrs and 90+ rpc connections and im still able to connect. perhaps v0.17.1.7 fixed some rpc exploit

I am following the direction in this link Gatian (github.com/monero-project/monero/blob/master/contrib/gitian/README.md) and keep running into error. Is there a more uptodate direction or should I post my error to pastebin

Linux ubuntu 5.4.0-58-generic #64~18.04.1-Ubuntu SMP Wed Dec 9 17:11:11 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

mnt_grrrl: I would recommend to try building the next version.

This release has issue for those who don't have dependencies cached.

will do

is there a low volume mailing list that announced when it is build time?

No, it is announced in this channel.

ok thanks

Hi Mates,I will be starting my holidays this week (more time) so thought about publishing of what I have already done from my CCS. What's the right place for this?

mj-xmr: you can write a comment on your PR on repo.getmonero.org

selsta: Thanks. Will do.

And congrats on the ccache :) Kicks ass.

:D

However I have noticed, that the max size of 150 MB might be a bit too little. I saw sometimes, that it exceeds 175. If I find it in the logs, I will let you know.

yep, can change it to 200

Last time I got an award like that was in a primary school football team. It had three stars too and said that I'm special :')

I just binned it though instead of showing it off to naive groupies.

Could somebody review 6986? Would be a good UX improvement for a project we are working on (no spoilers :D)

Looks ok.

I have that feeling it'll end up confusing people, but hey, we'll see.

thanks mooo. I think woodser's points make sense and better to make such change sooner than later

Any documentation on bus errors with monerod on the raspberry pi? Latest version has been kicking out SIGBUS error for me. Looking at stacktrace now. Seems it tries to make a call to cryptonote::BlockchainLMDB::add_spent_key that fails.

Your DB is likely borked. Delete it, sync again.

SIGBUS is likely addressing outside the allocated virtual memory.

Reproduced this 3-4 times now. I thought maybe it was ssd, swapped those. Same manufacturer though.

Unless you're on a Sun or something, but that's unlikely.

Also swapped SD Card.

Nah, Elon says he'll take me to mars but I'm not holding out.

It seems to fail around 40-50% pretty consistently. New SSD. I verified with what we have on github. Added max current, swaps and whatnot all good.

If anyone has recommendations on how to easily integrate the ban-list for BTCPayServer users, it would be highly appreciated: btcpayserver/btcpayserver-docker #408

They've been trying to get Monero working in there since the start of the +2 attacks without much success aside from a "hacky" way to integrate the ban-list manually.

--ban-list /path/to/file isn't easy ?

They use a Docker image brough up by docker-compose for BTCPayServer

Does this mean "--ban-list /path/to/file isn't easy" ?

Would need to integrate the file download and new arg into the docker-compose file AFAICT

just merge or patch #7066 in tbh and it will be fixed

I'm going to attempt a PR when I have time but wanted to surface it here if someone happens to have the immediate skillset to help them out.

<tobtoht "just merge or patch #7066 in tbh"> Why was this rejected?

xiphon blamed upstream, even though it's clearly a libwallet issue as the current behavior differs from CLI

I'm just salty that we're still dealing with this even though a fix has been known for a month now

The patch seems wrong. The problem is probably that the GUI bails if the daemon isn't synced.

It kinda makes sense as a guard against sending a tx with only old fake outs.

moneromooo: the synced check happens here: github.com/monero-project/monero/bl…0a2/src/wallet/api/wallet.cpp#L2174

And that blocks sending txes ?

I guess not, unless constructing a tx with an out of sync wallet can cause txs to get rejected by the daemon. The patch will make sure the wallet stays refreshed. GUI might have an additional check that disables sending if daemon isn't synced.

Right. AFAICT from this code, the wallet will just not sync. Which is kinda sensible given daemon sync + wallet sync kinda thrash I/O IIRC.

If you merge this patch though, the asshole will just claim a bit more extra height.

I wonder why he hasn't done that already, then he'd mess up CLI too

Oh, that's the difference, the cli checks for a small number ?

I would have to check the code, but that's what I've been told

and if CLI doesn't check for a smaller number, does the same performance consideration not apply?

The same applies.

I see you guys are heavily firefighting currently. If there was however a friendly ghost, who could merge these 3 no-brainers, I could finalize a huge work package, that I have hanging: 6975 6959 6989

FWIW, I just tried and the wallet works just fine (and can send a tx) if the daemon has a target way beyond what its chain.

Ok, yeah, can't find it either. Regardless, I think we should've prioritized what's effectively a denial-of-service attack that currently affects many GUI/libwallet users over a performance issue that apparantly not enough people have noticed for it to be included in the CLI.

Unfortunately, a lot of wallets that use libwallet (inluding the GUI) expect the current behavior, so removing the sync check entirely is not an option.

Imo this piece of logic has no place in an API, it should be left to the client to decide, but hard to change that now.

Fwiw, I patched out the sync check entirely in Feather, and it works. I suggest other wallets do the same.

what's the downside to sending transactions if the node is actually for real behind? Assuming no double spend. Seems like it would affect ring selection maybe

but maybe not enough to matter

It will, but if it's too far behind other nodes will reject the tx iirc

it can get rejected even if it's not a double spend? my understanding is there's no consensus level enforcement of ring selection

They should not reject it (unless it's not valid of course).

ok yeah that's what I would think, and ring selection isn't enforced via consensus so

"expect the current behavior" being "expect the wallet to not sync if the dameon isn't" ?

right

Some wallets actually depend on that ?

I think maybe a "is_daemon_busy_syncing" RPC might do for this.

It's return wjether it's currently adding blocks.

Any opinion of whether that's a daft idea ?

Do we really need to pause wallet refreshes for adding blocks when the daemon is already synced? I'm thinking, naively mind you, that you have something like syncing true/false and it's only true if the daemon has added at least X blocks in Y minutes, or something like that.

No.

is what I suggested something like what you meant? how are we defining "currently adding blocks"

Mostly. I was thinking of defining it as exactly what it says on the tin. What you said is also a possibility, though with builtin delay.

Seems like that would work. Then just replace the daemonSynced() in wallet_api with the a is_daemon_busy_syncing() check and you don't risk breaking downstream wallets.

Seems reasonable to me. As long as it's somehow tied to the daemon actually receiving blocks instead of just waiting for them

but I do think it would be nice if the wallet sync didn't pause whenever there was a new block on an otherwise synced daemon

"Some wallets actually depend on that ?" -> If you remove the check GUI UI related to syncing will break in weird ways, that's all I know.

17:36 <moneromooo> If you merge this patch though, the asshole will just claim a bit more extra height. <-- that's exactly why I did not merge this

it would fix nothing

I tried to compile the "onion-monero-blockchain-explorer" from the "Monero Examples" for Windows on msys2. Stops very early in CMake already. Anybody has any idea how far away compiling on msys2 might be?

On a range from "Forget it" to "Needs only a tweak or two" ...

why would you want to run it on windows...

updated DNS to 0.17.1.7

tobtoht: do you think this would help GUI? monero-project/monero #7156

selsta: I think so yes, I'll test

thanks

Note that this will be false when it's idle waiting for more blocks. Which happens fairly frequently when syncing.

So you want to check repeatedly, not just once then sync a full wallet.

.merges

monero-project/monero #7158 looks like a bug?

Will the monero GUI be implementing multisig in the future?

viperperidot[m]: possible, but it does not have high priority currently

.merge+ 7140 7143 7144

Added

sybil nodes seem to have changed behavior, my .7 node is now permanently stuck at +2 height

tevador: 7154