Why does the Saviour of NASA take a group achievement award and present it as a proof of individual glory? twitter.com/hyc_symas/status/1203709575226183683

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)

test

Delegated RingCT: faster anonymous transactions

"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

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

anonymous decentralised cryptocurrency faster and more scalable than existing ones."

interesting cause I didn't even know RingCT was incompatible with PoS heh

thanks for sharing sgp_

DPoS is generally a dead-end from the perspective of most PoS enthusiast

I would need to read the paper to see how they define DPoS before I write it off

I was thinking about fake output selection, and whether an alternative selection algorithm would be better:

Divide the chain into N (= ring size) windows, then pick an output in each window.

Window size is calculated from 0 to current, based on the gamma distribution.

So a very wide window from 0, and very narrow windows near the most recent outputs.

A fake out would not be picked for the window in which the real output lies.

This should still match the gamma distribution I think, and yet would prevent silly degenerate picks.

ie, every ring would have an old output, for instance.

And the nice thing is that we could start enforcing this in consensus.

Would such a scheme introduce statistical issues ?

Well, statistically it wouldn't be random picked gamma distribution

because sometimes it doesn't have old outputs and it's normal

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

It effectively reduces the sets of fake outputs to choose from from all "gamma-like" to only certain "gamma-like" sets

I think it reduces the efficiency of rings

Do we care about "detailed statistical tests will show it's not gamma" ? If so, why ?

Why do you think it reduces the efficiency of rings ?

They can uncover the real output with higher probability

How ?

It depends on how you select outputs in each window. I doubt uniform distribution will be enough

You'll need to do analysis for each window and adjust distribution to preserve ring efficiency

Yes, uniform would be bad, at least for old windows.

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

Well, AFAICT that's not an argument against the system, just an argument against something I did not suggest.

It'd be the same now, if you use uniform distribition, it'd be shit. We just... don't.

I'm just interested in knowing whether picking one in every window would make it better or worse.

this could work with proper distribution curves for each window and have the same level of security

This is my uneducated cryptography amateur opinion ^^^

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.

The task then becomes choosing curves for each window to satisfy it

and choosing window sizes

what we really need is a larger ring size

^^^

and same probabilities of real and fake outputs too

because skew in probabilities reduces effective ring size

sure, and slicing outputs into windows is a step to ensure uniform probabilities in each window

btw how was the current gamma distribution obtained? From BTC blockchain data?

IIRC from known spends pre-rct. Not 100% sure.

BTC spending patterns are quite different. They have mixers "for privacy" doing lots of transactions and they don't exist in XMR.

The Miller et al paper compared it with bitcoin, it was a similar shape.

Though differnet params. It's not clear to me how chain age would have changed monero's.

My gut feeling says it should be a simple shape with just a few parameters to reflect real world spending

I'd put forward that the enforcement of selection should be prioritized or given greater weight in this decision

It's impossible to enforce random selection

only selection windows probably

because xkcd.com/221

deterministic *is* possible. ppl just don't like the burden it puts on things

how are you going to make it deterministic without disclosing which output is real?

I think the answer to this question will be worth a scientific paper :D

i forget. i feel like its been bandied about here. perhaps in lounge.

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.

could even smoosh that together with the window thing to make it even easier, less brute forcing maybe

If the offset is large, it skews the whole distribution though, so N might need to be large.

that won't work

Seed off key image + height + user seed, if you want to roll N times.

Why ?

it means that first N-1 times didn't fall on the real output

which will exclude all the outputs that it fell on

which I suppose is almost all outputs on the blockchain

The Nth one probably will not fall on the real out either.

That's why you have an offset.

Granted, you might be able to make statistical guesses.

hmm, offset leaks some bits of data anyway

It does, but you don't have to select the smallest offset.

Though the smallest it is, the closer to the original distribution your picks are.

Anyway, shall we pause on this for the meeting ?

you could just run PRNG with random 64-bit seeds every time until one of outputs is yours

then it shouldn't leak any data about the real output

That'd take a *long* time when you spend old outs.

But also, large offset -> more likely to spend an old out...

Though you can have the wallet select large offset on purpose when spending a recent out.

It's got a number of unclear possible leaks though, agreed.

larger ringsize would help

Does anyone here want to have a meeting ?

If so, please go ahead if you have something to talk about :)

that creates a problem of transactions that are generated offline

they can't use latest blocks obviously

Well, looks like noone today.

As for offline txes, it's the same as now, right ?

yes, same. But with deterministic generation you'll have to include the exact blockchain height used in the tx

which is another bit of information not present today

Yes. Might be a way around that though. Like quantizing a bit and having the verifier try a few heights around the claimed height.

Around some of it anyway.

This is why NRL anchors ring member statistics off the youngest ring member rather than the block it was included on

So that delayed broadcast isn’t a problem

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

but with included generation height it will be pretty obvious

online transactions get mined in 1-2 blocks time

Yep, that's exactly why we key off an intrinsic data point (height of youngest ring member) rather than extrinsic

(such as the height at which the transaction was included)

sounds like an argument for binning. there's a good amount of research on binning

