06:15:01 <jeffro256[m]> Is it normal to fail the functional_rpc_test related to stopping the miner? I figured maybe CI maybe blocking monero mining, but sometimes it works, other times it doesn't.
08:01:44 <moneromooo> Yes, unknown reason. Feel free to look at it, but it'll be unrelated to whatever you're changing.
13:56:13 <jeffro256[m]> thanks!
15:55:25 <Lib> hey guys, I am trying to understand how to see how much XMR is sent to a subaddress
15:55:30 <Lib> but it shows my balance as a whole
15:55:51 <Lib> how do i see how much each XMR went to each subaddress
16:06:20 <Lib> hi
16:06:59 <ndorf> type `balance detail` in the cli wallet. also wrong channel, use #monero
16:08:41 <Lib> ok sorry
16:08:44 <Lib> yea that works
16:08:55 <Lib> it shows the first 6 
16:09:08 <Lib> i tired balance detail
16:09:35 <Lib> i thouught i had to put blance and [x]
16:09:45 <Lib> instead of detail
16:09:49 <Lib> what that x was I dunno
16:10:55 <Lib> again thanks for your help
17:01:45 <Halver[m]> <moneromooo> "Now I'm wondering whether this..." <- apologies, but what is "cold signing" ? What's the difference with signing ? 
17:02:23 <Halver[m]> Would be very thankful for a link or a small explanation.
17:03:49 <merope> Signing a transaction on a computer that is permanently disconnected from the internet
17:06:26 <merope> You have a view-only wallet connected to the internet that scans the chain and creates the unsigned transaction, which you then export to the "cold wallet" on the airgapped computer and sign with the spend key. Once you've done that, you export the signed transaction back to the view-only wallet and submit it to the network
17:54:12 <bbqcore[m]> <merope> "You have a view-only wallet..." <- gotta pass outputs & key images first ;) 
17:55:04 <bbqcore[m]> seraphis will make it as simple as you describe IIRC
19:23:10 <jeffro256[m]> cryptonote_connection_context has three atomic members: m_callback_request_count, m_new_stripe_notification, and m_idle_peer_notification, which I will call A, B, and C, respectively. Currently, copy assignment and copy construction for cryptonote_connection_context is not thread-safe. For example, when we assign a cryptonote_connection_context to another, ccc1 = ccc2, the value of ccc2.B may change between the assignment of ccc1.A
19:23:10 <jeffro256[m]> and ccc1.B. Is this mitigated outside of the class?
19:36:49 <jeffro256[m]> Or rather I should say that the three members are of type epee::copyable_atomic, which is std::atomic<uint32_t> but with copy assignment and copy construction defined