00:56:16 <binaryFate> Fluorine Fermi v0.18.0.0 binaries are online!!
00:57:05 <binaryFate> Massive thank you to all contributors
00:57:38 <binaryFate> And thanks to everyone who contributed hashes for the deterministic builds 
01:08:48 <gingeropolous> huzzah! congrats all!
01:26:13 <dangerousfreedom> Awesome :)
01:27:52 <luigi1112> w00t
02:07:39 <garth> Woooo
02:43:04 <PSEP1> Congrats all! This time I'll be around for the hard fork exciting!
06:16:27 <r4v3r23[m]> <binaryFate> "Fluorine Fermi v0.18.0.0..." <- thanks. just missing the github release :)
07:35:38 <fluffypony> moneromooo: I can check them
07:36:28 <fluffypony> ok so the issue is DNSSEC right?
07:39:16 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.de
07:39:36 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.ch
07:39:49 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.fr
07:39:59 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.net
07:40:08 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.no
07:40:17 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.org
07:40:29 <fluffypony> https://dnssec-analyzer.verisignlabs.com/updates.moneropulse.se
07:41:07 <fluffypony> all seems correctly configured per Verisign
07:41:39 <fluffypony> might be the DNSSEC verifier code that is bust
07:42:28 <fluffypony> the only thing I can think of that would affect it (besides ISP oddness) is the . root zone hard-coded key, but that changed a few years and I'm certain we rolled it over
07:42:31 <fluffypony> *few years ago
07:48:54 <sech1> fluffypony https://paste.debian.net/hidden/69c8e330/
07:49:31 <fluffypony> "no DNSKEY rrset for trust anchor . while building chain of trust"
07:49:40 <fluffypony> ok so that's the root domain
07:49:53 <fluffypony> the way DNSSEC works is it only has one key hardcoded, the one for .
07:50:03 <fluffypony> then it checks the trust anchor for .net based on the trust anchor for .
07:50:16 <fluffypony> then the trust anchor for moneropulse.net, and then for updates.moneropulse.net
07:50:41 <fluffypony> so if it's failing on . that means that either your ISP isn't serving DNSSEC records when requested, OR the utility is busted
07:50:53 <sech1> This is on Hetzner server
08:00:36 <fluffypony> hmmm where is monero-utils-dns-check - it's not part of the binary package, right?
08:10:20 <fluffypony> WOW monerod shuts down way way way faster in 0.18
08:10:21 <fluffypony> awesome work
08:18:17 <sech1> monero-utils-dns-checks
08:18:59 <sech1> it's built in debug builds
08:19:36 <johnfoss68[m]> Hey sorry to bother, I'm putting together twitter thread about Monero's upcoming hardfork, and want to add a bit of historical context. Was there ever a code change to include the tail emission? Just been searching thru bitcointalk and couldn't find anything definitive. A rough month/year would be good if someone knows off the top of their head. Cheers. 
08:22:09 <sech1> yes
08:22:15 <johnfoss68[m]> It'll be in reference to the calcification of emission schedule. 
08:22:32 <sech1> https://github.com/monero-project/monero/commit/754a785ee15915c4d8d81dbd55d7005e07c6407e
08:28:13 <sech1> found this piece of history: https://bitcointalk.org/index.php?topic=962235.msg10683368#msg10683368
08:36:22 <fluffypony> johnfoss68[m]: yes
08:38:10 <fluffypony> there was no tail emission, but REALLY early on (first few weeks) I read the Courtois paper (and then years later he hosted the first Monero meetup in London with binaryFate and myself and others) and raised the idea of a tail emission. We announced that we'd be doing this, and then tacotime and I (primarily) debated the exact structure of it, before settling on disinflationary + starting at sub-1%.
08:39:14 <fluffypony> the way we announced it / referred to it prior to the code change was "A minimum subsidy may be implemented in the future with <1% inflation to preserve mining incentives."
08:43:43 <johnfoss68[m]> Thanks guy! 👍
08:43:53 <johnfoss68[m]> guys*
09:04:50 <maybefbi> Hypothetically speaking, If only BlackRock had the permission to add digitally-signed blocks (with BlackRock key) to the monero blockchain, how will they go about discarding transactions from bad actors? AFAIK, this can't be done because monero transactions are already indistinguishable from each other thanks to CLSAG, one-time-addresses, range proofs of pedersen commitments. So BlackRock won't know which transaction they are including or 
09:04:51 <maybefbi> not-including in the blocks under this hypothetical scenario. BlackRock could be handling transations from Sisters-of-Charity or a drug-cartel, so BlackRock won't know which transaction they are dealing with. So why do we require Monero to be permission-less?
09:07:51 <merope> maybefbi not the right room for that discussion, and also you are making a few faulty assumptions. We can continue in #monero if you'd like
09:09:17 <maybefbi> i will paste it there
09:53:08 <HenryHollingwort> the latest binaries when using a ledger hardware wallet say "... app doesn't support the current monero version. Try to update the Monero Ledger App, at least 1.6.0 is required", i think that message will need to be updated (i am on 1.7.8 atm) when they update the monero integration
09:54:42 <ofrnxmr[m]> I just posted the answer to that question in #monero:monero.social 
09:55:10 <ofrnxmr[m]> https://matrix.to/#/!psOvWRiQkyosOPKvaO:matrix.org/$nHeUxOJxQVGBt1nW8qs2Y9rGMik7XNJtInkQPplLdoE?via=monero.social&via=matrix.org&via=tchncs.de
09:55:47 <ofrnxmr[m]> The error should probably be updated to reflect the new minimum version 
09:56:59 <HenryHollingwort> (can't visit the link because i wasn't in the room before that) 
09:57:43 <ofrnxmr[m]> Initially scheduled for July 20:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/10feea1af0e84cf94d9d8fa4763aa7b3f86bc346)
09:59:49 <HenryHollingwort> that's trezor though as opposed to ledger but i assume it's in the same situtation (awaiting update released at which point update min version string same as ^)
11:45:05 <TheCharlatan> hyc I saw this comment on an old bitcoin issue (#18916):
11:45:11 <TheCharlatan> > One key factor to consider here is that BDB supports page-level encryption, and there's an unreleased patch for LMDB that does also. The LMDB-based Monero wallet will be using this feature.
11:45:23 <TheCharlatan> what's the status on that?
12:32:49 <hyc> The LMDB code has been ready for literally years. nobody has worked on migrating the wallet to use LMDB
12:39:01 <hyc> TheCharlatan: probably it won't happen unless some exchanges put up a bounty, since they'll benefit the most from the perf gain
14:20:22 <gingeropolous> seed node ops, update ure seed nodes :)
15:12:21 <selsta> HenryHollingwort: Ledger users have to wait with the update, they didn't put out an update yet.
17:02:46 <moneromooo> 0.18 outputs some irrelevant (unless debugging) error: duplicate key: node_data. I suggest https://paste.debian.net/hidden/42dc99e8/ (untested).
17:03:10 <moneromooo> Just one so far, right at the start, so it might be less spammy than I thought it'd be.
17:04:27 <selsta> didn't see this yet
17:04:54 <selsta> could it be a peer that uses custom code?
17:05:29 <moneromooo> Yes.
17:08:30 <scoobybejesus> i got that basically the moment i started up 0.18 https://paste.debian.net/hidden/2428e7c5/
17:10:40 <hyc> oh yeah, I got that here too, on my arm64 box
17:13:07 <hyc> also got it ~12 hours after starting on my linode. July 17.
17:13:29 <hyc> july 17 5am, july 18 2:47 on my arm64 box
17:17:27 <selsta> can someone get the IP from this peer when using log level 2?
18:31:01 <sethforprivacy> Could someone with monero-announce access please announce the new release? That's the only missing announcement item from https://github.com/monero-project/meta/issues/690.
18:31:45 <sethforprivacy> And has anyone performed testnet Ledger/Trezor testing? I think jberman has done Ledger but want to confirm before I check those off.
18:33:29 <sethforprivacy> And if anyone knows if these unchecked items have been done yet, please let me know.
18:33:38 * sethforprivacy uploaded an image: (136KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.optoutpod.com/dDqHhljzgMzbDZGzKXtuAlle/Screen%20Shot%202022-07-20%20at%202.33.12%20PM.png >
18:36:20 <selsta> ledger / trezor code is not included yet in this release
18:37:30 <sech1> moneromooo I don't think it's safe to redefine MONERO_DEFAULT_LOG_CATEGORY inside a header file
18:37:39 <sethforprivacy> selsta: But both have dev builds up, so was just wondering if they've been tested. If not I'll just leave them unchecked and add a note.
18:38:25 <moneromooo> It is safe, since it just redirects the category. cpp files #define this after all header includes.
18:38:42 <moneromooo> There are already headers that do this, due to epee's header heavy design.
18:39:05 <sech1> if cpp files redefine it then ok
18:39:06 <moneromooo> The worst you get is an unexpected default category, which should be trivial to fix.
18:39:15 <moneromooo> Most do.
18:39:32 <selsta> binaryFate has to send a monero-announce mail
18:39:36 <moneromooo> (and should)
18:40:11 <sethforprivacy> selsta: Figured but wasn't sure, thanks, selsta!
18:40:55 <jberman[m]> Seth For Privacy: I created testnet txs with a ledger with this code (https://github.com/j-berman/app-monero/commit/c1a6eb8bbbc1cc7974ce0938e9d8f920d0ad3ae9) + this code (https://github.com/j-berman/monero/commit/cfbd590fd63ff9e0c5ec68c618e2f3fdaf24d241). Working on the handoff with ledger
19:27:54 <selsta> .merge+ 8428
19:27:54 <xmr-pr> Added
19:37:47 <selsta> does this still seem relevant? https://github.com/monero-project/monero/issues/119
19:43:56 <hyc> probably hasn't been relevant in years
19:44:47 <moneromooo> I do not remember ever seeing this.
19:46:21 <hyc> nor I
19:46:45 <selsta> I'll close this
20:47:00 <selsta> hyc: is this still relevant with randomx? https://github.com/monero-project/monero/issues/4860 is this something that would have to be implemented in the monero repo?
20:47:13 <selsta> I'm not familiar with buildroot extension
20:56:24 <hyc> selsta the main point of that ticket was providing a monerod that can run on pi and other small single board computers
20:56:39 <hyc> since we have official arm linux binaries now, I think we can close this
20:57:16 <selsta> ok, sounds good
20:57:17 <hyc> might add a commene avout pinode 
20:57:22 <hyc> comment
20:57:26 <selsta> will do
20:58:05 <real_me[m]> I’m waiting for multisig fix to be merged on 0.18
20:58:32 <real_me[m]> Very excited
20:58:54 <hyc> it's merged already, no?
20:59:15 <selsta> multisig is still experimental and should only be used when all multisig participants are trusted
21:07:42 <dangerousfreedom> I think it would be interesting to post it here too:
21:07:47 <dangerousfreedom> https://github.com/monero-project/monero/issues/8438
21:11:01 <selsta> dangerousfreedom: would make sense to document all of these special tx in case someone works on an alternative implementation, though not sure where to write it down
21:13:14 <dangerousfreedom> I'm still working on my understanding, making stats and correlating the occurrences to be sure that it is a bug and not an exploit. I will provide my full result as soon as I have them! So far I would like to share my results as I believe that a community work would be faster and more productive to solve this issue.
21:13:47 <dangerousfreedom> (If there is an issue at all)
23:21:00 <selsta> .merge+ 8359
23:21:00 <xmr-pr> Added
23:23:43 <selsta> .merge+ 8352
23:23:43 <xmr-pr> Added