what's the motivation for this discussion again? are there wallets using different selection algorithms again?

Some asshole spamming the network with non standard picks.

got it

in what way are they doing that? all old picks?

the opposite - all new

Link to any example tx of these picks?

why would someone even do that other than just to be annoying?

sgp: bingo

they don't learn any additional info compared to spamming with the correct algo

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

it doesn't need to be an effective attack, it only needs to be FUD.

well that's an output control problem, isn't the selection change unnecessary?

This attack is only effective at supporting miners :P

if anything, all it does it warn users that someone is trying to conduct an output control attack

and then someone can create a lower bound for the magnitude

but it must last for months before it gets efficient

because standard pick algorithm chooses old outputs too

seems like it's been going a week or two already

sech1: I argue it's effective enough just to share FUD after a week

and if there's 2 independent (or even competing) entities doing this, it won't work at all

they need to have enough outputs of course

tx rate is double what it was ~2 weeks ago

but if they are looking to FUD only one transaction, not terribly difficult

that seems like a significant amount for this purpose

0.25 XMR/day to spam 15000 transactions

I say FUD in this case only because they probably only need to make a non-verifiable educated guess to FUD

anyone have an idea of the magnitude? I have a bunch of tools to test

if he owns 50% of txs (and outputs) for the past week, that's a pretty solid starting point

well, it jumped from 15k to 27k per day on Sunday

which was unusual

I think it started on Sunday

see bitinfocharts.com/comparison/monero-transactions.html#3m

likely, yeah

if someone can show the data on what % of those transactions use unusual rings, please let me know

so it this one: xmrchain.net/tx/f382376955e147ea718…ff1ada56dbe35c14f91bacba9d20dc338e7 one of these tx's?

ring members selected only from the last 3 days

townforge.net//dist/output-age-output-last-month.xz (50 MB, has the last month's txes along with output ages)

Telltale is when the first ring member has a number of a few thousand.

(which means the oldest output is only a few days old)

looking

You can ignore the "out" lines here.

Columns for hte "tx" lines are height, txid, ring size, then 11 output ages in blocks.

Last one being 14-20 is also a likely giveaway.

okay, thank you

I see a lot such transactions even in month old blocks in that file

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+?

not too surprising, given how long attacks have been ongoing

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.

I'm still trying to filter the data from the download

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

moneromooo can you prepare the similar file for May 2019 when there was no attack (presumably) and a lot of legit transactions

Yes.

for one arbitrary ring to be compromised each day with ringsize 11, that would require oversight of 38% of outputs distributed uniformly

actually that's assuming all 1-in, so that's not actually quite true. Actually less than 38% then

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

<+moneromooo> Some asshole spamming the network with non standard picks. <-- any numbers on how many of the transactions are like this?

14-20 is actually pretty common overall. So not a sign.

sech1: townforge.net//dist/output-age-output-may-2019.xz

