04:13:41 <plowsof[m]> gingeropolous ccs proposal to beef up / maintain infra for MRL https://www.reddit.com/r/Monero/comments/un0wqi/my_first_ccs_request_more_storage_for_monero/
11:14:15 <ooo123ooo123[m]> <plowsof[m]> "gingeropolous ccs proposal to..." <- for Rucknium to be precise
13:37:57 <gingeropolous[m]> not really. man i wish matrix had an ignore button. ah well
13:41:32 <merope> it does
13:41:51 <merope> click on the account, there's a red ignore button at the end
13:42:15 <merope> oh, just realized that gingeropolous left :/
14:07:29 <gingeropolous[m]> nice. thanks
14:33:17 <UkoeHB> meeting 2.5hr
17:00:26 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/702
17:00:26 <UkoeHB> 1. greetings
17:00:26 <UkoeHB> hello
17:00:49 <ooo123ooo123[m]> hello
17:01:09 <rbrunner> Hi
17:01:10 <Rucknium[m]> Hi
17:01:38 <xmr-ack[m]> Hi
17:02:35 <jberman[m]> hello
17:02:46 <UkoeHB> 2. updates, what is everyone working on?
17:02:58 <mj-xmr[m]> Hi
17:04:11 <Rucknium[m]> Been doing a lot of work on BCH projects, including prototyping various data structures.
17:05:19 <xmr-ack[m]> Me: I’ve been feature engineering for my magic grant, I have a neural network built that is achieving roughly the same accuracies as the other models.
17:06:25 <mj-xmr[m]> I have basically done everything else, that was blocking me from continuing the Decoy reimplementation, including the time consuming monthly report.
17:06:26 <mj-xmr[m]> After this, I made the next step and confirmed (so far visually), that my Python interpretation of the gamma distribution's parameters is the same as the original Monero's. See here:
17:06:26 <mj-xmr[m]> https://github.com/mj-xmr/monero-mrl-mj/tree/decoy/decoy#comparison-of-moneros-and-python-gamma-distribution
17:06:46 * mj-xmr[m] uploaded an image: (32KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/dBJaSeDvKHJGOFKwaYfzyeBk/image.png >
17:07:54 <mj-xmr[m]> Ruck: if nothing stops me, I should have it done until the end of the next week.
17:08:32 <UkoeHB> me: Continuing work on Seraphis (will write unit tests for my input selection solver today, next step is enote scanning workflows). Also pushing multisig PR 8149 forward (finally done with all the rebases). The existing multisig implementation is completely busted, so it's important to fix as many bugs as possible with the next HF. However, as ooo123ooo123[m] rightly points out, we need more reviews for increased 
17:08:32 <UkoeHB> confidence that all the bugs/protocol inadequacies have been resolved (if there are any takers, please help with that, the protocol is too large for any one person to identify every possible weakness).
17:08:50 <Rucknium[m]> Looks great! Just a typo: Those are the PDFs rather than the CDFs
17:09:47 <jberman[m]> re-reviewed 8076 (rbrunner's PR to reduce trips to the daemon on wallet refresh), dug deeper into the Dandelion++ impl while doing so, and have been working through patching some daemon connectivity/reliability issues I noticed in the process (txs get stuck after failing to relay on 1st try, and connections are dropping leading to sporadic failed submits/warnings in the logs). Getting to the bottom of these specific connectivity
17:09:47 <jberman[m]> issues I believe will give me momentum into reviewing perfect-daemon's 7760 that deals with similar issues
17:11:25 <Rucknium[m]> jberman: Great. Thank you. I have heard from many people that `monerod` has reliability issues.
17:11:56 <rbrunner> Yeah, 7760 is waiting for a long time already, would be sad to waste it because nobody reviews
17:14:17 <UkoeHB> 3. discussion, any questions/comments/things to talk about?
17:14:23 <jberman[m]> Tbh I'm hoping some of 7760 can be knocked out with smaller bite-sized patches like vtnerd pointed out in his review of that PR; that PR is fairly large and difficult to reason through
17:16:20 <Rucknium[m]> Would anyone mind if I opened a PR for the research-lab GitHub repo to update the README a little? For example, addition MoneroResearch.info , link to list of open research questions, explanation of where to find meeting announcements, etc.
17:16:42 <Rucknium[m]> Also, there is a PR waiting to be merged to add previous meeting logs.
17:17:00 <UkoeHB> go for it
17:17:19 <selsta> jberman[m]: the problem is it fixes a number of interconnected bugs, so one large rewrite was the easiest way to go for it
17:19:30 <w[m]> Is 7999 still being looked at for the fork? https://github.com/monero-project/monero/pull/7999
17:19:59 <selsta> for this fork? no
17:20:03 <ooo123ooo123[m]> Bulletproofs++ will be included into this fork
17:20:29 <UkoeHB> BP++?
17:20:56 <hyc> only 1 +, not 2
17:21:24 <selsta> there is also ++ now but that isn't implemented yet
17:21:28 <selsta> at least there is a paper for it
17:21:50 <hyc> https://eprint.iacr.org/2022/510
17:22:08 <UkoeHB> the BP++ paper said it was slower than BP+ (in their tests), so it's usefulness remains to be seen
17:23:18 <UkoeHB> maybe batching can amortize those costs
17:24:43 <mj-xmr[m]> <Rucknium[m]> "Looks great! Just a typo..." <- Fixed. Thanks.
17:25:00 <Rucknium[m]> Do people have thoughts about gingeropolous  's CCS proposal for more storage on the research computing server? https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/317
17:25:51 <Rucknium[m]> In the short term, the storage increase is important for analyzing user behavior on other blockchains.
17:28:47 <ooo123ooo123[m]> Rucknium[m]: Would it be useful for BCH work too ?
17:30:41 <Rucknium[m]> We are not using it for BCH-focused projects. However, as discussed in a recent meeting, I will be analyzing some key medium-of-exchange cryptocurrencies, including BTC, BCH, LTC, DOGE, and maybe DASH.
17:32:30 <merope> Not much to say I guess - improving the tools for the job is always a plus imo
17:33:05 <ooo123ooo123[m]> <UkoeHB> "the BP++ paper said it was..." <- "This code is not competitive with implementations in C or Rust or that use highly performant libraries for the elliptic curve operations." That's reference implementation without any optimizations
17:33:21 <UkoeHB> yes, hence 'remains to be seen'
17:33:29 <mj-xmr[m]> <Rucknium[m]> "In the short term, the storage..." <- Exactly this is what ArticMine suggested me to do with my future fee vs blocksize analysis. This will help proving Monero's superiority.
17:33:49 <moneromooo> EC op count should give a fairly good indication.
17:33:54 <mj-xmr[m]> Since Monero will adapt to the situation better. We know it.
17:34:27 <mj-xmr[m]> So yeah. I'm for the gingeropolous 's CCS Proposal.
17:36:34 <UkoeHB> BP++ is also a very new paper, so it would be good to let it marinate (and maybe do some poc and perf testing if we can find someone able and motivated to implement it).
17:40:18 <UkoeHB> Anything else anyone wants to say? Otherwise we can close the meeting early
17:41:32 <Rucknium[m]> On mining pool concentration, I want to point out that my suggestion to try to have minexmr.com implement a dynamic pool operator fee got lots of upvotes on Reddit. Which doesn't mean too much, but suggests that the community would be OK with the idea: https://www.reddit.com/r/Monero/comments/uk8pab/comment/i7o6bt6/
17:41:43 <Rucknium[m]> Of course the key hurdle is whether minexmr.com itself is OK with the idea 
17:42:08 <moneromooo> Good luck. I wrote a patch to do that automatically years ago, nobody cared.
17:42:13 <hyc> and how many of the upvotes are from minexmr miners?
17:42:44 <ooo123ooo123[m]> <UkoeHB> "BP++ is also a very new paper..." <- The hardest part is to check it's security. Implementation is easy
17:43:09 <Rucknium[m]> We will likely continue to deal with this problem. According to my very preliminary model, minexmr's share of blocks found increases when the fiat/XMR exchange rate declines. It may be that miners who use minexmr are less sensitive to depreciation of XMR.
17:43:17 <merope> Such a dynamic pool fee would work if miners were picking pools "dynamically", but I think it would just be "free money" for the pool operator as-is
17:44:02 <hyc> yeah if most miners are "set it and forget it"
17:44:13 <UkoeHB> ooo123ooo123[m]: well if you want to implement a proof-of-concept, I can spin up some perf tests
17:44:31 <merope> We know that there is a large botnet concentration on Minexmr, so they are definitely "less sensitive to depreciation"
17:44:47 <selsta> yes, minexmr is probably the default pool in many botnet guides
17:45:47 <ooo123ooo123[m]> merope: How did you check that ? Is it public knowledge ?
17:45:55 <merope> And even if mining configuration were not "set it and forget it", we still have the issue of withdrawal minimums. Many small miners start mining on Minexmr, get told to switch, but stick around because they can't withdraw their payouts yet
17:46:40 <merope> People are very attached to those 1-2 dollars worth of xmr they took weeks to mine
17:46:54 <ooo123ooo123[m]> <Rucknium[m]> "On mining pool concentration..." <- Pool will not commit suicide this way, so it will not help at all. And if pool decides to commit suicide then another pool will pop up and replace it
17:49:05 <Rucknium[m]> Frankly if pools will not change behavior to reducing concentration, then a protocol change may be in order, in line with tevador's MRL issue #98. I think we have been hoping that p2pool changes things, especially now that it is integrated with the GUI wallet. But if things don't change, what do we do?
17:49:48 <gingeropolous> tevadors boolberry-like thing might work
17:50:12 <Rucknium[m]> I don't think that others pools can just grab market share so easily. minexmr's hashrate share is the product of years of inertia.
17:50:13 <gingeropolous> though if the majority of that hr is botnets, they'll just hide behind a proxy
17:50:49 <gingeropolous> but i guess at some level it will still add costs to the pool, which will drive the fee up, which would hopefully get ppl to migrate to different pools
17:52:43 <moneromooo> One thing that could help is (1) xmrig auto uses the pool with lowest hash rate in a set of pools it knows about and (2) a common api for pools to "exchange" pending balances, similar to how banks do settlements.
17:52:59 <moneromooo> It'd rely on pools being onest, but the current system already does.
17:53:07 <moneromooo> Also relies on someone to do the code...
17:53:28 <moneromooo> (this is to counter the "people are very attached..." point)
17:53:59 <moneromooo> Might rely too much on cooperation though.
17:54:10 <gingeropolous> yeah.
17:54:30 <moneromooo> Though if you don't cooperate, you get bumped off xmrig's list ? Might be enough of an incentive.
17:54:44 <gingeropolous> right now there's relatively little cost of being a big pool
17:54:53 <moneromooo> Does xmrig have a builtin list atm ? If not, it'd also add a centralization aspect.
17:55:26 <sech1> there's no built in list in xmrig
17:55:28 <moneromooo> Actually, nvm, this adds nothig on top of p2pool does it. Ignore what I said.
17:55:30 <merope> It would rely on trusting both pools - but given that you were using one pool and are now switching to the other, it implies that you are trusting them already to hold your balance
17:55:46 <sech1> but there is a list at https://xmrig.com/wizard#pools
17:55:48 <merope> The main issue I see with the balance transfer is the setup and the tx fees every time someone wants to switch
17:56:07 <gingeropolous> this seems very top down
17:56:38 <merope> sech1 perhaps add a warning next to minexmr's name? Or remove minexmr from that list?
17:56:55 <merope> That way, if somebody really wants to mine there, they'll have to add it manually
17:56:59 <sech1> that would be censorship
17:57:03 <merope> Might be enough to deter a clueless newbie
17:57:14 <sech1> clueless newbie don't use this page
17:57:29 <sech1> they usually watch some youtube video or google "how to mine monero"
17:57:43 <merope> I've pointed countless newbies to the wizard (don't know how many have actually used it though)
17:57:45 <sech1> and find a guide that tells them to use minexmr
17:57:49 <gingeropolous> and most noobs (i was once a noob) want to see a payout to see that its real
17:57:59 <gingeropolous> so they go for the one that'll give them a payout the soonest
17:58:29 <merope> And it would not be censorship - they still *can* mine there, they'll just have to add it as a "custom pool" instead of going off the preconfigured list
17:58:33 <gingeropolous> if the noob sticks around they may change pools. but i imagine it would mainly be for a lower fee
17:59:30 <merope> The earliest payout is from pools with the lowest withdrawal minimum
17:59:40 <UkoeHB> we are at the end of the hour, thanks for attending everyone
18:00:20 <moneromooo> The earliest payout is based on that minimum, the pool hash rate, and luck.
18:05:52 <nioc> earliest pending balance shows that it is working  
18:07:03 <gingeropolous> are there any downsides to https://github.com/monero-project/research-lab/issues/98 that aren't apparent?
18:07:38 <sech1> every miner would have to run a node
18:08:12 <gingeropolous> not as i understand it. the pool would have to deliver a chunk of data every n blocks to a miner
18:08:26 <sech1> not realistic for a big pool
18:08:33 <gingeropolous> isn't that the point?
18:09:01 <sech1> they could use some CDN though
18:09:05 <ooo123ooo123[m]> gingeropolous: It's can be mitigated with patch for xmrig and modification from pool side which will deliver hash of whatever is added for hashing
18:09:05 <ooo123ooo123[m]> useless
18:09:17 <gingeropolous> thats more $$, which increase the fee %
18:09:53 <sech1> Mitigated is the wrong word. It's additional traffic for pool miners
18:09:59 <sech1> having own node locally will be more efficient
18:10:14 <Rucknium[m]> I think the main concern about reducing or eliminating the viability of pools is a dramatic reduction is hashrate, which would harm blockchain security.
18:10:39 <ooo123ooo123[m]> Rucknium[m]: Are you just copy/pasting answers of others ?
18:11:09 <gingeropolous> this wouldn't necessarily reduce or eliminate the viability of pools though. it would just encourage distribution
18:11:10 <sech1> I don't know how much a pool operator would need to pay for CDN, but I don't think it will cost them more than they already pay for servers
18:12:34 <ooo123ooo123[m]> sech1: It's easy to write dumb daemon that will maintain only 10GB of blockchain state that is needed for mining
18:12:36 <moneromooo> Are you implying someone should never have an opinion another shared ?
18:12:48 <moneromooo> It's unclear. Maybe you are being an asshole. Or both, you never know.
18:13:01 <moneromooo> Can you explain which (or a third possibility I did not think of) ?
18:13:56 <sech1> it's easy to modify the proposal to require all blockchain data, not just 10 GB
18:14:36 <ooo123ooo123[m]> sech1: Data can be requested asynchronously from other nodes, no problem
18:14:38 <moneromooo> Oh wait, I forgot, I already asked to explain something, and you did not bother.
18:14:48 <moneromooo> So I know now.
18:15:33 <moneromooo> I'll still wait for a third asshole time before /ignore, due to the first message about an interesting paper.
18:15:42 <moneromooo> (might have been a mistake)
18:15:44 <sech1> ooo123ooo123[m] it's still 256 MB of data download every 64 blocks, traffic usage will be the same as just running the local node
18:16:20 <gingeropolous> right, but for a pool operators, now they have the cost of delivering 256 MB of data * (number of miners)
18:16:54 <ooo123ooo123[m]> sech1: 33KB/s isn't a problem for miner
18:17:22 <UkoeHB> sech1: Would the pool necessarily be the one sending out the chain data? Pool miners could just operate as normal listener nodes on the network to get chain data, then talk to the pool for the mining part (while I was typing, ooo123 made this point). Rather than significantly reducing pool dominance it might just reduce overall hashrate (reducing the cost of 51%).
18:17:27 <merope> <Rucknium[m]> "I think the main concern about..." <- Note that the proposal in issue 98 would make centralized pools harder to run, but it would not eliminate pools entirely
18:17:38 <sech1> 33 KB/s is a problem for botnet miners which are the majority on minexmr
18:17:47 <merope> So, with a proper implementation, it could potentially shift the balance further towards p2pool
18:17:53 <sech1> 33 KB/s per each botnet worker is a lot
18:17:58 <sech1> many are on poor connections
18:18:06 <ooo123ooo123[m]> sech1: Real botnet machines has enough free HDD space for mining
18:18:16 <ooo123ooo123[m]> s/has/have/
18:18:40 <merope> But it would make the botnet even easier to spot
18:18:59 <ooo123ooo123[m]> This direction is just making mining node heaver for everyone without achieving the goal
18:19:04 <Rucknium[m]> gingeropolous: Due to that, wouldn't the proposal incentivize pools to ban low-hashrate miners? If it is a cost per miner rather than cost per hash.
18:19:13 <merope> "Hmmm, my cpu usage is often 100%, ram usage 2GB higher than normal, and now I have lost 10GB of disk space and my connection is always pegged"
18:19:28 <selsta> but isn't mining way more resource intensive that running a node?
18:19:33 <selsta> than*
18:19:44 <gingeropolous> just on the CPU
18:19:47 <sech1> it is, but on in disc space
18:20:18 <ooo123ooo123[m]> merope: Botnet victims are smart enough to not notice it
18:20:27 <UkoeHB> If pools expect all their miners to download blockchain data from the network, wouldn't this really clog up public nodes (assuming pool miners are optimized so they don't mirror the chain).
18:20:38 <UkoeHB> ?
18:20:41 <merope> Rucknium[m]: In that case, those miners would still have to move to another pool (which they would not have done otherwise). They are low hashrate, but still better than nothing
18:21:13 <ArticMine[m]> Not necessarily in cost if the mining is done during the heating season in a building heated with electricity
18:21:14 <gingeropolous> ^
18:21:22 <gingeropolous> gah, ment ^ for merope 
18:22:35 <ArticMine[m]> If one replaces electric resistance heating with mining there is NO additional electricity cost
18:23:28 <ooo123ooo123[m]> <moneromooo> "Are you implying someone..." <- People with their own opinion usually can defend it. That wasn't the case there
18:23:29 <merope> Besides, botnets often [citation needed] rely on swarms of low-hashrate workers - so such a ban policy on the pool side would force botnets to use proxies or spread their hashrate elsewhere
18:25:04 <merope> ooo123ooo123 this topic has come up before, and the notion that killing pools would reduce network security is correct and has been discussed before
18:25:05 <moneromooo> I did not see any request to defend it. But an opinion is not necessarily based on facts and logic. It could be based on feelings (though in the current case, I agree it probably doesn't have a place).
18:25:40 <moneromooo> In the feelings case, there is no real defense since introspection about one's feelings is pretty much impossible.
18:25:57 <moneromooo> (to a fairly large extent anyway)
18:26:56 <gingeropolous> M5M400 didn't respond to my cost estimate request in pools. 
18:26:59 <merope> It "would be nice (TM)" to see a detailed study on the impact of that proposal on mining requirements, as a function of how much of the chain you need to lookup and how often
18:27:02 <moneromooo> (I agree with what merope just said btw, I used to think pools should be taken down a notch, I now think it'd be more loss than gain, though that is of course a guess, absent the actual attempt)
18:27:48 <ooo123ooo123[m]> merope: Discussion doesn't prove anything. Why ?
18:28:12 <moneromooo> IIRC wownero did switch from "pools ok" to "trying to disincentivize pools", and hash rate went down IIRC. anyone knows whther true, and whether it has recovered (or maybe hash / price ratio) ?
18:28:43 <sech1> Wownero is consitently ~2x more profitable to mine
18:28:54 <sech1> so I can say hashrate reduced by 50%
18:29:00 <moneromooo> 2x more... than monero ?
18:29:03 <merope> ooo123ooo123 If you'd read the previous discussion, you'd know. Otherwise, by your logic we'd have to redemonstrate the entirety of mathematics every say that 2+2=4. Stop polluting the channel if you have nothing to contribute
18:29:07 <sech1> yes, than monero
18:29:24 <moneromooo> Was is sinilar to monero before ?
18:29:28 <sech1> yes
18:29:36 <moneromooo> Thanks.
18:29:37 <sech1> thank to MoneroOcean and other switching pools
18:29:48 <merope> wownero is still randomx, right? just enforced solo mining
18:29:50 <ooo123ooo123[m]> merope: Any short summary why ?
18:30:18 <gingeropolous> its a randomx variant.. some of the parameters changed, but its essentially the same (CPU centric)
18:30:54 <merope> Oh right, 1MB cache was it?
18:30:54 <sech1> it's randomx with 1 MB scratchpad, so more favorable for Intel CPUs
18:31:09 <w[m]> Rx/wow
18:31:09 <w[m]> A bit lighter with higher hashrates 
18:31:38 <Rucknium[m]> ooo123ooo123: The log of the previous discussion is here: https://libera.monerologs.net/monero-research-lab/20220216
18:32:58 <merope> I wonder if we could look at extra_nonce of the wownero blocks before and after solo_mining and try to compare hashrate distribution from that
18:33:28 <gingeropolous> afaik, the wownero solo-only prevents p2pool from working.
18:33:50 <merope> Sorry, tx_extra length
18:34:06 <merope> Though I doubt there would be an exact correspondence between tx_extra lengths and individual miners
18:34:18 <gingeropolous> i think if that weren't true, solo-only would be more ... attractive..?
18:35:01 <merope> Yeah, if p2pool were still possible with solo-only it would be the perfect solution
18:35:07 <moneromooo> Very unlikely. Pools have a special length (the zone117x based ones at least have a 4 byte chunk (5 with length I think) extra data which non pool will not usually have.
18:35:47 <gingeropolous> i wonder if we could do that thing that other networks have done where they split up the PoW. Here, instead of splitting between different PoW, we split between solo blocks and pool blocks
18:35:52 <moneromooo> Some pools watermark their blocks for... asshole reasons. Though since pools usually list their blocks, it doesn't really matter in practice.
18:36:17 <moneromooo> (and that watermark is data in extra too, which means specific length typically)
18:36:36 <moneromooo> Well, some pools, at least one pool.
18:36:44 <gingeropolous> it'd be interesting, because a solo miner could contribute to both blocks
18:36:54 <gingeropolous> but a pool could only contribute to one
18:37:12 <gingeropolous> though that could be more convoluted than its worth
18:38:13 <merope> contributing to both blocks = computing two separate hashes
18:38:33 <merope> so their effort would just be split between the two sides, and you'd be back to square one
18:38:35 <gingeropolous> naw, those protocols do something like every even block is X, and odd block is Y 
18:39:31 <sech1> so with tevador's proposal, pool traffic would be 85 GB/month/miner
18:39:46 <sech1> 1000 miners = 85 TB/month, or $500 to pay for a CDN
18:39:49 <gingeropolous> and its currently ....
18:40:07 <sech1> CDN from OVH, for example
18:40:27 * w[m] uploaded an image: (56KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/cchXYLJppgxSdVQgENONHcae/Image_118.jpg >
18:40:29 <w[m]> moneromooo: wownero hashrate when they went solo
18:40:32 <sech1> so yes, this proposal just adds traffic toa list of miners' problems
18:40:37 <sech1> not so much changes for pools
18:40:42 <gingeropolous> blargh
18:41:31 <moneromooo> w[m]: missing sentence fragment ?
18:41:44 <sech1> and this proposal will probably wipe out small pools due to increased costs
18:41:48 <sech1> only big pools will remain
18:42:06 <sech1> so the effect might be quite the opposite of the desired
18:42:11 <gingeropolous> .hrm
18:42:16 <ooo123ooo123[m]> sech1, do you believe in 1000x-3000x multiplier for p2pool payouts frequency relatively to solo mining too ?
18:42:30 <sech1> I don't "believe". It can be calculated
18:42:40 <sech1> network diff / p2pool diff = multiplier
18:43:09 <sech1> currently it's 2185x for p2pool-mini
18:43:37 <sech1> assuming that each share give 1 payout
18:43:46 <sech1> which is not true in general case
18:43:53 <sech1> so real multiplier will be smaller
18:44:04 <gingeropolous> unfortunately, i don't think we can expect the same result as the bitcoin mining network. due to the lower barrier of entry, we'll have an eternal september kinda thing, so participants won't come to the realization that they need to spread the hash
18:44:40 <UkoeHB> sech1: how do p2pool payouts compare to the fee cost of spending a single input?
18:44:49 <merope> though some bigger miners will find multiple shares per payout too, so... would the average still be 1?
18:44:58 <gingeropolous> i think bitcoin pulled it off because the participants are more professional level
18:45:04 <sech1> if you combine many inputs, the fee will be < 1% of the amount
18:45:10 <ooo123ooo123[m]> What's about multiplier for "equal amount payout frequency" ? e.g. time to get the same amount with available hashrate from solo or p2pool mining ?
18:45:14 <sech1> it will be worse after July fork though
18:45:18 <ooo123ooo123[m]> sech1: What's the real multiplier then ?
18:45:38 <gingeropolous> never consolidate, just hodl till the dust buys a house. 
18:46:00 <moneromooo> The real (long term average) multiplier depends on your hash rate, so there is not one single one.
18:46:08 <sech1> real multiplier depends on pool luck and individual miner luck
18:46:08 <UkoeHB> sech1: I mean specifically the differential fee from incrementing the number of inputs (this math is important for input selection).
18:46:19 <merope> ooo123ooo123 the *average* time to get the same amount will always the same, because it only depends on your hashrate vs network hashrate. What changes is the variance. Solo mining is the maximum variance (all-or-nothing, and it can take years on low hashrate to find a block), pool mining is lower variance the bigger the pool.
18:46:21 <sech1> I can only estimate average numbers (see above)
18:46:55 <sech1> UkoeHB adding 1 input adds ~520 bytes to the transaction weight
18:46:58 <sech1> so it's quite cheap
18:47:39 <moneromooo> (and of the p2pool hash rate too)
18:47:48 <ooo123ooo123[m]> sech1: average real numbers
18:47:53 <ooo123ooo123[m]> is ?
18:48:10 <sech1> the amount of XMR mined? It's the same over long enough time
18:48:18 <moneromooo> 520 sounds like a lot. Are you sure ?
18:48:21 <merope> ooo123ooo123 why don't you try calculating them yourself, and then we can compare notes?
18:48:31 <sech1> he can only criticize
18:48:46 <gingeropolous> <sech1> 1000 miners = 85 TB/month, or $500 to pay for a CDN >>> wait wait. With this estimate, minexmr would have a $6k / month CDN cost
18:49:04 <UkoeHB> what the current min fee per byte, and what is the current p2pool payout?
18:49:06 <sech1> moneromooo that's from my experiments (100 KB transaction = 194 inputs)
18:49:27 <moneromooo> A ring... 16 outs, 32 bytes maybe. Amount, 6 bytes. Key image, 32 bytes. Various lengths, a handful of bytes.
18:49:38 <sech1> gingeropolous that's peanuts for them
18:50:24 <sech1> They currently get $12k / month in fees
18:50:30 <moneromooo> Amount probalby 1 byte even nowadays.
18:50:38 <UkoeHB> moneromooo: seems right, seraphis is around 700-900 bytes per input I think
18:51:02 <moneromooo> Hmm. I wonder what I'm forgetting then.
18:51:11 <ooo123ooo123[m]> merope: I've already said it's <= 12x
18:51:13 <moneromooo> Oh. Signatures :D
18:51:22 <ooo123ooo123[m]> I'm trying to understand how you're calculating
18:51:29 <merope> UkoeHB Minimum payout = Monero block reward/2160, ~0.0003 XMR
18:51:29 <sech1> yes, those bulletproofs take a lot of tx space
18:51:39 <moneromooo> BPs are for outs.
18:52:18 <sech1> oh. anyway, it's 515-520 bytes per input from what I can see when I sweep p2pool payouts
18:52:38 <moneromooo> Yes, I'd just discounted sigs, my mistake.
18:52:44 <UkoeHB> merope: ok, and what is the min fee per byte?
18:52:58 <sech1> 4000 piconero
18:53:08 <merope> Lowest fee I'm seeing right now is 0.000004257869 per byte
18:53:11 <sech1> will be when we hit the tail emission
18:53:23 <merope> So a single payout will be able to pay for its own spend
18:53:29 <sech1> yes
18:53:43 <sech1> otherwise I wouldn't make 2160 the default
18:53:53 <merope> Though the usual pattern is for miners to aggregate all payouts with a sweep
18:53:56 <sech1> I wanted to make it bigger, but the fee calculation didn't add up
18:54:12 <sech1> yes, sweeping many inputs is ~3x more efficient
18:55:01 <sech1> July fork will increase fees almost 5x, this will be sensitive for p2pool miners
18:55:05 <UkoeHB> is that payout ~150x the fee? ok
18:55:19 <UkoeHB> the very smallest fee*
18:55:33 <sech1> after the fork, sweeping minimum p2pool payouts (<0.0003 XMR each) will cost 4-5% of the amount
18:56:11 <sech1> so mining on p2pool-mini and getting more than 0.0003 XMR per payout will be more important
18:56:51 <sech1> but it won't matter "in the future" (c) when median block size increases a lot :D
18:57:01 <sech1> and we'll have small fees again
18:57:54 <sech1> I also thought about adding "0-fee" transaction broadcasting between p2pool nodes. They can still mine 0-fee transactions from their own miners
18:58:04 <gingeropolous> mmmmm yes
18:58:12 <sech1> but this will make such transactions stand out, so I'm not sure
18:58:32 <gingeropolous> i mean, consolidating that dust makes it stand out
18:58:38 <sech1> true
18:58:44 <sech1> it's already easy to spot
18:59:16 <gingeropolous> let alone having your xmr address shared amongst the p2pool members with your ip, so ...
18:59:40 <sech1> an observer who saves all p2pool blocks knows all inputs and if he/she sees a tx with > 100 inputs, each of inputs has a p2pool payout to the same address in its rings, then it's obvious
19:00:54 <gingeropolous> im still trying to get through my head how taking $6k out of minexmr's $12k monthly inflows wouldn't do much
19:01:18 <sech1> they would just increase the fee to 1.5% and get 18k/month
19:01:33 <sech1> and smaller pools would just go out of business
19:01:45 <sech1> while the fat one dries, the thin one dies
19:02:17 <gingeropolous> yeah i guess 1.5 isn't that far from 1.0, and supportxmr 0.6% compared to minexmr 1.1% indicates that its all hogwash anyway
19:03:15 <moneromooo> Maybe what's needed is people to make flashy youtube or tiktok videos showing one click p2pool setup.
19:03:29 * moneromooo takes one step back
19:03:34 <gingeropolous> :)
19:04:31 <merope> Unironically yes
19:04:34 <gingeropolous> clearly we need asics
19:04:45 <gingeropolous> so we can have mining farms that know how to distribute hashrate
19:04:49 <merope> The main hurdle is the "one click setup" part
19:05:23 <moneromooo> Would it count as one click if you have to install python and wxwidgets first...
19:05:24 <sech1> we have zero click setup aka botnets
19:05:55 <gingeropolous> one click, disable antivirus, sync the blockchain....
19:08:01 <gingeropolous> well, conclusion is tiktok
20:35:04 <UkoeHB> ooo123ooo123[m]: This PR https://github.com/monero-project/monero/pull/8149 has stabilized after a bunch of rebases, cleanup, and some review comments (sorry for the messy commit history). Do you want to review the changes?
22:23:55 <r4v3r23[m]> .merges