libera #monero-dev

19 Jan 2025

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Monero GUI dev is at #monero-gui || Monero website dev is at #monero-site || Non-dev questions -> #monero, please || No fork help, you’re on your own

• 00:25
  tobtoht_
  merges this week would be phenomenal
• 00:25
  tobtoht_
  if time permits
• 00:25
  tobtoht_
  ping luigi1111
• 00:34
  luigi1111
  You have permissions now. I will try to merge Tuesday though
• 00:35
  tobtoht_
  am i allowed to merge queued prs if they are my own?
• 00:35
  tobtoht_
  that's all that's left
• 01:32
  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
  tobtoht_
  approvals and selsta already gatekeep what can be merged
• 01:32
  tobtoht_
  i don't see why it matters who ultimately presses the merge button
• 01:33
  tobtoht_
  this rule precisely hinders the dependency-hell maintenance i do - for no apparent benefit
• 01:33
  tobtoht_
  it's entirely bottlenecked by the speed of merges
• 03:22
  ofrnxmr
  .merges
• 03:22
  xmr-pr
  9453 9491 9523 9544 9643 9645 9646 9648 9650 9653 9666 9680
• 03:37
  ofrnxmr
  👍 9453 9491 9523 9544 9643 9645 9646 9648 9650 9653 9680(vtnerd comment) - do any need release versions? tobtoht_
• 03:42
  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
  tobtoht_
  thanks for going through the list
• 03:43
  ofrnxmr
  Thanks tob
• 13:58
  m-relay
  <e​veroddandeven:monero.social> Hey guys
• 14:01
  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
  m-relay
  <e​veroddandeven:monero.social> Only when outputs are too much and transaction would be too big?
• 14:15
  m-relay
  <m​onero.arbo:matrix.org> max outputs is 16, max inputs is limited by max transaction size... currently 140ish kB ?
• 14:16
  m-relay
  <m​onero.arbo:matrix.org> I think it's a little less than half of the current blocksize limit
• 14:56
  m-relay
  <e​veroddandeven:monero.social> is defined as `CRYPTONOTE_MAX_TX_SIZE` (`cryptonote_config.h`), right?
• 15: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
  m-relay
  <m​onero.arbo:matrix.org> github.com/monero-project/monero/bl…ter/src/cryptonote_core/tx_pool.cpp
• 15:23
  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
  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
  m-relay
  <o​frnxmr:monero.social> 100kb (2/3 of a 150kb max tx size limit)
• 20:10
  m-relay
  <o​frnxmr:monero.social> {I dont know why its 2/3}
• 20:12
  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
  moneromooo
  IIRC it's 2/3 to avoid the case where only one tx might fit, instead of 2. "Engineering tolerance".
• 20:34
  moneromooo
  Better than have 2 instead of 3. The "loss" is smaller. I don't remember any other reason.
• 20:35
  moneromooo
  It just might be always certain two would fit given the constraints the wallet uses, I am just not 100% sure.
• 20:36
  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
  moneromooo
  Don't think it does.
• 22:50
  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