11:03:29 <waki4ever> Why does the Saviour of NASA take a group achievement award and present it as a proof of individual glory? https://twitter.com/hyc_symas/status/1203709575226183683
11:42:58 <ErCiccione[m]> I can ban people and delete messages on matrix side. if you want to give me OP on freenode too i can control both from matrix (or with my freenode account linked to this matrix account)
12:06:38 <ErCiccione[m]> test
15:34:54 <sgp_> Delegated RingCT: faster anonymous transactions
15:35:05 <sgp_> https://eprint.iacr.org/2020/1521
15:35:24 <sgp_> "We present a modification to RingCT protocol with stealth addresses that makes it compatible with Delegated Proof of Stake based consensus mechanisms called Delegated RingCT. Our scheme has two building blocks: a customised version of an Integrated Signature and Encryption scheme composed of a public key encryption scheme and two signature schemes (a digital signature and a linkable ring signature); and
15:35:24 <sgp_> non-interactive zero knowledge proofs. We give a description of the scheme, security proofs and a prototype implementation whose benchmarking is discussed. Although Delegated RingCT does not have the same degree of anonymity as other RingCT constructions, we argue that the benefits that the compatibility with DPoS consensus mechanisms brings constitute a reasonable trade-off for being able to develop an
15:35:24 <sgp_> anonymous decentralised cryptocurrency faster and more scalable than existing ones."
15:43:27 <LyzaL> interesting cause I didn't even know RingCT was incompatible with PoS heh
15:56:31 <UkoeHB__> thanks for sharing sgp_
16:11:52 <mikerah[m]> DPoS is generally a dead-end from the perspective of most PoS enthusiast
16:12:09 <mikerah[m]> I would need to read the paper to see how they define DPoS before I write it off
16:24:43 <moneromooo> I was thinking about fake output selection, and whether an alternative selection algorithm would be better:
16:25:12 <moneromooo> Divide the chain into N (= ring size) windows, then pick an output in each window.
16:25:36 <moneromooo> Window size is calculated from 0 to current, based on the gamma distribution.
16:26:02 <moneromooo> So a very wide window from 0, and very narrow windows near the most recent outputs.
16:26:25 <moneromooo> A fake out would not be picked for the window in which the real output lies.
16:27:00 <moneromooo> This should still match the gamma distribution I think, and yet would prevent silly degenerate picks.
16:27:13 <moneromooo> ie, every ring would have an old output, for instance.
16:27:41 <moneromooo> And the nice thing is that we could start enforcing this in consensus.
16:28:12 <moneromooo> Would such a scheme introduce statistical issues ?
16:34:23 <sech1> Well, statistically it wouldn't be random picked gamma distribution
16:34:33 <sech1> because sometimes it doesn't have old outputs and it's normal
16:38:21 <sech1> I mean, if you make a bar chart of selected output's frequencies it will look like gamma. But more detailed statistical tests will show it's not gamma
16:40:04 <sech1> It effectively reduces the sets of fake outputs to choose from from all "gamma-like" to only certain "gamma-like" sets
16:40:20 <sech1> I think it reduces the efficiency of rings
16:40:50 <moneromooo> Do we care about "detailed statistical tests will show it's not gamma" ? If so, why ?
16:41:10 <moneromooo> Why do you think it reduces the efficiency of rings ?
16:41:12 <sech1> They can uncover the real output with higher probability
16:41:22 <moneromooo> How ?
16:42:53 <sech1> It depends on how you select outputs in each window. I doubt uniform distribution will be enough
16:43:17 <sech1> You'll need to do analysis for each window and adjust distribution to preserve ring efficiency
16:43:36 <moneromooo> Yes, uniform would be bad, at least for old windows.
16:44:27 <sech1> So if an attacker knows that real outputs in some window are most often in a certain part of it, they can exclude outputs which are not in that part
16:45:36 <moneromooo> Well, AFAICT that's not an argument against the system, just an argument against something I did not suggest.
16:45:53 <moneromooo> It'd be the same now, if you use uniform distribition, it'd be shit. We just... don't.
16:46:47 <moneromooo> I'm just interested in knowing whether picking one in every window would make it better or worse.
16:46:48 <sech1> this could work with proper distribution curves for each window and have the same level of security
16:47:12 <sech1> This is my uneducated cryptography amateur opinion ^^^
16:48:40 <sech1> I think it should satisfy the following: if an output is N blocks old, it should appear in a ring with the same probability as the real output of the same age. Regardless if you use selection windows or not.
16:49:00 <sech1> The task then becomes choosing curves for each window to satisfy it
16:49:19 <sech1> and choosing window sizes
16:49:27 <tevador> what we really need is a larger ring size
16:49:34 <gingeropolous> ^^^
16:49:52 <sech1> and same probabilities of real and fake outputs too
16:50:02 <sech1> because skew in probabilities reduces effective ring size
16:50:28 <hyc> sure, and slicing outputs into windows is a step to ensure uniform probabilities in each window
16:51:26 <sech1> btw how was the current gamma distribution obtained? From BTC blockchain data?
16:52:01 <moneromooo> IIRC from known spends pre-rct. Not 100% sure.
16:52:12 <sech1> BTC spending patterns are quite different. They have mixers "for privacy" doing lots of transactions and they don't exist in XMR.
16:52:57 <moneromooo> The Miller et al paper compared it with bitcoin, it was a similar shape.
16:53:20 <moneromooo> Though differnet params. It's not clear to me how chain age would have changed monero's.
16:53:35 <sech1> My gut feeling says it should be a simple shape with just a few parameters to reflect real world spending
16:55:18 <gingeropolous> I'd put forward that the enforcement of selection should be prioritized or given greater weight in this decision
16:55:43 <sech1> It's impossible to enforce random selection
16:55:49 <sech1> only selection windows probably
16:56:04 <sech1> because https://xkcd.com/221/
16:56:15 <gingeropolous> deterministic *is* possible. ppl just don't like the burden it puts on things
16:57:06 <sech1> how are you going to make it deterministic without disclosing which output is real?
16:57:35 <sech1> I think the answer to this question will be worth a scientific paper :D
16:57:48 <gingeropolous> i forget. i feel like its been bandied about here. perhaps in lounge.
16:58:28 <moneromooo> One idea is to have a PRNG seeded of, say, the key image and the current height. Generate data, maybe N times. You can then offset the whpole thing so one output falls onto the real out. Inc;ude height and offset in the ring.
16:58:56 <gingeropolous> could even smoosh that together with the window thing to make it even easier, less brute forcing maybe
16:59:04 <moneromooo> If the offset is large, it skews the whole distribution though, so N might need to be large.
17:00:32 <sech1> that won't work
17:00:33 <moneromooo> Seed off key image + height + user seed, if you want to roll N times.
17:00:36 <moneromooo> Why ?
17:00:42 <sech1> it means that first N-1 times didn't fall on the real output
17:00:51 <sech1> which will exclude all the outputs that it fell on
17:00:59 <sech1> which I suppose is almost all outputs on the blockchain
17:01:06 <moneromooo> The Nth one probably will not fall on the real out either.
17:01:18 <moneromooo> That's why you have an offset.
17:01:49 <moneromooo> Granted, you might be able to make statistical guesses.
17:01:59 <sech1> hmm, offset leaks some bits of data anyway
17:02:24 <moneromooo> It does, but you don't have to select the smallest offset.
17:02:40 <moneromooo> Though the smallest it is, the closer to the original distribution your picks are.
17:03:47 <moneromooo> Anyway, shall we pause on this for the meeting ?
17:03:56 <sech1> you could just run PRNG with random 64-bit seeds every time until one of outputs is yours
17:04:04 <sech1> then it shouldn't leak any data about the real output
17:04:19 <moneromooo> That'd take a *long* time when you spend old outs.
17:04:38 <moneromooo> But also, large offset -> more likely to spend an old out...
17:04:57 <moneromooo> Though you can have the wallet select large offset on purpose when spending a recent out.
17:05:23 <moneromooo> It's got a number of unclear possible leaks though, agreed.
17:05:46 <gingeropolous> larger ringsize would help
17:05:48 <moneromooo> Does anyone here want to have a meeting ?
17:06:03 <moneromooo> If so, please go ahead if you have something to talk about :)
17:06:09 <sech1> that creates a problem of transactions that are generated offline
17:06:22 <sech1> they can't use latest blocks obviously
17:10:32 <moneromooo> Well, looks like noone today.
17:10:44 <moneromooo> As for offline txes, it's the same as now, right ?
17:13:47 <sech1> yes, same. But with deterministic generation you'll have to include the exact blockchain height used in the tx
17:14:06 <sech1> which is another bit of information not present today
17:15:00 <moneromooo> Yes. Might be a way around that though. Like quantizing a bit and having the verifier try a few heights around the claimed height.
17:15:36 <moneromooo> Around some of it anyway.
17:16:12 <Isthmus> This is why NRL anchors ring member statistics off the youngest ring member rather than the block it was included on
17:16:55 <Isthmus> So that delayed broadcast isn’t a problem
17:18:08 <sech1> right now if we see that the youngest ring member is 100 blocks old we can't tell if it was online or offline transaction
17:18:17 <sech1> but with included generation height it will be pretty obvious
17:18:28 <sech1> online transactions get mined in 1-2 blocks time
17:21:27 <Isthmus> Yep, that's exactly why we key off an intrinsic data point (height of youngest ring member) rather than extrinsic
17:21:38 <Isthmus> (such as the height at which the transaction was included)
17:41:54 <sgp_> sounds like an argument for binning. there's a good amount of research on binning
17:45:46 <sgp_> what's the motivation for this discussion again? are there wallets using different selection algorithms again?
17:46:47 <moneromooo> Some asshole spamming the network with non standard picks.
17:46:57 <sgp_> got it
17:47:12 <sgp_> in what way are they doing that? all old picks?
17:47:33 <hyc> the opposite - all new
17:49:01 <sech1> Link to any example tx of these picks?
17:49:03 <sgp_> why would someone even do that other than just to be annoying?
17:49:14 <hyc> sgp: bingo
17:49:29 <sgp_> they don't learn any additional info compared to spamming with the correct algo
17:50:15 <hyc> it lets them point to any arbitrary recent txn and say "look how trivially this can be de-anon'd" because it uses all outputs that he spammed already
17:50:49 <hyc> it doesn't need to be an effective attack, it only needs to be FUD.
17:50:49 <sgp_> well that's an output control problem, isn't the selection change unnecessary?
17:50:59 <sech1> This attack is only effective at supporting miners :P
17:51:27 <sgp_> if anything, all it does it warn users that someone is trying to conduct an output control attack
17:51:52 <sgp_> and then someone can create a lower bound for the magnitude
17:51:57 <sech1> but it must last for months before it gets efficient
17:52:06 <sech1> because standard pick algorithm chooses old outputs too
17:52:24 <hyc> seems like it's been going a week or two already
17:52:27 <sgp_> sech1: I argue it's effective enough just to share FUD after a week
17:52:32 <sech1> and if there's 2 independent (or even competing) entities doing this, it won't work at all
17:52:37 <sgp_> they need to have enough outputs of course
17:52:50 <hyc> tx rate is double what it was ~2 weeks ago
17:53:03 <sgp_> but if they are looking to FUD only one transaction, not terribly difficult
17:53:05 <hyc> that seems like a significant amount for this purpose
17:53:22 <sech1> 0.25 XMR/day to spam 15000 transactions
17:53:28 <sgp_> I say FUD in this case only because they probably only need to make a non-verifiable educated guess to FUD
17:53:50 <sgp_> anyone have an idea of the magnitude? I have a bunch of tools to test
17:54:01 <hyc> if he owns 50% of txs (and outputs) for the past week, that's a pretty solid starting point
17:54:09 <sech1> well, it jumped from 15k to 27k per day on Sunday
17:54:12 <sech1> which was unusual
17:54:23 <sech1> I think it started on Sunday
17:54:43 <sech1> see https://bitinfocharts.com/comparison/monero-transactions.html#3m
17:55:24 <hyc> likely, yeah
17:56:09 <sgp_> if someone can show the data on what % of those transactions use unusual rings, please let me know
17:57:02 <sech1> so it this one: https://xmrchain.net/tx/f382376955e147ea718272ef29b92ff1ada56dbe35c14f91bacba9d20dc338e7 one of these tx's?
17:57:17 <sech1> ring members selected only from the last 3 days
17:57:28 <moneromooo> https://townforge.net//dist/output-age-output-last-month.xz (50 MB, has the last month's txes along with output ages)
17:57:59 <moneromooo> Telltale is when the first ring member has a number of a few thousand.
17:58:17 <moneromooo> (which means the oldest output is only a few days old)
17:59:29 <sgp_> looking
18:00:15 <moneromooo> You can ignore the "out" lines here.
18:00:43 <moneromooo> Columns for hte "tx" lines are height, txid, ring size, then 11 output ages in blocks.
18:01:50 <moneromooo> Last one being 14-20 is also a likely giveaway.
18:01:58 <sgp_> okay, thank you
18:04:28 <sech1> I see a lot such transactions even in month old blocks in that file
18:05:13 <ArticMine> tevador: what we really need is a larger ring size <---- Let us quantify this. For a ring size of 25 what would be the size of a 2 in 2 out tx after factoring in BP+?
18:05:17 <hyc> not too surprising, given how long attacks have been ongoing
18:05:30 <moneromooo> I can give anyone interested the source to the program that generates these. 5 GB output so I can't upload that in any sane timeline.
18:05:52 <sgp_> I'm still trying to filter the data from the download
18:11:41 <sgp_> it's difficult to say exactly how effective the attack is at identifying all of the outputs, since I would need to know how many normal transactions have at least one output older than x days
18:14:26 <sech1> moneromooo can you prepare the similar file for May 2019 when there was no attack (presumably) and a lot of legit transactions
18:15:27 <moneromooo> Yes.
18:15:50 <sgp_> for one arbitrary ring to be compromised each day with ringsize 11, that would require oversight of 38% of outputs distributed uniformly
18:16:43 <sgp_> actually that's assuming all 1-in, so that's not actually quite true. Actually less than 38% then
18:18:01 <sgp_> and if there's a higher % of recent outputs controlled (as in this case), then as long as they have outputs past a reasonable window, they would also need control of fewer total outputs
18:21:45 <Inge-> <+moneromooo> Some asshole spamming the network with non standard picks. <-- any numbers on how many of the transactions are like this?
18:22:13 <moneromooo> 14-20 is actually pretty common overall. So not a sign.
18:25:45 <moneromooo> sech1: https://townforge.net//dist/output-age-output-may-2019.xz
18:42:47 <sgp_> I have some rough data coming up soon with the last month numbers (not May 2019's)
18:44:32 <Isthmus> Hmm, I know that with a (2+)-in transaction, I can reference the same output in multiple rings
18:44:45 <Isthmus> But can I also make a single ring that references the same output 11 times?
18:44:53 <Isthmus> Mathematically I don't see why it wouldn't work
18:44:56 <sgp_> Yes I think
18:45:17 <Isthmus> That'd be some good FUD material
18:46:56 <sgp_> The main harm is to the sender of the tx in that case
18:47:26 <Isthmus> Correct, it would be modifying your software to shoot your own foot
18:47:33 <Isthmus> Which seems on brand for certain trolls
18:49:19 <moneromooo> You can't use the same output more than once in a ring.
18:49:29 <moneromooo> You can still do plenty of other dumb things though.
18:51:44 <sech11> Interesting: https://i.imgur.com/kmqlkDf.png
18:52:04 <sech11> This is the age of the oldest output in a ring (normalized, Y-axis is in promille)
18:52:25 <sech11> I mean 1/1000
18:52:40 <moneromooo> Matches the tx rate almost doubling.
18:52:50 <sech1> No, it's normalized
18:53:04 <sech1> I divided by the total number of txs and then multiplied numbers by 1000
18:53:27 <sech1> So it shifted towards younger outputs in the last month
18:53:41 <moneromooo> Well, almost twice the ratio of very recent, no ?
18:53:45 <sech1> and there's also a peak at ~186 days
18:53:55 <sech1> yes, 2 times more very recent outputs
18:54:17 <sgp_> For the last month, about 15% of txs have their max decoy block height less than 10000 blocks
18:54:40 <sgp_> s/decoy/output
18:55:26 <sgp_> Half have their oldest output less than 60000 blocks old
18:55:55 <sgp_> Those are rings actually, not txs
18:58:07 <sgp_> I only see about 3000 rings with max age less than 1000 blocks
18:58:35 <sgp_> Which is ~0.3%
19:03:16 <sgp_> sech1: are we getting different numbers on those?
19:07:14 <sech1> I don't know, I need to rewrite my script to count it
19:12:38 <sech1> For the last month, I have half rings with oldest output less than 61*720 = 43920 blocks
19:12:58 <sech1> For May 2019, it's 107*720 = 77040 blocks
19:14:48 <sech1> Cumulative graph: https://i.imgur.com/yhHx0ca.png
19:15:21 <moneromooo> It's weird. I can see your images, but I can't see most others from imgur, I get a "you need JS" page...
19:15:52 <sech1> It's direct links to static images
19:16:48 <sech1> Where in the codebase is the output selection algorithm?
19:17:05 <moneromooo> wallet2.cpp, grep for "gamma".
19:17:19 <moneromooo> Ignore the triangular distribution stuff, it's only used for pre-rct now.
19:19:27 <sech1> gamma_picker class?
19:20:11 <moneromooo> Yes.
19:20:35 <sech1> blocks_to_consider is limited to 1 year? What if someone spends older output?
19:21:31 <moneromooo> No idea. I don't remember that. Let me read code...
19:22:02 <sech1> nevermind, it's a limiting parameter
19:22:09 <sech1> it's only used to calculate average output time
19:22:17 <sech1> *not a limiting parameter
19:23:34 <sgp_> sech1: y axis is %*10?
19:23:48 <sech1> sgp_ yes
19:23:57 <sech1> per mille (1/1000)
19:24:59 <sech1> moneromooo well, that explains more younger outputs in the last month. The gamma_picker is skewed to younger outputs if number of txs was growing in the last year, which it did
19:25:19 <sech1> average_output_time and logic around it assumes that tx flow was constant
19:25:24 <moneromooo> Does it explain such a large shift ?
19:26:00 <sech1> well, we did have more than 2 times fewer transactions a year ago: https://bitinfocharts.com/comparison/monero-transactions.html#1y
19:26:15 <moneromooo> Shift from two weeks ago.
19:26:25 <moneromooo> Sustained.
19:26:34 <sgp_> this data doesn't scream "different selection algo used by large spammer" to me
19:26:37 <sech1> It's not a simple math to estimate the effect of this transaction growth on output selection as it is now
19:27:58 <sgp_> right, and other user behavior would change it too
19:28:22 <sech1> on the other hand, transaction growth will skew real spending to younger outputs too, so I think gamma_picker logic is correct here
19:28:24 <moneromooo> I was kinda confusing tx volume and output age. The sustained shift that feels like a good outlier is the number of txes.
19:28:34 <sgp_> based on the conversation earlier, I assumed something like 20% of new txs used outputs all less than 10000 blocks
19:32:43 <needmoney90> Any value in popping up a site that you send Monero to as a 'donation', and it persistently sends transactions with those funds in a forward secret way while deleting its prior keys?
19:33:15 <needmoney90> Stopgap measure, in the event of a suspected attack, you can dump some funds in and add a base level of known secure txes
19:33:27 <sgp_> not amazing if the behavior is predictable somehow
19:33:41 <sgp_> handling timing would be kinda difficult
19:33:50 <needmoney90> Worth looking into?
19:34:03 <sgp_> imo not really
19:35:24 <sgp_> I'm worried that cheap transactions is one vulnerability here. They don't need to be extremely expensive, but even $0.01 per would help keep rando trolls away
19:35:26 <sech1> bad idea to spam the chain with useless transactions for eternity
19:35:34 <sech1> it's already approaching 100 GB
19:37:32 <sgp_> at the moment transactions are basically free at ~$0.002
19:38:09 <sgp_> so only ~$1k for 15000 tx/day
19:38:28 <sgp_> for a month
19:39:25 <sgp_> ArticMine: what's keeping us from increasing the base fee?
19:42:49 <gingeropolous> obvi the fact that monero's gonna be worth 9 kajillion dollars tomorrow.
19:43:02 <gingeropolous> what about lowering the 300kb thingy
19:45:04 <jwinterm> need to use chainlink to tie base rate to usd value
19:45:05 <jwinterm> clearly
19:47:40 <sgp_> Monero could 100x vs USD and the base fee would still be cheap
19:48:13 <sgp_> Well, maybe reasonable not SUPER cheap
19:48:49 <jwinterm> $0.20 seems reasonable to me
19:49:21 <sech1> $13100 per XMR seems also reasonable to me :P
19:50:02 <midipoet> Be funny if we then found out that XMR price is always relative to transaction fee cost, as opposed to the other way around.
19:51:35 <hyc> in comparisons to other "privacy" coins that I see frequently posted, XMR seems to already have the most expensive fees of the class
20:00:29 <sgp_> hyc: yeah but those have even less use. ZEC's z2z fees are artificially low
20:01:32 <sgp_> my gut feeling is that the base fees should be 10x higher
20:09:32 <sech1> you want a contentious fork?
20:09:52 <sech1> it's too late to increase fees
20:10:53 <sgp_> well I know it would take a fork to increase base fees, but we could change next hardfork with bp+ if there's a reason to
20:11:11 <sgp_> not sure where contentious fork comes from
20:13:19 <sech1> contentious because users will not want higher fees without a very good reason.
20:13:59 <sethsimmons> Yeah.I don’t know how well that would go over unless we have clear data that an attack is ongoing.
20:14:19 <sethsimmons> Low fees are a big selling point for people and one of the most frequent “pros” brought up.
20:14:34 <sethsimmons> The best way to combat flooding attacks is to get more people to use Monero 😉
20:14:45 <sech1> they're low now, but on the scale of a few years price will go up a lot and fees won't be low anymore
20:15:40 <hyc> we're at something like 1/4th of ATH in XMR/USD. 4x for fees doesn't seem huge
20:20:27 <sgp_> I honestly don't think a fee bump to a reasonable number will be contentious, especially if it's supported better than the current base fee
20:20:54 <sgp_> like, will people REALLY walk away if fees go up to $0.01
20:21:24 <sgp_> I just don't want to take fee increases off the table, that's all. *If* we should do one, then we should do one
20:22:14 <sethsimmons> There just needs to be a clear reason with supporting data
20:22:29 <sethsimmons> Especially since it will likely need to be rolled back later on because its based on fiat value
20:23:01 <sethsimmons> If it could be made decentralized like dynamic block size that is one thing, but relying on devs/Core to change fees at will is a road I’m not a huge fan of.
20:23:18 <sethsimmons> And will bring heavy “centralized” FUD for some good reason
20:23:26 <sethsimmons> I doubt it would actually be a contentious hard fork
20:25:03 <thrmo> the current fee was set exactly like that though sethsimmons
20:26:10 <thrmo> fees will always be a contentious point/change until we can develop a new model
20:26:32 <thrmo> *better model
20:26:45 <sethsimmons> Yes I understand, and that’s why I’m not opposed to a change with clear data to back up the necessity.
20:28:47 <hyc> re: higher fees - would not be a major attack disincentive, if the attacker also holds significant hashrate
20:28:59 <hyc> higher fees just puts more money in their pocket
20:29:02 <sgp_> sure
20:29:18 <thrmo> that's a different attack vector though and harder to pull off hyc
20:31:04 <hyc> ... or attacker is getting dev donations from mining software that's in common use ...
20:31:57 <thrmo> his software is less and less used these days, afaik
20:32:04 <hyc> good to hear
20:32:17 <sethsimmons> 😬
20:32:23 <thrmo> that's what you get when you antagonize an entire community I guess.
20:32:38 <sethsimmons> Good
20:33:21 <sarang> Important to note that an attacker who spams outputs could use that data to reduce effective anon set of honest transactions
20:33:43 <sarang> And having a common non-standard characteristic could be used as a way to make this spam set public
20:33:58 <thrmo> I think that's his plan
20:34:01 <hyc> yes, that's been the underlying assumption in this whole discussion
20:34:57 <sarang> OK, just had jumped in, hadn't followed everything
20:35:59 <sarang> Quite the interesting set of attacks recently
20:36:28 <sethsimmons> Is this actually an ongoing attack?
20:37:27 <hyc> yes
20:37:38 <sgp_> besides the adjusted selection algo which ended up being less clear, is there any other indication that an attack is being conducted? just the tx increase?
20:38:03 <hyc> tx increase, output selection
20:38:38 <sethsimmons> We know the TX increase is an attack and not related to DNMs being Monero-only now as a general rule + speculative load?
20:39:14 <hyc> tx rate ~doubled on Sunday, 15K to 27K
20:39:36 <hyc> are you aware of any DNM announcements (comparable to alphabay 2016) that would account for such a jump?
20:39:45 <sgp_> you all were discussing that looking back, you were concerned for about a month though right?
20:41:09 <hyc> we were remarking on it, but maybe not yet concerned.
20:41:23 <hyc> but there's no way these new txns are legit, with their weird output selection
20:43:55 <sethsimmons> A large portion of the new transactions have flawed decoy selection?
20:44:11 <sethsimmons> We have been averaging ~20k transactions for a while now, with a major dip around the fork of course.
20:44:41 <sgp_> sarang: without special software. any reason why we would see such a change in the output selection? The real-time selection may decrease with more outputs generated recently, but would block time be unaffected? Or is the block time shortened because it selects by output not by block? https://i.imgur.com/yhHx0ca.png
20:44:50 <sethsimmons> There was no recent DNM announcement that would double TX count overnight, but 27k is not that far off of our recent ATHs of ~20k multiple times.
20:44:51 <sech1> fun fact: you need only 600 kh/s to mine fees for 25k transactions/day
20:46:00 <sethsimmons> <sethsimmons "There was no recent DNM announce"> This also coincides with a large increase in Monero price, so could have been organic + DNM usage + speculative
20:47:44 <sethsimmons> <sgp_ "sarang: without special software"> What percentage of these transactions have an abnormal decoy selection?
20:47:51 <sgp_> sarang: is the selection by block (so we should expect this to not change with increased # of txs), or is it more per output and thus would expect to narrow with more activity?
20:48:14 <sgp_> if I recall correctly it's closer to the former?
20:48:58 <sech1> selection is per output
20:49:15 <sech1> but it's quantized to a random output in a block after selecting output index
20:50:29 <sgp_> so we should expect an increase in # of txs to select more outputs from more recent blocks, as we see here?
20:50:41 <sech1> yes
20:50:58 <sech1> as long as number of txs grows
20:51:24 <hyc> so can that explain the selection we're currently seeing?
20:51:46 <hyc> seems like a weakness in the selection algo, should be counting blocks
20:52:10 <hyc> (tho I recall that was a weakness before, when most blocks were empty)
20:52:14 <sech1> "on the other hand, transaction growth will skew real spending to younger outputs too, so I think gamma_picker logic is correct here"
20:53:35 <sech1> what we need to do is to run gamma_picker 1,000,000 times for example to add a reference line to https://i.imgur.com/kmqlkDf.png
20:54:01 <hyc> probably should return to a block-based algo, but weighted so that empty blocks don't count
20:54:11 <sgp_> makes sense, agree sech1
20:54:33 <sgp_> thanks for the explanation
20:56:35 <sgp_> I think if fuk specifically was to spam, they are more likely to do so with an unmodified algo
20:57:16 <sgp_> just because anything else is more effort with no benefit
20:57:41 <sethsimmons> *and makes the attack much easier to detect
21:27:21 <Inge-> could be other actors dipping their toes in.