02:08:09 <w[m]> Not sure if this is the wrong place
02:08:09 <w[m]> But regarding the 10 block unlock time
02:08:09 <w[m]> I noticed fixedfloat does 2 blocks. If it is of any consequence, I may ask them if theyve ever lost any monero due to the low confirmations.
02:08:09 <w[m]> I dont remember how many changenow, kraken etc use, but kucoin is 12
02:35:01 <BusyBoredom[m]> 10 block unlock time is enforced by consensus, it's the amount of time after receiving monero before you can spend it and there are no exceptions. 
02:35:01 <BusyBoredom[m]> The other numbers you're seeing are simply third parties saying "after X confirmations, well mark the transaction as complete". It doesn't mean they can spend it after 2 blocks, it just means they consider the transaction complete. 
02:35:01 <BusyBoredom[m]> This channel is intended for devs, so questions like this are best asked in channels like #monero:monero.social
03:47:50 <jeffro256[m]> Hey I've got a couple questions about Levin. Upon receiving a levin handshake request, does monerod always send back peer information in the payload?
03:48:37 <jeffro256[m]> Second: the Bender's nightmare signature must proceed  both the bucket and the payload, correct?
07:29:48 <w[m]> > <@busyboredom:monero.social> 10 block unlock time is enforced by consensus, it's the amount of time after receiving monero before you can spend it and there are no exceptions.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c119845f2dc1b20c02f9f9cbf50e87218f0912f4)
07:31:03 <w[m]> s/My question was misunderstood, was more wondering thebimplications of lowering the unlock time in the protocol, as if a company like ff accepts 2 conf tx id wonder how necessary 10 is / would it be worth looking into - but ill cont. in #monero:monero.social/My question was misunderstood, was more wondering thebimplications of lowering the unlock time in the protocol, as if a company like ff accepts/ is able to trust 2 conf tx, id wonder how
07:31:03 <w[m]> necessary 10 is / would it be worth looking into changing - but ill cont. in #monero:monero.social /
08:00:18 -xmr-pr- erciccione opened pull request #8222: [release-v0.17] replace erciccione's seednode with one on haveno's inf...
08:00:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8222
10:07:43 <selsta> w[m]: you are still mixing up two different things
10:08:26 <selsta> .merge+ 8222
10:08:26 <xmr-pr> Added
18:03:57 <jeffro256[m]> @selsta So my PR (https://github.com/monero-project/monero/pull/8211) has a merge conflict with PR #8186 (https://github.com/monero-project/monero/pull/8186). Luckily, It can be trivially resolved. Should I put that merge commit in my PR or let Luigi handle it?
18:04:16 <jeffro256[m]> luigi1112 ^
18:11:00 <luigi1112> rebase please
18:12:30 <mj-xmr[m]> Then you can ping me to re-review.
19:00:27 <jeffro256[m]> mj-xmr[m] Okay I rebased! I put  a comment in the PR how I did it so you can easily replicate and check it 
19:00:54 <jeffro256[m]> I just did git rebase --master and then deleted the 3 files that conflicted (they were deleted anyways in my PR)
19:16:56 <jeffro256[m]> Is there a reason that boost::interprocess::ipcdetail::atomic_(read/write/inc/sec)32 is used instead of boost::atomic or std::atomic in abstract_tcp_server2,  levin_protocol_handler_async, etc?
22:30:18 -xmr-pr- jeffro256 opened pull request #8223: Eliminate dependence on boost::interprocess
22:30:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8223