13:16:49 <MohammedMujahid[> Please help me. I have withdrawn XMR From binance to my gui wallet but still it has not come please help
13:17:02 * MohammedMujahid[ uploaded an image: (51KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/uWEslnPrZoVdOiVQSMTVMrsh/20211119_181655.jpg >
13:17:07 <dEBRUYNE> MohammedMujahid[: https://monero.stackexchange.com/questions/6640/i-am-missing-not-seeing-a-transaction-to-in-the-gui-zero-balance
13:26:27 <rbrunner> Interesting view on testnet: Somebody tries out big transactions :) https://testnet.xmrchain.com/
13:31:48 <sethsimmons> <rbrunner> "Interesting view on testnet..." <- 3TX per block 😅
13:32:54 <sech1> They could've made bigger transaction with this simple wallet2.cpp change...
13:33:30 <rbrunner> Stress tests always welcome, I guess
13:33:58 <nikg83[m]> Can they do the same on mainnet?
13:34:07 <sethsimmons> Similar tactic was used on mainnet not too long ago, could be prep for another "attack" or just someone playing around.
13:35:12 <rbrunner> Yesterday was difficulty adjustement day, because mining went from about 8 kH/s to about 2 kH/s, and difficulty still has not yet fully adjusted
13:35:27 <Rucknium[m]> In all honesty, we may want to examine maximum tx size. Having only 3 tx in a block may be a problem for decoy selection, not to mention verification times
13:36:09 <rbrunner> Lol. Professional hazard: Immediately seeing statistical problems everywhere :)
13:36:21 <rbrunner> (Just joking)
13:36:36 <Rucknium[m]> That's...why I'm here ;)
13:36:37 <sethsimmons> Rucknium[m]: This isn't the max, it would adjust over time.
13:37:04 <MohammedMujahid[> Is this node safe http://opennode.xmr-tw.org:18089
13:37:06 <sethsimmons> Oh, you mean limiting TX size further
13:37:38 <merope> Is there any relistic scenario in which a user might need a tx with 194 inputs?
13:37:42 <Rucknium[m]> sethsimmons: Right. Maybe we should consider its implications.
13:37:58 <sethsimmons> merope: Yes, sweeping p2pool payouts.
13:38:06 <sethsimmons> Can speak from experience 🙃
13:38:32 <merope> Hmmm, didn't think of that
13:38:38 <Rucknium[m]> But frankly they could do that with a series of smaller txs. 
13:38:42 <sethsimmons> Obviously that could be broken up into more transactions, but that's not uncommon for those mining p2pool with smaller hashrates.
13:38:57 <sethsimmons> I already had to split out into multiple transactions...
13:39:16 <merope> Those are coinbase transactions though, so they could be treated as an exception? (Assuming they're not already)
13:39:31 <sethsimmons> merope: Hmm, that would be an interesting exception.
13:41:56 <merope> Do we already have some statistics on tx count vs input number? Perhaps we could introduce a 50-100 input limit per transaction
13:42:27 <Rucknium[m]> On Townforge, there is still a limit to the number of coinbase outputs that can be consolidated. It might not be a number limit; maybe a total tx size limit.
13:42:33 <sech1> "Yesterday was difficulty adjustement day, because mining went from about 8 kH/s to about 2 kH/s" that's the answer. Someone was mining on testnet for a long time and is now consolidating
13:42:48 <Rucknium[m]> merope: neptune could help with that.
13:43:28 <merope> That way if a pool or an exchange need to consolidate lots of input they still can, while leaving some room in the block for more transactions 
13:43:45 <Rucknium[m]> I mean I could help with that too. What stats do you want, exactly?
13:45:39 <merope> I think a simple histogram of the number of inputs per transaction would suffice (not sure what to choose as a starting point for the window)
13:46:07 <Rucknium[m]> It's discrete, so we can just have a table.
13:46:30 <Rucknium[m]> What time period? Between which block heights would you want?
13:46:50 <merope> Sorry, my stats language is a bit poor xD
13:47:11 <merope> Perhaps since block 2210000? The advent of CLSAG
13:47:33 <Rucknium[m]> Ok. Coming right up...
13:47:41 <merope> Or maybe 2210720, to exclude the last mlsag stragglers
13:48:13 <Rucknium[m]> neptune 's database stops in Sept I think, since it was last built to examine the summer tx volume anomaly.
13:49:44 <merope> That would mean ~11 months worth of transactions - should be rappresentative enough, right?
13:55:17 <Rucknium[m]> There are 5 txs with 1245 inputs. More stats incoming...
13:56:27 <merope> woah, that's massive
13:57:15 <Rucknium[m]> That seems like it may be the max. Here's what the bottom of the table looks like
13:58:02 <Rucknium[m]>       973       1
13:58:02 <Rucknium[m]>      1047       1
13:58:02 <Rucknium[m]>      1243       1
13:58:02 <Rucknium[m]>      1245       5
13:58:20 <Rucknium[m]> I can try to track down the hash of one of those txs....
14:03:12 <Rucknium[m]> Check out block 2006386. There's two 1245in txs, plus coinbase, and that's it. Actually that was before your time window. One sec..
14:04:44 <Rucknium[m]> ec646bdcfa905358209abd486de4fbabfe50cb1e83f8375058a3f7a69650a1f5
14:04:51 <Rucknium[m]> ^ Not RingCT, though
14:05:35 <merope> Yeah, neither are the two from block 2006386
14:05:52 <Rucknium[m]> 29eb6e840f9b41a0f659b43b0dcad36f368d2b021109f3e31e15d33f8aceae47
14:06:09 <Rucknium[m]> ^ Another non-RingCT 🤔
14:08:53 <Rucknium[m]> I checked all 5 of those 1245in txs, and none of them are RingCT
14:09:51 <Rucknium[m]> The 5 that are in the >= 2210720 block height time window, that is
14:11:46 <merope> Aside from these few massive ones, what's the distribution like for the others? For instance, how many transactions have more than 100 inputs relative to the total?
14:15:04 <Rucknium[m]> Should I exclude RingCT txs to answer your question?
14:15:37 <Rucknium[m]> I mean NON-RingCT txs
14:18:56 <merope> Hmmm... I say let's include them: there might still be some old pre-ringct outputs that might need conversion, so we could still see some massive txes like that in the future. If there's a significant portion of transactions like that, it might justify a higher input limit
14:22:02 <Rucknium[m]> This analysis is being conducted on gingeropolous 's server, by the way. Thanks, gingeropolous !
14:29:02 <neptune> Rucknium[m]: try table "tx_attribute_2489999", each row is a transaction, there is a column "tx_n_inputs" for number of inputs, and it goes up to block 2489999. 
14:32:39 <Rucknium[m]> neptune: Thanks! All columns or no?
14:36:07 <Rucknium[m]> Ok, I will load all the columns. R shall eat zee RAM.
14:42:44 <neptune> Rucknium[m]: all columns for what? if they're not part of your histogram I wouldn't SELECT them
14:45:30 <Rucknium[m]> Too late. 
15:04:18 <Rucknium[m]> endor00: See 
15:04:18 <Rucknium[m]> https://github.com/Rucknium/misc-research/blob/main/Monero-transaction-inputs-stats/height-2210720-to-2489999.csv
15:24:04 <rbrunner> In moneromooo 's Pay for RPC system it costs COST_PER_BLOCK = 0.05 to fetch a single block from the daemon over RPC, but 10 times more COST_PER_TX = 0.5 to get a single tx
15:24:40 <rbrunner> For the per-tx cost it does not matter whether it comes from the blockchain or the pool
15:25:13 <rbrunner> As `wallet2` gets most of the txs currently in the pool at every refresh, that must get terribly expensive
15:25:35 <rbrunner> Any idea why fetching txs should be so expensive in Pay for RPC?
15:37:21 <rbrunner> (I am aware that it's hardly used, if at all, but I don't want to be the one to break it with changes I currently do connected with fetching of pool txs.)
15:39:20 <gingeropolous> from what i remember, the cost is proportional to the actual computational resources used to perform the actions
15:42:02 <rbrunner> Yes, that's also my understanding of the situation, and that's why I wonder: I claim it's nowhere 10 times more resource-intensive to get a tx from the blockchain than a full block
15:44:57 <rbrunner> And imagine the wallet syncing, needing one block, and seeing 100 tx in the pool: Cost is 0.05 for the block and 50 to fetch those pool txs ...
15:52:21 <rbrunner> Maybe I will initiate the greatest cost reduction in the history of Monero: Fetching txs over RPC ten times cheaper now :)
15:55:59 <merope> Is there a way to measure (more or less accurately) the actual resources consumed by each request? (cpu cycles, ram, i/o, whatever)
15:57:50 <rbrunner> Hmmm, I guess there must be. But I imagine that's not simple, e.g. because so much is happening at the same time, within multiple threads within the daemon
16:02:52 <atomfried[m]> from my experience, messuring memory while running is a real pain in the ass...
16:07:33 <rbrunner> The current costs look like guestimates, but as moneromooo almost always delivers solid work I am pretty sure there is an "idea" behind txs being expensive.
16:07:54 <rbrunner> Maybe they will chime in later, taking a break from Townforge ...
16:11:33 <sethsimmons> So what are we waiting on for scheduling 0.18 HF? Would it be best if I start up a new meta issue to finalize discussion of the key items?
16:16:02 <Rucknium[m]> That sounds fine. It seems that no one(s) have taken the initiative to determine scheduling, so you could take such initiative :)
16:16:48 <luigi1111> March?
16:17:25 <sethsimmons> I don't have much free time but will try to hash out some details in an issue we can use moving forward.
16:17:32 <sethsimmons> ANd yes, I think an early-Spring HF is ideal.
16:19:38 <sethsimmons> What are the main features being included outside of ring size increase and view tags? ANything else worth mentioning? Was there a decoy selection change from jberman?
16:20:29 <rbrunner> Yeah, maybe their "simple binning" wallet-side is so good that we want that in
16:20:46 <rbrunner> That was jberman, right? Not sure
16:20:56 <Rucknium[m]> Seth For Privacy: Keep in mind that, generally, changes to the decoy selection algorithm do not require a hard fork since it is a wallet-level feature.
16:21:15 <Lyza> BP+?
16:21:19 <Rucknium[m]> Binning has not yet been vetted by a statistician.
16:21:25 <sethsimmons> IIRC there was something specifically that would be best done as part of a HF.
16:21:39 <sethsimmons> Lyza: Yes, thanks
16:21:52 <sethsimmons> And fee changes
16:22:09 <Lyza> yeah decoy selection via wallet doesn't need to be doned via HF but there was concern about having people using different selection algos
16:22:14 <Lyza> fee changes very important ya
16:22:22 <Rucknium[m]> Seth For Privacy: It's true that bundling decoy selection changes with hard forks can be useful since a HF is a forced upgrade.
16:22:47 <rbrunner> UkoeHB 's more robust multisig wallet construction, and some other PR still on the way to prevent an attack, as per Wednesday's MRL meeting
16:23:15 <sethsimmons> Does that require HF or will that be part of a point release/
16:23:56 <rbrunner> Not sure, but seems to me the best time to put something like that into service is a HF, like for decoy selection changes
16:25:49 <rbrunner> Maybe there are smaller things that only went into master so far, but not the 0.17 release branch. Don't have an overview, selsta may know more. Maybe more like improvements and optimizations
16:26:44 <Rucknium[m]> ArticMine suggested that the ring size increase be leveraged to gather additional statistical information for OSPEAD development. I agreed, so as of now about 1/3 to 1/4 of the tail end of OSPEAD work will take place after the HF.
16:31:28 <sethsimmons> https://github.com/monero-project/meta/issues/630
16:31:45 <sethsimmons> Please let me know if I missed anything, and we can start using that as a reference while planning.
16:37:45 <sethsimmons> Friendly reminder that we have a release checklist, but it could probably use some updates/more review: https://github.com/monero-project/monero/blob/master/docs/RELEASE_CHECKLIST.md
16:37:46 <sethsimmons> We can use that for the v0.18 release that enforces v15 hard-fork.
16:59:44 <merope> > <@rucknium:monero.social> endor00: See 
16:59:44 <merope> > https://github.com/Rucknium/misc-research/blob/main/Monero-transaction-inputs-stats/height-2210720-to-2489999.csv
16:59:44 <merope> Thanks!
17:00:24 <merope> Looking at the cumulative frequencies, I'd say that limiting transactions to 100 inputs should be fine
17:00:24 <merope> https://paste.debian.net/hidden/df29421a/
17:01:08 <merope> It covers (almost) 99.9% of all transactions within our sample
17:02:20 <monerobull[m]> merope: Sad p2pool miner noises
17:02:30 <merope> And almost all of the ones excluded are the few thousands of 185-194 inputs
17:03:24 <Lyza> looking at more recent data would give a better accounting of p2pool users
17:03:31 <merope> monerobull[m]: Actually, now that I think about it, p2pool would not be affected at all. We're talking about inputs here, not outputs
17:03:48 <Lyza> yeah but p2pool miners often have many outputs to consolidate
17:04:06 <merope> "Many" - more than 100?
17:04:27 <merope> And even if so, it would take at most a couple of transactions to do that
17:04:46 <monerobull[m]> Well we're not going to get big players to join p2pool if sending coins to a private wallet becomes a full-time job
17:05:23 <monerobull[m]> I needed to send 3 separate transactions to get 10$ worth of xmr out of my mining wallet
17:05:44 <Lyza> p2pool pays out every block and there's a block ever 2 minutes if you're 1/3 of the hashrate that's 240 outputs per day
17:05:46 <merope> How many inputs did those have in total?
17:05:59 <nero-cultist[m]> Monero's Algo kinda makes it pointless to mine for 99% of users 
17:06:05 <nero-cultist[m]> And botnets amplify this 
17:06:28 <merope> nero-cultist[m]: That has nothing to do with the algo, nor the discussion at hand
17:06:28 <nero-cultist[m]> Sure maybe the 1% of users with a Ryzen CPU can enjoy it 
17:06:37 <monerobull[m]> Saying "we shouldn't care about miners" is not really helpful
17:06:45 <nero-cultist[m]> ...
17:06:59 <nero-cultist[m]> Okay what ever  
17:07:07 <nero-cultist[m]> Continue without my complaints 
17:07:32 <Lyza> could we do something to make consolidating coinbase outputs more efficient?
17:07:39 <Lyza> compared to normal TX
17:07:44 <Rucknium[m]> monerobull: Let's write a little script to do multiple consolidation txs
17:08:00 <merope> monerobull[m]: Never said that - I'm asking you to quantify how many inputs did you have to consolidate, to get a better idea of the issue at hand
17:08:07 <Rucknium[m]> Huge txs may be a threat to user privacy due to decoy selection issues
17:08:34 <merope> That was the whole point of getting tx data in the first place - see how many transactions would be affected by a given input limit
17:08:53 <monerobull[m]> merope: I had like 200 incoming transactions after mining for a month and i am a thousand times smaller than the big miners
17:09:15 <Lyza> what is the first spend of a coinbase TX just didn't use ring sigs. the amount and stuff is already transparent right? so the first spend of a coinbase TX become a sort of blinding TX then you use it normally afterwards
17:09:44 <Lyza> what if*
17:10:15 <monerobull[m]> Doesnt p2pool send out payments the block after a block is found?
17:10:33 <Lyza> nah it pays out in the coinbase tx
17:10:49 <Lyza> splits the coinbase reward into a bunch of outputs
17:10:56 <Rucknium[m]> Lyza: That doesn't address the decoy selection issues. The decoy selection issue is that when there are huge txs, they can fill up the whole block, which drastically reduces the number of decoy outputs that can be pulled from that block
17:11:06 <sethsimmons> No, in the block you find.
17:11:08 <sethsimmons> Yeah
17:11:20 <Lyza> <Rucknium[m]> would the transactions not be much smaller without ring sigs attached?
17:11:23 <sethsimmons> Rucknium[m]: Feather already automates sending multiple TXs if the coins being swept are too large for one.
17:11:35 <sethsimmons> Max seems to be ~194 inputs for whatever reason.
17:11:43 <sethsimmons> Lyza: Yes
17:12:21 <Rucknium[m]> Lyza: I don't think coinbase txs have any ring sigs. 
17:12:45 <Rucknium[m]> Aren't coinbase tx amounts transparent?
17:12:53 <Lyza> I'm suggesting to take away ring sigs from transactions that use only coinbase outputs as inputs
17:12:57 <Lyza> yes they are
17:13:12 <monerobull[m]> This is getting too technical for me. Just wanted to make a point how restrictions like these can really harm the project in the future through ways one might not even think about
17:13:36 <sethsimmons> They still use rings, sgp_ has suggested for a while not using rings for coinbase outputs, or using only coinbase outputs in coinbases rings.
17:14:20 <merope> monerobull: so with an 100 input limit, it would take you 2 transactions to consolidate all your mining inputs
17:14:24 <Rucknium[m]> sethsimmons: That would make especial sense with p2pool use rising.
17:16:51 <monerobull[m]> merope: I get like 1 share every two days if in lucky
17:17:57 <monerobull[m]> But the big guys who get like 10 or more shares per 12 minute interval would need many, many transactions
17:18:46 <sethsimmons> As long as the wallet software can automatically handle splitting 100s of outputs into multiple TXs, the limit doesn't really matter TBH.
17:18:54 <sethsimmons> Feather already does this, not sure on GUI/CLI.
17:19:01 <Rucknium[m]> Those big guys should write a script. This may be a user privacy issue, which should take priority over miner UX issues.
17:19:12 <monerobull[m]> The guy didn't even tell me what the problem was
17:19:16 <sethsimmons> Lets move this convo to #monero-research-lounge:monero.social, though, not really dev related.
17:19:34 <Rucknium[m]> Or, as Seth indicates, use a wallet like Feather.
17:20:32 <monerobull[m]> Rucknium[m]: Youre not going to get p2pool adoption if it's way easier to just stay in centralized pools
17:27:24 <sgp_> <Rucknium[m]> "That would make especial sense..." <- in what way is this especially necessary with p2pool use rising?
17:29:28 <Rucknium[m]> sgp_: More small coinbase payouts
17:30:14 <sgp_> Rucknium: number of coinbase outputs are consistent though. p2pool miners and pool miners alike get C+1 outputs though
17:31:07 <sech1> sethsimmons maximum of 194 inputs comes from wallet2.cpp tx size limitation, it can be changed in the code
17:31:13 <sech1> not a part of consensus
17:31:15 <Rucknium[m]> sgp_: Looks like I'm wrong, then. What is C+1?
17:31:26 <sech1> max transaction size that monerod will accept is 1,000,000 bytes
17:31:56 <sgp_> 1 sec let me look more closely
17:31:58 <Rucknium[m]> sech1: What is the max tx size enforced by consensus?
17:32:04 <sech1> 1e6 bytes
17:32:33 <sech1> #define CRYPTONOTE_MAX_TX_SIZE 1000000
17:33:11 <Rucknium[m]> sech1:  Current max block size?
17:33:19 <sech1> 300kb
17:33:32 <sech1> so it won't be mined even if it's in mempool
17:33:37 <sech1> until blocks increase in size
17:35:27 <Rucknium[m]> To me, this is a privacy problem since decoy selection needs recent outputs to include in rings as decoys.
17:36:26 <Rucknium[m]> If blocks are full of just a few huge txs, decoy selection will be off kilter
17:37:44 <Rucknium[m]> And we saw this happen a month or two ago when we saw low-resource nodes struggling to keep up with those blocks that had a few huge txs. Seth For Privacy  and others were reporting on it.
17:38:21 <luigi1112> few huge or many small shouldn't be particularly different for low resource nodes
17:39:22 <Rucknium[m]> Did we ever get to the bottom of why nodes were struggling with those txs?
17:45:27 <UkoeHB> Maybe the threadpool in `verRctNonSemanticsSimple()` got too slammed.
17:45:53 * sgp_ uploaded an image: (52KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/BXLfHhvpcUfQeydGxGDNyzEs/image.png >
17:45:53 <sgp_> is this accurate?
17:47:26 <sethsimmons> sgp_: Looks correct to me.
17:49:55 <sgp_> given that as correct, there's no incremental concern with coinbase outputs with p2pool
17:50:59 <sgp_> if anything, it makes the selection of C+1 outputs more convincing as decoys
17:52:03 <nero-cultist[m]> Can we get back to talking about random x?
17:52:19 <nero-cultist[m]> There's a chip shortage making buying random x hardware near ASIC territory 
17:52:36 <nero-cultist[m]> 2 mobos
17:52:42 <nero-cultist[m]> 2 high end cpus
17:53:10 <nero-cultist[m]> It's nearly profitable or viable for people trying to support the network at a loss 
17:53:32 <nero-cultist[m]> What could be the cause ? 
17:53:36 <nero-cultist[m]> Botnets ? 
17:53:51 <nero-cultist[m]> The Algo it's self preferring new cpus from a specific manufacturer
17:53:53 <nero-cultist[m]> ?
17:54:05 <sgp_> mining is supposed to be a boring commodity, especially when CPUs can be spun up or turned off on a whim
17:54:13 <sethsimmons> Not the room for that, use #monero-pow:monero.social.
17:54:28 <sgp_> yeah
17:54:31 <sethsimmons> Or #monero:monero.social.
17:54:41 <nero-cultist[m]> ??????
17:54:49 <nero-cultist[m]> I'm suggesting a change to the developers 
17:55:18 <sgp_> when you have a specific change you can suggest it here, the current discussion is just about mining
17:55:20 <UkoeHB> What change exactly?
17:55:53 <nero-cultist[m]> A bottle neck for CPUs especially older ones is the cache 
17:55:56 <sethsimmons> A new algo that fits his needs 🙃
17:56:14 <nero-cultist[m]> sethsimmons: I have access to a Ryzen CPU
17:56:18 <nero-cultist[m]> ??????????
17:56:21 <sethsimmons> Go to one of the rooms mentioned, please.
17:56:35 <nero-cultist[m]> Our coin isn't infallible you know. 
17:56:38 <sethsimmons> This convo has nothing do with active development or any specific proposal.
17:56:42 <nero-cultist[m]> ....
17:57:20 <sgp_> Seth is right, start there and come back when you have a specific spec change or something
17:57:26 <nero-cultist[m]> I did 
17:57:30 <sethsimmons> We will gladly discuss it elsewhere, stop cluttering this room please 🙂
17:57:35 <nero-cultist[m]> A scratch pad size change. 
17:57:48 <nero-cultist[m]> Along with reductions to cache usage 
17:58:11 <nero-cultist[m]> Think like randomwow
17:58:21 <luigi1111w> take it to #monero-pow or #monero
17:58:32 <nero-cultist[m]> Kk
17:58:36 <luigi1111w> thanks
17:59:11 <sethsimmons> luigi1111w has the power, I guess 😀
18:04:10 <Rucknium[m]> endor00: I think we should make a GitHub issue exploring a reduction in the max input number and/or tx size. I'm not sure if its better as a /Monero issue or or /MRL issue
18:08:20 <sethsimmons> MRL, I would imagine, as it needs further research and reasoning.
18:14:51 <nioc> luigi1112> few huge or many small shouldn't be particularly different for low resource nodes <<>> yet it does
18:15:03 <nioc> *is
18:15:48 <sethsimmons> Yes, it crashed one of my nodes and ate 100% CPU and 100% RAM on the other till processed when we had the flood of large TXs.
18:16:00 <sethsimmons> I believe the issue was fixed since, though, selsta would know.
18:16:23 <wfaressuissia> "Yes, it crashed one of my nodes and ate 100% CPU and 100% RAM on the other till processed when we had the flood of large TXs." there is 100MB limit for packet size
18:17:27 <wfaressuissia> max number of connections of in/out connections should be chosen properly in order to have enough memory in the worst case (100MB * 2 * (in + out) + ... < RAM)
18:18:48 <wfaressuissia> it's stupid to touch (limit number of in/out) consensus where it can be solved with better code without any hf
18:21:18 <Rucknium[m]> wfaressuissia[m]: Better code doesn't solve the potential privacy issue.
18:22:36 <wfaressuissia> your reply isn't concrete, what do you mean ?
18:23:31 <Rucknium[m]> If consecutive blocks are filled with a few large transactions, that could mess up how the decoy selection algorithm is supposed to protect privacy.
18:23:38 <sethsimmons> <wfaressuissia[m]> "max number of connections of in..." <- is this done automatically, or still need to be done?
18:23:56 <Rucknium[m]> Since there will be few outputs to choose from in recent blocks
18:27:32 <wfaressuissia> "is this done automatically, or still need to be done?"  number of out peers is fixed by default, number of in peers is unlimited by default. These connection limits should be set manually by user
18:28:37 <sethsimmons> Would anyone here be able to run a meeting around HF planning? https://github.com/monero-project/meta/issues/630
18:28:48 <sethsimmons> Meetings are tricky for me with day job, so would be best if someone else could.
18:31:03 <wfaressuissia> There are many other problems in monerod that can't be mitigated with more resources dedicated to monerod. It requires almost complete rewrite with another design
18:31:49 <wfaressuissia> Current p2p network is working only due to ~5 large mining pools that are being operated by humans 24/7
18:32:16 <wfaressuissia> If someone want to remove big mining pools then firstly write software properly so that in can work automatically without human in the loop
18:35:21 <wfaressuissia> "If consecutive blocks are filled with a few large transactions, that could mess up how the decoy selection algorithm is supposed to protect privacy." it's problem with implementation of decoy selection
18:36:14 <wfaressuissia> general purpose implementation should work with any number of txs per block
18:39:23 <Rucknium[m]> No, because decoy selection is based on economic behavior. We shouldn't try to bend decoy selection around a "features" that a tiny, tiny proportion of users use.
18:39:51 <Rucknium[m]> Decoy selection is critical for user privacy. User privacy is Monero's #1 feature.
18:52:36 <wfaressuissia> "We shouldn't try to bend decoy selection around a "features" that a tiny, tiny proportion of users use." proof
18:53:56 <Rucknium[m]> wfaressuissia[m]: I produced proof a mere 4 hours ago:
18:53:56 <Rucknium[m]> https://github.com/Rucknium/misc-research/blob/main/Monero-transaction-inputs-stats/height-2210720-to-2489999.csv
18:54:14 <carrington[m]> Don't we often get empty blocks with no transactions anyways? 
18:54:51 <carrington[m]> So "big transaction mean fewer transactions" is part of a broader problem with decoy selection
18:55:01 <Rucknium[m]> carrington[m]: I don't think so. I could check though.
18:55:48 <carrington[m]> Although I agree there should be some sensible limit on transaction size. P2pool does seem to complicate things
18:58:00 <Rucknium[m]> If I understood the conversation earlier, max tx size is now three times larger than max block size.
18:59:15 <nioc> effective tx size is 1/3 blocksize
19:01:00 <nioc> empty blocks can happen when blocks are a few seconds apart
19:01:35 <sethsimmons> <sech1> "#define CRYPTONOTE_MAX_TX_SIZE 1..." <- Yes, this is 1/3 current median block size limit
19:01:54 <sethsimmons> You can see this from the recent testnet blocks with only 3 TX + coinbase in them.
19:02:29 <sech1> it's not 1/3
19:02:32 <Rucknium[m]> Oh, oops my mistake, that is 1/3 and not 3/1.
19:02:33 <sech1> it's 1 million bytes
19:02:55 <sethsimmons> Which equates to ~1/3  right now?
19:03:07 <sethsimmons> I know it's not coded as 1/3
19:03:08 <wfaressuissia> no
19:03:18 <sethsimmons> Oh
19:03:21 <sethsimmons> I misread
19:03:31 <wfaressuissia> 300KB blocks size limit, actual block can be up to 2x300KB with reward penalty, txs size limit is 1MB
19:03:59 <sech1> tx size limit is calculated as (block_size_limit / 2 - 600) * 2/3
19:04:03 <sech1> in wallet2.cpp
19:04:18 <sech1> which equates 99600 bytes currently
19:04:30 <UkoeHB> that is just a wallet barrier, not consensus
19:04:42 <sech1> consensus is 1,000,000 bytes
19:04:45 <sethsimmons> https://testnet.xmrchain.com/block/1856285
19:04:46 <sethsimmons> Ahhh
19:05:17 <sech1> the limit in wallet2 is soft - it can add more inputs above 99,600 bytes to pay fees
19:05:18 <sethsimmons> Got it
19:05:18 <Rucknium[m]> UkoeHB: Yes, that's what I am concerned about. What if someone spams huge txs and mines them, or can just broadcast them and nodes accept them.
19:05:18 <wfaressuissia> <rucknium[m]> "No, because decoy selection is..." <- What's the difference if in both cases (number of inputs * number of txs) will remain constant and will leak the same information ? Also single aggregate tx is cheaper and smaller ?
19:05:27 <sethsimmons> So with "official" clients max is `(block_size_limit / 2 - 600) * 2/3`, but consensus will allow up to 1,000,000 bytes.
19:05:29 <sethsimmons> Got it.
19:05:45 <sethsimmons> And the current limit equates to ~100kb ATM.
19:06:09 <wfaressuissia> rucknium[m]: it isn't spam, it's expected behaviour
19:07:14 <Rucknium[m]> wfaressuissia[m]: Why do you have to be so contrarian all the time? I don't get it. Yes, we had an apparent spam incident earlier this year. It was with small txs though.
19:08:01 <wfaressuissia> "Yes, we had an apparent spam incident earlier this year. It was with small txs though." it isn't spam, it's allowed behaviour by code therefore it should be expected
19:08:37 <sech1> that's more of a philosophical dispute
19:09:31 <wfaressuissia> This system in the end should allow to do cheap private txs. if you are fighting with spam then increase fee so that no one will do txs and report that privacy is perfect now
19:09:38 <Rucknium[m]> I believe that the original definition of technological spam was in email, where the email systems technically allowed it but it was harmful to its operation. So, yes, spam.
19:10:28 <UkoeHB> wfaressuissia: large transactions are a bit more useful to a passive observer, who knows that one member in each ring is from the same person. If the large tx is split, then the observer only knows there are clumps of inputs, but there might be multiple tx authors.
19:13:11 <koe000[m]> wfaressuissia: large transactions are a bit more useful to a passive observer, who knows that one member in each ring is from the same person. If the large tx is split, then the observer only knows there are clumps of inputs, but there might be multiple tx authors. (bridge is depressingly unreliable)
19:14:23 <koe000[m]> solid 5 minutes to show up, nice
19:17:02 <UkoeHB> However, if you make more tx without churning, to further combine small tx, then graph analysis will make up at least part of the difference.
19:17:35 <wfaressuissia> Sudden peak of txs vs sudden 1 huge tx, what's the difference ?
19:18:03 <wfaressuissia> koe000[m]: are you writing via #monero-dev:libera.chat or via matrix room ?
19:20:01 <Rucknium[m]> wfaressuissia[m]: Other transactions can get in those blocks. With huge txs, those other txs are pushed out and cannot be used as decoys from those blocks.
19:20:50 <koe000[m]> There is a non-zero margin of plausible deniability added with small tx. My koe000 account is in the matrix room, my UkoeHB account is in libera.chat.
19:21:11 <wfaressuissia> All txs are owned by the same entity, that means all of them can be revealed to public
19:22:03 <Rucknium[m]> wfaressuissia[m]: What proportion of view keys are publicly available at the moment?
19:26:47 <wfaressuissia> I didn't count
19:43:30 <Lyza> not to be like a squeaky wheel but, if the only use case we have for large numbers of inputs is significant #s people consolidating coinbase outputs due to p2pool, why not make an exception specifically for those outputs? they are identifiable, they could be constructed without rings and be a ton smaller, I think without harming privacy
19:43:59 <Lyza> seems like if you're consolidating a bunch of coinbase outputs it's going to be obvious and the rings aren't actually obscuring anything anyway
19:45:20 <wfaressuissia> "... I think without harming privacy ..." proof 
19:46:29 <Lyza> it's a suggestion for consideration; I don't have proof except for what I already said, that it seems like the consolidation would already be obvious. and anyway you can always send to yourself again after consolidating
19:46:39 <botcoinnotbot[m]> Lyza: you would just be making it easier for people to distinguish p2pool consolidations instead of forcing them to guess 
19:47:18 <Lyza> yes on the basis that guessing is already trivial, which Idk is maybe an incorrect assumption
19:47:58 <Lyza> you got 100+ inputs and every single ring contains a coinbase output in it, I mean.... that seems unlikely to be random chance
19:48:51 <Lyza> unless coinbase outputs become a large proportion of all outputs I guess
19:49:16 <Rucknium[m]> Lyza: Which is not great for user privacy.
19:49:47 <botcoinnotbot[m]> "that it seems like the consolidation would already be obvious", proofs please
19:51:20 <botcoinnotbot[m]> due to random chance there has probably been many transactions which look like consolidations which are not, if you were to make a special class of transaction for consolidation any regular transaction that included many coinbases by chance would be affected
19:53:45 <Lyza> "if you were to make a special class of transaction for consolidation any regular transaction that included many coinbases by chance would be affected" <--- regular transactions would not include coinbase outputs in rings, under this suggestion
19:54:06 <nioc> p2pool will significantly increase consolidation txs but they have always existed   
19:54:36 <Lyza> doesn't CLI warn you that combining large numbers of outputs is bad for privacy? thought this was well known. and obvs it would be worse for consolidating coinbase outputs
19:55:34 <Lyza> and if we did this, we could limit inputs for other transactions to something very reasonable like idk 16 instead of 100, which might be a win for privacy as well
19:56:12 <Rucknium[m]> Keep in mind that there have been a lot of "nice features" in Monero that have later been recognized as a threat to privacy and had to be removed.
19:56:20 <nioc> with p2pool you can get many txes that are temporarily close and yhe CLI warns you when they are 
19:56:43 <Lyza> yeah I'm really not trying to make any ahrd claims just putting it out there to be considered
19:57:32 <Lyza> I guess another option is making it so there can only be one coinbase output but I think we like p2pool
19:57:37 <Rucknium[m]> Lyza: In case it wasn't clear, I was supporting your point.
19:57:53 <Lyza> cool :)
20:03:04 <wfaressuissia> "I believe that the original definition of technological spam was in email, where the email systems technically allowed it but it was harmful to its operation. So, yes, spam." there is no difference between spam and demand
20:03:14 <Rucknium[m]> By "nice feature" I was implying that consolidating a huge number of outputs in a single tx was a nice feature.
20:03:38 <wfaressuissia> Any demand can be marked as spam to justification for poorly designed system
20:03:46 <wfaressuissia> * ... to justify ...
20:06:13 <Rucknium[m]> In my view decoys and ring signatures are a suboptimal system, but they are the best thing we have at the moment, given that other solutions rely on cryptography that has not been battle tested. So, yes, the system is not well designed but there is no other viable way at the moment.
20:08:03 <nero-cultist[m]> ^
20:08:32 <nero-cultist[m]> Is increasing ring signatures simply just a bandaid for a bigger problem 
20:09:56 <sethsimmons> An increase in ring sizes in the next network upgrade is a stop-gap until much larger ring sizes via Seraphis.
20:14:26 <MohammedMujahid[> Monero community please help me 
20:14:34 * MohammedMujahid[ uploaded an image: (200KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/QwkHOXHgVAWypKNhSuIkOExs/Screenshot_2021-11-20-01-41-16-85_0b2fce7a16bf2b728d6ffa28c8d60efb.jpg >
20:15:14 <MohammedMujahid[> Kindly please help me😭
20:15:48 <louipcm> does the transaction appear in the blockchain?
20:16:02 <Rucknium[m]> nero-cultist: If you are interested in further reading on weaknesses with the ring signature model, you can read this piece by a Zcash Foundation member. Keep in mind that most of these attacks require you to interact with large nefarious entities:
20:16:02 <Rucknium[m]> https://www.zfnd.org/blog/blockchain-privacy/
20:16:08 <louipcm> also this is the wrong channel
20:16:22 <sethsimmons> This channel is not for support, please use #monero:monero.social and refer to the help you were already linked to earlier.
20:16:29 <Rucknium[m]> Mohammed Mujahid: This is not the correct room. Please go elsewhere. This is for development discussion.
20:21:03 <MohammedMujahid[> <louipcm> "does the transaction appear in..." <- No sir
20:22:14 <wfaressuissia> "... Keep in mind that most of these attacks require you to interact with large nefarious entities:" if your statistical solution will work then it should increase cost (amount of resources) required for these ways of deanonymization
20:26:04 <Rucknium[m]> wfaressuissia[m]: Right. That's part of the point of increasing the ring size and developing a better decoy selection algorithm. An adversary would need even more information about a target after the decoy issues are improved.
20:27:13 <wfaressuissia> "An adversary would need even more information about  ..." I mean your statistical solution can be tested (this test can be written even before your research) by anyone against those attacks
20:27:46 <wfaressuissia> and there will be concrete numbers how much it helps or not doesn't help
20:30:16 <Rucknium[m]> Yes, you are correct
20:31:39 <nero-cultist[m]> > <@rucknium:monero.social> nero-cultist: If you are interested in further reading on weaknesses with the ring signature model, you can read this piece by a Zcash Foundation member. Keep in mind that most of these attacks require you to interact with large nefarious entities:
20:31:39 <nero-cultist[m]> > https://www.zfnd.org/blog/blockchain-privacy/
20:31:39 <nero-cultist[m]> Do you think we could apply similar concepts to Monero? 
20:31:50 <nero-cultist[m]> The best of both worlds ?
20:32:37 <wfaressuissia> "That's part of the point of increasing the ring size" it makes system better in the worst case and doesn't rely on any assumptions except working cryptography
20:33:03 <wfaressuissia> "... and developing a better decoy selection algorithm." don't know how useful it will be but it relies on many assumptions about usage pattern
20:33:05 <Rucknium[m]> If and when there is a better solution with acceptable tradeoffs that is battle-tested and requires no trusted setup, then probably Monero would adopt it.
20:33:08 <wfaressuissia> and isn't ideal solution for decentralized system
20:34:41 <Rucknium[m]> wfaressuissia[m]: So the ultimate goal would be to have a dynamically-adjusting decoy selection aglorithm that matches the current usage pattern at every point in time.
20:44:04 <wfaressuissia> It's more interesting to have test (that can be run by anyone) that will show cost for all known attacks on privacy. And this test doesn't require solution for the attacks. But for some reason it looks like this test will not be even written by you.
20:45:23 <Rucknium[m]> wfaressuissia[m]: Where's that thing you promised at the MRL meeting?
20:45:41 <wfaressuissia> which one ?
20:47:00 <Rucknium[m]> wfaressuissia[m]: https://libera.monerologs.net/monero-research-lab/20211117#c47763
20:53:41 <wfaressuissia> "Where's that thing ..." in my head yet
20:55:02 <Rucknium[m]> wfaressuissia[m]: I suggest you spend time trying to figure out how to move it from your head to the real world instead of being such a nag.
20:55:52 <rock[m]> Woah, easy there Ruck.
20:57:09 <wfaressuissia> "I suggest you ..." fortunately there is at least something in my head to move, unlike in others
20:57:50 <Rucknium[m]> wfaressuissia[m]: Yeah, who are you talking about? Who others? Out with it!
20:58:20 <Rucknium[m]> wfaressuissia[m]: You snipe at other and contribute nothing. Prove me wrong.
20:58:36 <Rucknium[m]> Prove me wrong by doing something.
20:58:56 <rock[m]> Fellas, it's Friday. We're all nerds here. Let it go
21:28:44 <frak0197[m]> <rock[m]> "Fellas, it's Friday. We're all..." <- speak for yourself! im a dork 😃
21:29:10 <luigi1111w> nerds dorks geeks
23:05:41 <botcoinnotbot[m]> how hard would it be to add a config file option to add/exclude your node from using networks.
23:06:19 <botcoinnotbot[m]> e.g. --network-exclude ipv4/6 --network-use i2p/tor?
23:06:59 <botcoinnotbot[m]> for those who wish to have all node communications specifically through i2p/tor? 
23:11:37 <botcoinnotbot[m]> bitcoin config file has the option for onlynet=tor
23:11:37 <botcoinnotbot[m]> onlynet=i2p, something I think would be worth porting over to monero :)
23:25:31 <wfaressuissia> "porting command line arg" awesome idea. It also makes sense to port command args "--enable-sybil-resistance --enable-decentralized-mining --enable-high-throughput --enable-high-privacy"
23:26:50 <botcoinnotbot[m]> wfaressuissia[m]: why so toxic, I am well aware that this is more than just adding a command
23:33:36 <wfaressuissia> "clearnet: mandatory, all packets, --p2p-bind-ip/--p2p-bind-ipv6, i2p/tor: optional, only txs, `--tx-proxy/--anonymous-outbound/--anonymous-inbound`" these options are already doing, so you didn't even check `monerod --help` ?
23:36:13 <wfaressuissia> "...  I am well aware that this is more than just adding a command" there are a lot of problems in current code even with clearnet p2p network (add to this problems with anonymization network support)
23:36:26 <wfaressuissia> also bitcoin is not the best reference of project with good p2p network
23:36:34 <wfaressuissia> and it isn't task that can be described as "porting over" 
23:37:21 <botcoinnotbot[m]> wfaressuissia[m]: if you actually read the docs you would know that this does not make your node exclusive to that network, nor is there a command to do that
23:40:01 <botcoinnotbot[m]> wfaressuissia[m]: you are making assumptions about what I am saying and then attacking your own assumptions. wownero has a dedicated port for i2p of 34565, how hard would it be to just block all connections except for the assigned i2p port. I said nothing about porting bitcoin node code
23:42:12 <wfaressuissia> clearnet isn't working, i2p/tor support is even more funny, there is nothing inside to configure with command line options
23:45:01 <wfaressuissia> what things will be transmitted over that imaginary dedicated i2p port ?
23:45:53 <botcoinnotbot[m]> wfaressuissia[m]: what are you smoking? i am running my node over i2p tor and ipv4 with 500 incoming connections right now
23:50:45 <wfaressuissia> Why did you mention 500 ?
23:53:49 <botcoinnotbot[m]> wfaressuissia[m]: to tell you that the networking is fine and can handle many connections fine
23:57:40 <selsta> botcoinnotbot[m]: can you link that wownero commit?
23:58:01 <selsta> as far as I know wownero doesn't have anything that isn't a thing in monero
23:59:05 <wfaressuissia> "... to tell you that the networking is fine and can handle many connections fine" anyone can send simultaneously 500 packets to your node it will occupy 100MB * 500 RAM at the same time
23:59:12 <wfaressuissia> do you have so much memory ?