I have some rough data coming up soon with the last month numbers (not May 2019's)

Hmm, I know that with a (2+)-in transaction, I can reference the same output in multiple rings

But can I also make a single ring that references the same output 11 times?

Mathematically I don't see why it wouldn't work

Yes I think

That'd be some good FUD material

The main harm is to the sender of the tx in that case

Correct, it would be modifying your software to shoot your own foot

Which seems on brand for certain trolls

You can't use the same output more than once in a ring.

You can still do plenty of other dumb things though.

Interesting: i.imgur.com/kmqlkDf.png

This is the age of the oldest output in a ring (normalized, Y-axis is in promille)

I mean 1/1000

Matches the tx rate almost doubling.

No, it's normalized

I divided by the total number of txs and then multiplied numbers by 1000

So it shifted towards younger outputs in the last month

Well, almost twice the ratio of very recent, no ?

and there's also a peak at ~186 days

yes, 2 times more very recent outputs

For the last month, about 15% of txs have their max decoy block height less than 10000 blocks

s/decoy/output

Half have their oldest output less than 60000 blocks old

Those are rings actually, not txs

I only see about 3000 rings with max age less than 1000 blocks

Which is ~0.3%

sech1: are we getting different numbers on those?

I don't know, I need to rewrite my script to count it

For the last month, I have half rings with oldest output less than 61*720 = 43920 blocks

For May 2019, it's 107*720 = 77040 blocks

Cumulative graph: i.imgur.com/yhHx0ca.png

It's weird. I can see your images, but I can't see most others from imgur, I get a "you need JS" page...

It's direct links to static images

Where in the codebase is the output selection algorithm?

wallet2.cpp, grep for "gamma".

Ignore the triangular distribution stuff, it's only used for pre-rct now.

gamma_picker class?

Yes.

blocks_to_consider is limited to 1 year? What if someone spends older output?

No idea. I don't remember that. Let me read code...

nevermind, it's a limiting parameter

it's only used to calculate average output time

*not a limiting parameter

sech1: y axis is %*10?

sgp_ yes

per mille (1/1000)

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

average_output_time and logic around it assumes that tx flow was constant

Does it explain such a large shift ?

well, we did have more than 2 times fewer transactions a year ago: bitinfocharts.com/comparison/monero-transactions.html#1y

Shift from two weeks ago.

Sustained.

this data doesn't scream "different selection algo used by large spammer" to me

It's not a simple math to estimate the effect of this transaction growth on output selection as it is now

right, and other user behavior would change it too

on the other hand, transaction growth will skew real spending to younger outputs too, so I think gamma_picker logic is correct here

I was kinda confusing tx volume and output age. The sustained shift that feels like a good outlier is the number of txes.

based on the conversation earlier, I assumed something like 20% of new txs used outputs all less than 10000 blocks

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?

Stopgap measure, in the event of a suspected attack, you can dump some funds in and add a base level of known secure txes

not amazing if the behavior is predictable somehow

handling timing would be kinda difficult

Worth looking into?

imo not really

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

bad idea to spam the chain with useless transactions for eternity

it's already approaching 100 GB

at the moment transactions are basically free at ~$0.002

so only ~$1k for 15000 tx/day

for a month

ArticMine: what's keeping us from increasing the base fee?

obvi the fact that monero's gonna be worth 9 kajillion dollars tomorrow.

what about lowering the 300kb thingy

need to use chainlink to tie base rate to usd value

clearly

Monero could 100x vs USD and the base fee would still be cheap

Well, maybe reasonable not SUPER cheap

$0.20 seems reasonable to me

$13100 per XMR seems also reasonable to me :P

Be funny if we then found out that XMR price is always relative to transaction fee cost, as opposed to the other way around.

in comparisons to other "privacy" coins that I see frequently posted, XMR seems to already have the most expensive fees of the class

hyc: yeah but those have even less use. ZEC's z2z fees are artificially low

my gut feeling is that the base fees should be 10x higher

you want a contentious fork?

it's too late to increase fees

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

not sure where contentious fork comes from

contentious because users will not want higher fees without a very good reason.

Yeah.I don’t know how well that would go over unless we have clear data that an attack is ongoing.

Low fees are a big selling point for people and one of the most frequent “pros” brought up.

The best way to combat flooding attacks is to get more people to use Monero 😉

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

we're at something like 1/4th of ATH in XMR/USD. 4x for fees doesn't seem huge

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

like, will people REALLY walk away if fees go up to $0.01

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

There just needs to be a clear reason with supporting data

Especially since it will likely need to be rolled back later on because its based on fiat value

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.

And will bring heavy “centralized” FUD for some good reason

I doubt it would actually be a contentious hard fork

the current fee was set exactly like that though sethsimmons

fees will always be a contentious point/change until we can develop a new model

*better model

Yes I understand, and that’s why I’m not opposed to a change with clear data to back up the necessity.

re: higher fees - would not be a major attack disincentive, if the attacker also holds significant hashrate

higher fees just puts more money in their pocket

sure

that's a different attack vector though and harder to pull off hyc

... or attacker is getting dev donations from mining software that's in common use ...

his software is less and less used these days, afaik

good to hear

😬

that's what you get when you antagonize an entire community I guess.

Good

Important to note that an attacker who spams outputs could use that data to reduce effective anon set of honest transactions

And having a common non-standard characteristic could be used as a way to make this spam set public

I think that's his plan

yes, that's been the underlying assumption in this whole discussion

OK, just had jumped in, hadn't followed everything

Quite the interesting set of attacks recently

Is this actually an ongoing attack?

yes

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?

tx increase, output selection

We know the TX increase is an attack and not related to DNMs being Monero-only now as a general rule + speculative load?

tx rate ~doubled on Sunday, 15K to 27K

are you aware of any DNM announcements (comparable to alphabay 2016) that would account for such a jump?

you all were discussing that looking back, you were concerned for about a month though right?

we were remarking on it, but maybe not yet concerned.

but there's no way these new txns are legit, with their weird output selection

A large portion of the new transactions have flawed decoy selection?

We have been averaging ~20k transactions for a while now, with a major dip around the fork of course.

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? i.imgur.com/yhHx0ca.png

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.

fun fact: you need only 600 kh/s to mine fees for 25k transactions/day

<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

<sgp_ "sarang: without special software"> What percentage of these transactions have an abnormal decoy selection?

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?

if I recall correctly it's closer to the former?

selection is per output

but it's quantized to a random output in a block after selecting output index

so we should expect an increase in # of txs to select more outputs from more recent blocks, as we see here?

yes

as long as number of txs grows

so can that explain the selection we're currently seeing?

seems like a weakness in the selection algo, should be counting blocks

(tho I recall that was a weakness before, when most blocks were empty)

"on the other hand, transaction growth will skew real spending to younger outputs too, so I think gamma_picker logic is correct here"

what we need to do is to run gamma_picker 1,000,000 times for example to add a reference line to i.imgur.com/kmqlkDf.png

probably should return to a block-based algo, but weighted so that empty blocks don't count

makes sense, agree sech1

thanks for the explanation

I think if fuk specifically was to spam, they are more likely to do so with an unmodified algo

just because anything else is more effort with no benefit

*and makes the attack much easier to detect

could be other actors dipping their toes in.