v0.18.2.0 binaries are now online. Big thank you to all contributors

When will multisig wallet loose it’s ‘experimental feature’ status? Are there still many known bugs or is it secure already?

greenpillow11[m]: multisig needs security proofs and an audit

By the time that tx_memory_pool::init is called, its Blockchain member m_blockchain is already initialized correct?

jeffro256[m]: monero-project/monero #8033

ah idk about the initialization order though

```std::unique_ptr<Blockchain> core_storage;

tx_memory_pool m_mempool(*core_storage);

core_storage.reset(new Blockchain(m_mempool));```

lol how would that ever not cause a segmentation fault

*core_storage yields a reference. It is not dereferenced.

Yes but its a reference to nothing, if it's stored and used later, when dereferenced it will seg fault, no? Unless I'm missing something else

std::addressof(*std::unique_ptr<int>()) == nullptr

Actually, the code you quoted does seem odd, due to the unique_ptr usage...

Oh that's because the reference never gets used... tx_memory_pool is never initialized

I mean ::init() called, it is c++ initialized

UkoeHB I'll review that PR later

I remember seeing that a long time ago

This stems from a design issue with Blockchain/tx_memory_pool, they shouldn't both need references to each other. The Blockchain class does way too much but oh well

I say that... while having an open PR which expands the Blockchain class

Please review monero-project/monero #8754

Another question: is it possible for a reorg to end up lowering the height of the chain if the difficulty of each block is just that much higher?

Like would RestOfTheChain <- Block (diff 100) <- Block(diff 100) ever reorganize to RestOfTheChain <- Block(diff 300)

It's possible, but the reorg would have to be deeper than 15 blocks: github.com/monero-project/monero/bl…/master/src/cryptonote_config.h#L82

// !!!

Haha thanks I'll take a look

Oh... You're saying it would only happen if the difficulty adjusted upwards enough from a reorg that the old blocks did not pass difficulty tests?

actually much more than 15 blocks because there's also 60 blocks cutoff elsewhere

so 75 blocks until difficulty actually starts to react to hashrate changes

Is that the DIFFICULTY_CUT value you're talking about?

I think it's technically possible to increase the difficulty with just over 15 blocks, but not enough to account for fewer blocks in the chain overall. The cutoff would only apply if the newly added timestamps are outliers.

Why wouldn't it end up with fewer blocks? Wouldn't that cause hard forks dependent on when a certain node saw a block?

Nvm no it wouldn't

So as a very messy, not well super well-defined rule of thumb, is it fair to say that the head of the chain is chosen by height in the short term, and cumulative difficulty in the long term?