14:58:16 <m-relay> <s​gp_:monero.social> I spoke with a few people at the finney forum this weekend about the monerod read locks, and I'm pretty confident that is the main thing slowing down the cake nodes
15:08:19 <m-relay> <s​gp_:monero.social> I believe this is the pr that was discussed https://github.com/monero-project/monero/pull/9181
15:09:02 <sech1> Did they test with 9181? Did it improve performance?
15:09:42 <m-relay> <s​gp_:monero.social> no, but they can. Is the issue you observed with the one cpu core pinned to 100% still present?
15:11:12 <sech1> It's not strictly 1 core, but when the node is synchronizing, it barely uses more than 1 CPU core
15:11:27 <sech1> When it's past checkpoints
15:11:40 <m-relay> <s​gp_:monero.social> cake solved its node issues for now by putting the entire blockchain in ram. that seems to have done the trick
15:12:01 <m-relay> <s​gp_:monero.social> but that's pricey long-term :p
15:34:44 <m-relay> <r​ucknium:monero.social> I'm not the only one who noticed that some txs with more than 5 inputs can appear in the txpool with a fee less than 20 nanoneros per byte. Is wallet2 making these txs? When the txpool has a backlog, these txs can stay in the txpool for hours. They sit in the "queue" below the 20 nanoneros/byte txs that are getting confirmed in the "first in, first out" rule of `get_block_template<clipped message>
15:34:44 <m-relay> <r​ucknium:monero.social> ` for txs that are on the same fee/byte level.
15:35:21 <m-relay> <r​ucknium:monero.social> For example, these txs waited over 24 hours to confirm, according to my txpool archive data:
15:35:30 <m-relay> <r​ucknium:monero.social> 32cbd8640fddcf7e9d449382a3d6a4521f065d90f27a7c72984ef2c6d690d5ff, 3adcbf45dc42971b11e159a02e2cce847e14504c826c9a3ff848908f4a5bcff2, bcf3f15f1a877a0be48ec5a498c4b92d5d3a3200db452b7ec615b59c08e07dd4, 1331e6554b2be45e7c2fa63faa9f125716d061165282bbc103e85c1b519acbfc, 914470815b33c90bcd53959bf2ef472726f520d18fbc78c6bbd07136ec93a30f, eca2315b48168bf2dbb686d8fbdf1bc1bf9f0849741ab32077a4e<clipped message>
15:35:31 <m-relay> <r​ucknium:monero.social> 973242b0982, 2c3c45238bcb2fefdccc0c0e0e49ea409ae8611d5c991dfecf7a4a6a7af911e9
15:36:20 <m-relay> <r​ucknium:monero.social> Their fee/weight is, respectively, 19959.70 19959.93 19940.11 19866.95 19874.59 19775.90 19664.40
15:37:40 <m-relay> <r​ucknium:monero.social> Is this undesirable behavior? Should I make an issue on GitHub? If these txs cannot have an exact 20 nanoneros/byte fee because of their unusual size, maybe they could have a slightly higher fee than 20 nanoneros/byte instead of slightly lower.
15:40:56 <moneromooo> Would this just not change which txes get to wait ?
15:42:39 <moneromooo> I guess a floor would just shuffle, since exactly 20 per weight-byte can be done, since it's a multiplication...
15:42:59 <m-relay> <r​ucknium:monero.social> It would reduce or eliminate extreme wait times in this circumstance. If it changed, the 20 nanoneros/byte txs would wait behind the unusual txs, but the 20 nanonero/byte txs would confirm in approximately the backlog time that `print_pool_stats` says.
15:43:22 <sech1> The problem is in the fee algorithm. Transaction weight is not transaction size for transactions with more than 1 input
15:43:40 <sech1> It does some rounding, and such transactions end up with less than 20
15:43:40 <moneromooo> In a set of txes, you'll always have one that's the last if all txes can be compared.
15:44:28 <sech1> Right now mempool clears regularly, so it's not urgent
15:45:06 <m-relay> <r​ucknium:monero.social> Yes, not urgent, but is it undesirable?
15:46:48 <m-relay> <r​ucknium:monero.social> I thought weight != size when number of _outputs_ is greater than 2.
15:49:24 <m-relay> <r​ucknium:monero.social> Zero to Monero 2.0 says "Transaction weight for a miner transaction (see Section 7.3.6), or a normal transaction with two outputs, is equal to the size in bytes. When a normal transaction has more than two outputs the weight is somewhat higher than the size."
15:53:33 <sech1> oh right, outputs\
15:53:54 <moneromooo> Weight is higher to account for BP's sublinear size vs verification cost.
15:54:21 <moneromooo> AFAIK this is the only case where weight is not equal to size.
17:50:17 <Pickchea> Hello, could anyone tell me what's the default limit for incoming connections and possibly tell me where to find that value in the code? I couldn't find it.
17:54:30 <sech1> Default is no limit
17:56:02 <Pickchea> sech1, thanks. I'm asking because the 2020 paper Exploring the Monero Peer-to-Peer Network says that the default is 1, which really can't be right. Right?
18:04:29 <sech1> it's probably a typo, default is -1 (unlimited)
18:06:11 <sech1> max connections per IP defaults to 1 though
19:23:00 <Pickchea> sech1, thanks! 
21:58:48 <jmjl> I was thinking, maybe radicle (https://radicle.xyz/
21:59:06 <jmjl> is usefull for self-hosting the monero project (related to https://github.com/monero-project/meta/issues/522)
21:59:38 <jmjl> but I'm not sure if it's possible or easy to use Tor with it
22:00:49 <jmjl> And well, maybe it makes the barrier to entry a bit too high, (if you guys decide to even use it, as it hasn't officially been released yet, https://radicle.xyz/faq#who-is-using-radicle-currently-how-many-users-does-it-have
22:02:59 <jmjl> well, and it being related with radworks (which funds itself on the $RAD token, which is another crypto currency), so maybe it's not a good idea?