05:40:57 <binaryFate> v0.18.2.0 binaries are now online. Big thank you to all contributors
13:49:36 <greenpillow11[m]> https://github.com/monero-project/monero/blob/master/src/wallet/wallet_rpc_server.cpp#L71
13:49:36 <greenpillow11[m]> When will multisig wallet loose it’s ‘experimental feature’ status? Are there still many known bugs or is it secure already?  
15:27:01 <selsta> greenpillow11[m]: multisig needs security proofs and an audit
20:57:13 <jeffro256[m]> By the time that tx_memory_pool::init is called, its Blockchain member m_blockchain is already initialized correct?
20:58:32 <UkoeHB> jeffro256[m]: https://github.com/monero-project/monero/pull/8033
21:00:57 <UkoeHB> ah idk about the initialization order though
21:14:18 <jeffro256[m]> ```std::unique_ptr<Blockchain> core_storage;
21:14:18 <jeffro256[m]> tx_memory_pool m_mempool(*core_storage);
21:14:18 <jeffro256[m]> core_storage.reset(new Blockchain(m_mempool));```
21:14:38 <jeffro256[m]> lol how would that ever not cause a segmentation fault
21:17:14 <moneromooo> *core_storage yields a reference. It is not dereferenced.
21:23:25 <jeffro256[m]> 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
21:23:37 <jeffro256[m]> std::addressof(*std::unique_ptr<int>()) == nullptr
21:28:00 <moneromooo> Actually, the code you quoted does seem odd, due to the unique_ptr usage...
21:28:36 <jeffro256[m]> Oh that's because the reference never gets used... tx_memory_pool is never initialized 
21:31:31 <jeffro256[m]> I mean ::init() called, it is c++ initialized 
21:33:40 <jeffro256[m]> UkoeHB I'll review that PR later 
21:34:00 <jeffro256[m]> I remember seeing that a long time ago
21:35:19 <jeffro256[m]> 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
21:43:32 <jeffro256[m]> I say that... while having an open PR which expands the Blockchain class 
22:16:10 <zerodan[m]> Please review https://github.com/monero-project/monero/pull/8754
23:02:31 <jeffro256[m]> 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?
23:03:49 <jeffro256[m]> Like would RestOfTheChain <- Block (diff 100) <- Block(diff 100) ever reorganize to RestOfTheChain <- Block(diff 300)
23:05:39 <tevador> It's possible, but the reorg would have to be deeper than 15 blocks: https://github.com/monero-project/monero/blob/master/src/cryptonote_config.h#L82
23:08:17 <jeffro256[m]> // !!!
23:08:28 <jeffro256[m]> Haha thanks I'll take a look 
23:11:01 <jeffro256[m]> 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?
23:11:51 <sech1> actually much more than 15 blocks because there's also 60 blocks cutoff elsewhere
23:12:05 <sech1> so 75 blocks until difficulty actually starts to react to hashrate changes
23:14:47 <jeffro256[m]> Is that the DIFFICULTY_CUT value you're talking about?
23:14:58 <tevador> 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.
23:46:02 <jeffro256[m]> Why wouldn't it end up with fewer blocks? Wouldn't that cause hard forks dependent on when a certain node saw a block?
23:47:44 <jeffro256[m]> Nvm no it wouldn't 
23:51:44 <jeffro256[m]> 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?