00:25:24 <tobtoht_> merges this week would be phenomenal
00:25:28 <tobtoht_> if time permits
00:25:36 <tobtoht_> ping luigi1111
00:34:37 <luigi1111> You have permissions now. I will try to merge Tuesday though
00:35:04 <tobtoht_> am i allowed to merge queued prs if they are my own?
00:35:57 <tobtoht_> that's all that's left
01:32:02 <tobtoht_> i could be more productive if i didn't have to deal with the cognitive load of maintaining/rebasing 45 open prs
01:32:17 <tobtoht_> approvals and selsta already gatekeep what can be merged
01:32:29 <tobtoht_> i don't see why it matters who ultimately presses the merge button
01:33:00 <tobtoht_> this rule precisely hinders the dependency-hell maintenance i do - for no apparent benefit
01:33:24 <tobtoht_> it's entirely bottlenecked by the speed of merges
03:22:30 <ofrnxmr> .merges
03:22:30 -xmr-pr- 9453 9491 9523 9544 9643 9645 9646 9648 9650 9653 9666 9680
03:37:31 <ofrnxmr> 👍 9453 9491 9523 9544 9643 9645 9646 9648 9650 9653 9680(vtnerd comment) - do any need release versions? tobtoht_
03:42:10 <tobtoht_> 9643 would be nice to have on release because of bug fixes, but doesn't backport cleanly. I'll skip that one for now until I decide what to do for release.
03:42:23 <tobtoht_> thanks for going through the list
03:43:51 <ofrnxmr> Thanks tob
13:58:36 <m-relay> <e​veroddandeven:monero.social> Hey guys
14:01:06 <m-relay> <e​veroddandeven:monero.social> I have a question, what are the conditions for creating multiple transactions to satisfy a particular request to send funds from wallet?
14:06:30 <m-relay> <e​veroddandeven:monero.social> Only when outputs are too much and transaction would be too big?
14:15:47 <m-relay> <m​onero.arbo:matrix.org> max outputs is 16, max inputs is limited by max transaction size... currently 140ish kB ?
14:16:09 <m-relay> <m​onero.arbo:matrix.org> I think it's a little less than half of the current blocksize limit
14:56:02 <m-relay> <e​veroddandeven:monero.social> is defined as `CRYPTONOTE_MAX_TX_SIZE` (`cryptonote_config.h`), right?
15:21:21 <m-relay> <m​onero.arbo:matrix.org> I believe it's line 118 here: `get_min_block_weight(version) / 2 - CRYPTONOTE_COINBASE_BLOB_RESERVED_SIZE`
15:21:21 <m-relay> <m​onero.arbo:matrix.org> https://github.com/monero-project/monero/blob/master/src/cryptonote_core/tx_pool.cpp
15:23:01 <m-relay> <m​onero.arbo:matrix.org> CRYPTONOTE_MAX_TX_SIZE you referenced seems to be a max TX size since it's set to 1 million bytes eg almost a megabyte
15:23:59 <m-relay> <m​onero.arbo:matrix.org> CRYPTONOTE\_MAX\_TX\_SIZE you referenced seems to be an absolute limit on TX size since it's able to grow with block size
20:10:20 <m-relay> <o​frnxmr:monero.social> 100kb (2/3 of a 150kb max tx size limit)
20:10:39 <m-relay> <o​frnxmr:monero.social> {I dont know why its 2/3}
20:12:30 <m-relay> <o​frnxmr:monero.social> It depends on if you use a sweep, transfer_split or transfer. The former 2 will create more transactions, keeping each tx under 100kb
20:33:26 <moneromooo> IIRC it's 2/3 to avoid the case where only one tx might fit, instead of 2. "Engineering tolerance".
20:34:00 <moneromooo> Better than have 2 instead of 3. The "loss" is smaller. I don't remember any other reason.
20:35:36 <moneromooo> It just might be always certain two would fit given the constraints the wallet uses, I am just not 100% sure.
20:36:31 <moneromooo> I also can't recall whether the wallet "predicts" what the max block size might be in a few blocks, in case it goes down.
20:36:40 <moneromooo> Don't think it does.
22:50:07 <m-relay> <m​onero.arbo:matrix.org> interesting. one effect is that doing 2/3 (100 kB) makes sure there's leftover room for small/normal transactions