01:42:29 * ziyzhou[m] uploaded an image: image.png (199KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ITuQBtiJgpBwhOGczkfoYbpG/image.png >
01:42:39 <ziyzhou[m]> Not sure if you have talked about this issue. The logo is very big in new page https://www.getmonero.org/community/team/
01:43:32 <selsta> ziyzhou[m]: seems to be a caching issue, try in a private browser
01:46:17 <ziyzhou[m]> selsta: It works good in private mode. Thanks.
01:46:45 <selsta> our css caching seems too aggressive
01:47:24 <selsta> .merge+ 7075 7074
01:47:24 <xmr-pr> Added
04:45:51 <gingeropolous> huzzah! 8 hrs and 90+ rpc connections and im still able to connect. perhaps v0.17.1.7 fixed some rpc exploit
07:26:38 <mnt_grrrl> I am following the direction in this link Gatian (https://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
07:29:10 <mnt_grrrl> 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
08:02:54 <selsta> mnt_grrrl: I would recommend to try building the next version.
08:03:18 <selsta> This release has issue for those who don't have dependencies cached.
08:04:13 <mnt_grrrl> will do
08:04:44 <mnt_grrrl> is there a low volume mailing list that announced when it is build time?
08:05:19 <selsta> No, it is announced in this channel.
08:05:49 <mnt_grrrl> ok thanks
09:59:53 <mj-xmr> 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?
10:00:20 -xmr-pr- normoes opened pull request #7153: Add wallet name, network mode to inactivity lock.
10:00:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7153
10:01:43 <selsta> mj-xmr: you can write a comment on your PR on repo.getmonero.org
10:02:03 <selsta> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/138
10:03:22 <mj-xmr> selsta: Thanks. Will do.
10:03:33 <mj-xmr> And congrats on the ccache :)  Kicks ass.
10:03:50 <selsta> :D
10:04:33 <mj-xmr> 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.
10:04:48 <selsta> yep, can change it to 200
12:07:25 <marcimbimbo> https://twitter.com/hyc_symas/status/1203709575226183683
12:07:28 <marcimbimbo> 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 :')
12:07:31 <marcimbimbo> I just binned it though instead of showing it off to naive groupies.
13:15:12 <ErCiccione[m]> Could somebody review 6986? Would be a good UX improvement for a project we are working on (no spoilers :D)
13:15:20 -xmr-pr- moneromooo-monero opened pull request #7155: Reject existing claimed blocks in sync mode
13:15:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7155
13:15:20 -xmr-pr- moneromooo-monero opened pull request #7154: Reject existing claimed blocks in sync mode
13:15:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7154
13:16:33 <moneromooo> Looks ok.
13:16:53 <moneromooo> I have that feeling it'll end up confusing people, but hey, we'll see.
13:23:50 <ErCiccione[m]> thanks mooo. I think woodser's points make sense and better to make such change sooner than later
13:25:02 <hashes4merkle> 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.
13:25:32 <moneromooo> Your DB is likely borked. Delete it, sync again.
13:26:01 <moneromooo> SIGBUS is likely addressing outside the allocated virtual memory.
13:26:05 <hashes4merkle> Reproduced this 3-4 times now.  I thought maybe it was ssd, swapped those. Same manufacturer though.
13:26:17 <moneromooo> Unless you're on a Sun or something, but that's unlikely.
13:26:18 <hashes4merkle> Also swapped SD Card.
13:26:40 <hashes4merkle> Nah, Elon says he'll take me to mars but I'm not holding out.
13:27:46 <hashes4merkle> 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.
16:12:25 <sethsimmons> If anyone has recommendations on how to easily integrate the ban-list for BTCPayServer users, it would be highly appreciated: https://github.com/btcpayserver/btcpayserver-docker/issues/408
16:12:55 <sethsimmons> 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.
16:16:51 <moneromooo> --ban-list /path/to/file isn't easy ?
16:17:07 <sethsimmons> They use a Docker image brough up by docker-compose for BTCPayServer
16:18:19 <moneromooo> Does this mean "--ban-list /path/to/file isn't easy" ?
16:18:46 <sethsimmons> Would need to integrate the file download and new arg into the docker-compose file AFAICT
16:19:08 <tobtoht> just merge or patch #7066 in tbh and it will be fixed
16:19:16 <sethsimmons> 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.
16:20:12 <sethsimmons> <tobtoht "just merge or patch #7066 in tbh"> Why was this rejected?
16:21:25 <tobtoht> xiphon blamed upstream, even though it's clearly a libwallet issue as the current behavior differs from CLI
16:23:19 <tobtoht> I'm just salty that we're still dealing with this even though a fix has been known for a month now
16:24:53 <moneromooo> The patch seems wrong. The problem is probably that the GUI bails if the daemon isn't synced.
16:25:20 <moneromooo> It kinda makes sense as a guard against sending a tx with only old fake outs.
16:25:51 <tobtoht> moneromooo: the synced check happens here: https://github.com/monero-project/monero/blob/1639d0ca7f054e1cf6d0445732b99ac61fc320a2/src/wallet/api/wallet.cpp#L2174
16:26:46 <moneromooo> And that blocks sending txes ?
16:34:41 <tobtoht> 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.
16:35:48 <moneromooo> 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.
16:36:20 <moneromooo> If you merge this patch though, the asshole will just claim a bit more extra height.
16:38:14 <tobtoht> I wonder why he hasn't done that already, then he'd mess up CLI too
16:39:13 <moneromooo> Oh, that's the difference, the cli checks for a small number ?
16:40:33 <tobtoht> I would have to check the code, but that's what I've been told
16:40:58 <tobtoht> and if CLI doesn't check for a smaller number, does the same performance consideration not apply?
16:41:13 <moneromooo> The same applies.
16:55:36 <mj-xmr> 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
17:08:15 <moneromooo> 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.
17:09:27 <tobtoht> 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.
17:09:46 <tobtoht> 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.
17:10:06 <tobtoht> 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.
17:10:19 <tobtoht> Fwiw, I patched out the sync check entirely in Feather, and it works. I suggest other wallets do the same.
17:11:11 <Lyza> 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
17:11:42 <Lyza> but maybe not enough to matter
17:12:03 <tobtoht> It will, but if it's too far behind other nodes will reject the tx iirc
17:12:37 <Lyza> it can get rejected even if it's not a double spend? my understanding is there's no consensus level enforcement of ring selection
17:12:55 <moneromooo> They should not reject it (unless it's not valid of course).
17:13:15 <Lyza> ok yeah that's what I would think, and ring selection isn't enforced via consensus so
17:15:30 <moneromooo> "expect the current behavior" being "expect the wallet to not sync if the dameon isn't" ?
17:15:45 <tobtoht> right
17:15:58 <moneromooo> Some wallets actually depend on that ?
17:26:31 <moneromooo> I think maybe a "is_daemon_busy_syncing" RPC might do for this.
17:26:43 <moneromooo> It's return wjether it's currently adding blocks.
17:28:34 <moneromooo> Any opinion of whether that's a daft idea ?
17:30:11 <Lyza> 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.
17:30:23 <moneromooo> No.
17:33:05 <Lyza> is what I suggested something like what you meant? how are we defining "currently adding blocks"
17:34:34 <moneromooo> 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.
17:36:27 <tobtoht> 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.
17:36:33 <Lyza> Seems reasonable to me. As long as it's somehow tied to the daemon actually receiving blocks instead of just waiting for them
17:37:24 <Lyza> 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
17:38:11 <tobtoht> "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.
18:59:12 <selsta> 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
18:59:19 <selsta> it would fix nothing
20:04:03 <rbrunner> 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?
20:04:21 <rbrunner> On a range from "Forget it" to "Needs only a tweak or two" ...
20:09:01 <hyc> why would you want to run it on windows...
20:23:20 <binaryFate> updated DNS to 0.17.1.7
20:29:05 <selsta> tobtoht: do you think this would help GUI? https://github.com/monero-project/monero/pull/7156
20:30:20 -xmr-pr- moneromooo-monero opened pull request #7156: rpc: add a busy_syncing field to get_info
20:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7156
20:33:21 <tobtoht> selsta: I think so yes, I'll test
20:33:55 <selsta> thanks
20:35:24 <moneromooo> Note that this will be false when it's idle waiting for more blocks. Which happens fairly frequently when syncing.
20:36:00 <moneromooo> So you want to check repeatedly, not just once then sync a full wallet.
21:05:40 <Snipa> .merges
21:05:40 -xmr-pr- 7074 7075
21:11:58 <selsta> https://github.com/monero-project/monero/issues/7158 looks like a bug?
21:28:21 <viperperidot[m]> Will the monero GUI be implementing multisig in the future?
21:36:00 <selsta> viperperidot[m]: possible, but it does not have high priority currently
22:03:36 <selsta> .merge+ 7140 7143 7144
22:03:36 <xmr-pr> Added
23:01:54 <tevador> sybil nodes seem to have changed behavior, my .7 node is now permanently stuck at +2 height
23:03:04 <selsta> tevador: 7154