Fluorine Fermi v0.18.0.0 binaries are online!!

Massive thank you to all contributors

And thanks to everyone who contributed hashes for the deterministic builds

huzzah! congrats all!

Awesome :)

w00t

Woooo

Congrats all! This time I'll be around for the hard fork exciting!

<binaryFate> "Fluorine Fermi v0.18.0.0..." <- thanks. just missing the github release :)

moneromooo: I can check them

ok so the issue is DNSSEC right?

all seems correctly configured per Verisign

might be the DNSSEC verifier code that is bust

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

*few years ago

fluffypony paste.debian.net/hidden/69c8e330

"no DNSKEY rrset for trust anchor . while building chain of trust"

ok so that's the root domain

the way DNSSEC works is it only has one key hardcoded, the one for .

then it checks the trust anchor for .net based on the trust anchor for .

then the trust anchor for moneropulse.net, and then for updates.moneropulse.net

so if it's failing on . that means that either your ISP isn't serving DNSSEC records when requested, OR the utility is busted

This is on Hetzner server

hmmm where is monero-utils-dns-check - it's not part of the binary package, right?

WOW monerod shuts down way way way faster in 0.18

awesome work

monero-utils-dns-checks

it's built in debug builds

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.

yes

It'll be in reference to the calcification of emission schedule.

found this piece of history: bitcointalk.org/index.php?topic=962235.msg10683368#msg10683368

johnfoss68[m]: yes

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%.

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."

Thanks guy! 👍

guys*

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

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?

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

i will paste it there

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

I just posted the answer to that question in #monero:monero.social

The error should probably be updated to reflect the new minimum version

(can't visit the link because i wasn't in the room before that)

Initially scheduled for July 20:... (full message at libera.ems.host/_matrix/media/r0/do…a1af0e84cf94d9d8fa4763aa7b3f86bc346)

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 ^)

hyc I saw this comment on an old bitcoin issue (#18916):

> 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.

what's the status on that?

The LMDB code has been ready for literally years. nobody has worked on migrating the wallet to use LMDB

TheCharlatan: probably it won't happen unless some exchanges put up a bounty, since they'll benefit the most from the perf gain

seed node ops, update ure seed nodes :)

HenryHollingwort: Ledger users have to wait with the update, they didn't put out an update yet.

0.18 outputs some irrelevant (unless debugging) error: duplicate key: node_data. I suggest paste.debian.net/hidden/42dc99e8 (untested).

Just one so far, right at the start, so it might be less spammy than I thought it'd be.

didn't see this yet

could it be a peer that uses custom code?

Yes.

i got that basically the moment i started up 0.18 paste.debian.net/hidden/2428e7c5

oh yeah, I got that here too, on my arm64 box

also got it ~12 hours after starting on my linode. July 17.

july 17 5am, july 18 2:47 on my arm64 box

can someone get the IP from this peer when using log level 2?

Could someone with monero-announce access please announce the new release? That's the only missing announcement item from monero-project/meta #690.

And has anyone performed testnet Ledger/Trezor testing? I think jberman has done Ledger but want to confirm before I check those off.

And if anyone knows if these unchecked items have been done yet, please let me know.

ledger / trezor code is not included yet in this release

moneromooo I don't think it's safe to redefine MONERO_DEFAULT_LOG_CATEGORY inside a header file

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.

It is safe, since it just redirects the category. cpp files #define this after all header includes.

There are already headers that do this, due to epee's header heavy design.

if cpp files redefine it then ok

The worst you get is an unexpected default category, which should be trivial to fix.

Most do.

binaryFate has to send a monero-announce mail

(and should)

selsta: Figured but wasn't sure, thanks, selsta!

Seth For Privacy: I created testnet txs with a ledger with this code (j-berman/app-monero c1a6eb8) + this code (j-berman/monero cfbd590). Working on the handoff with ledger

.merge+ 8428

Added

does this still seem relevant? monero-project/monero #119

probably hasn't been relevant in years

I do not remember ever seeing this.

nor I

I'll close this

hyc: is this still relevant with randomx? monero-project/monero #4860 is this something that would have to be implemented in the monero repo?

I'm not familiar with buildroot extension

selsta the main point of that ticket was providing a monerod that can run on pi and other small single board computers

since we have official arm linux binaries now, I think we can close this

ok, sounds good

might add a commene avout pinode

comment

will do

I’m waiting for multisig fix to be merged on 0.18

Very excited

it's merged already, no?

multisig is still experimental and should only be used when all multisig participants are trusted

I think it would be interesting to post it here too:

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

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.

(If there is an issue at all)

.merge+ 8359

Added

.merge+ 8352

Added