01:02:50 <luigi1111w> branched. will tag tomorrow I suspect
01:14:46 <selsta> thanks, yea tag tomorrow is important so that we can release on time
09:50:48 <selsta> sarang: https://github.com/trezor/trezor-firmware/pull/1246 can you confirm that the HF date was communicated with ph4r05 (our Trezor contact)?
13:43:23 <sarang> I had communicated the timeline to ph4r05 (and others, via GitHub): https://github.com/trezor/trezor-firmware/pull/1246#issuecomment-687156825
13:44:52 <sarang> I also had separately emailed ph4r05 on July 19 with the same timeline
13:45:31 <sarang> That email contained the expected dates, but of course not the specific fork height at that time
14:42:51 <luigi1111w> Oxygen Orion?
14:46:01 <nioc> luigi1111w: sadly yes
15:05:14 <luigi1111w> https://github.com/monero-project/monero/tags
15:05:24 <luigi1111w> please check
16:05:28 <sarang> Reminder that the weekly #monero-research-lab meeting starts at 17:00 UTC
16:05:29 <sarang> .time
16:22:01 <sarang> Didn't there used to be a bot in here?
16:22:02 <sarang> .date
16:22:04 <sarang> .time
16:22:58 <camthegeek> no wowbux/monerobux in -dev
16:23:20 <sarang> boo
16:23:31 <sarang> Maybe it got annoying and someone booted it
16:23:32 <camthegeek> he's in your lab though
16:23:35 <sarang> ya
16:23:41 <sarang> very helpful for datetimes
16:24:03 <sarang> and s/one/two/ substitutions
16:48:27 <iDunk> sarang: you probably misremembered.
16:50:31 <sarang> Oh well!
18:07:25 <dEBRUYNE> I will create a thread on Reddit for the deterministic builds results
18:11:07 <selsta> I’m busy until tomorrow, maybe someone else can do repro builds + upload them
18:39:52 <m2049r> i am having the issue that "sometimes" a transmitted tx is not seen in the pool and thus marked as failed - until the next refresh/update or it ends up in a block => https://gist.github.com/m2049r/8daf176822cf2d0763a403722d449330 (both client&daemon are 0.16.0.3)
18:39:59 <m2049r> am i doing something wrong??
18:40:06 <m2049r> is this an issue to report?
18:40:57 <m2049r> this is stagenet, but i had it happen on mainnet as well
18:41:25 <m2049r> with different daemons (mine & xmrto)
18:51:59 <iDunk> https://paste.debian.net/hidden/958e2833/
19:08:47 <selsta> m2049r: I have seen similar behavior but was not able to constantly reproduce it, I think it is Dandelion++ related
19:12:58 <luigi1111w> one can always count on iDunk
19:32:07 <m2049r> selsta: thanks. i hadn't seen this before upgrading to 0.16.0.3 daemon-side. how can i help in pinpointing the cause?
19:32:57 <m2049r> it's annoying for the user to think their tx has failed (and maybe repeating it) only to find out it ended up in the next block a couple of minutes later
20:03:22 <selsta> vtnerd: any idea if this is dandelion++ related?
20:03:24 <selsta> ^^
20:25:05 <m2049r> it just happened again. i have the client log. the tx was not in the pool for a long time (>10s) and when it appeared, *that's* when it went to status failed. it stayed that way until it was mined.
20:51:44 <vtnerd> how are you probing the pool for txes? in some cases the daemon should omit the tx from the pool list for privacy reasons
20:52:33 <vtnerd> thats likely one source of funkiness
20:53:27 <vtnerd> who was claiming it failed? the daemon or wallet? I don't recall a failed status in daemon although perhaps it gets reported that way in the UI
20:54:22 <vtnerd> the ~10s blackout was almost certainly the dandelion++ stem phase
20:56:14 <vtnerd> ah ok I see in the scrollback you mentioned "next refresh/update" - the algo seems to be working as expected but the "blackout" in the RPC might be causing issues
20:56:47 <vtnerd> first question is this daemon RPC in restricted mode .. ? selsta m2049r <-
20:59:32 <selsta> I have seen tx taking 2-3 minutes until they show in mempool
21:00:53 <vtnerd> hmm, hit a blackhole (bug? someone on testnet probing things?) then tripped embargo timeout
21:01:32 <vtnerd> one thing with testnet is there's a higher possibility of someone starting/stopping nodes, although I would expect that to be less likely if they accept inbound conns
21:01:57 <vtnerd> if a node goes offline that was used in a d++ stem, its effectively a "blackhole" but not a bug or attack
21:03:25 <selsta> was on mainnet
21:04:34 <selsta> but like I said it was not reliably reproducible
21:04:59 <m2049r> first saw it on mainnet and then checked stagenet where it also happens. but happened to me a lot on mainnet.
21:05:01 <m2049r> using rpc-restricted-bind-port
21:17:30 <Inge-> m2049r: slightly off-topic, I wonder if I hit sone kind of limit with Monerujo. one wallet when opened, scans and scans, but blocks to scan never counts down - but phone gets warm so is definitely doing something. all other wallets work fine. This one has a bunch of subaddresses (<100).
21:54:12 <TheCharlatan> sigs looking good so far :)
23:01:18 <iDunk> https://github.com/monero-project/monero/blob/release-v0.17/contrib/depends/packages/qt.mk#L3
23:01:26 <iDunk> ^ that's a 404.
23:01:57 <iDunk> 5.9 seems to be the oldest release they now host.
23:07:40 <iDunk> http://master.qt.io/new_archive/qt/5.7/5.7.1/submodules/
23:07:48 <iDunk> Looks like that could work.
23:25:16 <selsta> so.. retag?
23:25:34 <selsta> we should set up our own mirror :P
23:27:24 <TheCharlatan> there's still the bitcoin core mirror.
23:27:40 <selsta> that only has some thing
23:27:42 <selsta> things
23:27:54 <selsta> we use the bitcoin core mirror
23:28:01 <TheCharlatan> at least it has the qt archives.
23:28:48 <selsta> oh it does?
23:28:52 <selsta> so no retag?
23:28:54 <selsta> good
23:29:27 <iDunk> I'm looking at my builder/cache/common, and qt submodules are there. Idk from where, the download process gave 404s for qt stuff.
23:29:44 <selsta> yea IIRC bitcoin core mirror has it
23:30:03 <iDunk> Hmm, ok.
23:31:14 <TheCharlatan> https://bitcoincore.org/depends-sources/qtbase-opensource-src-5.7.1.tar.gz
23:38:40 <TheCharlatan> that said, I think I'll bump it 5.15.x, already have a patch for that more or less ready.