I updated monero-project/research-lab #70 with may recommendations to address this issue

thanks h4sh3d[m], grateful for your contribution and looking forward to the review process :)

Hello all

Finally online today... had to rebuild a Linux environment after it broke :/

ArticMine: really great stuff

you too UkoeHB_

Really cool to see such detailed, low-level discussion happening to make sure we're prepared well in advance of potential network events

Awesome work to all involved, the fee market + block size in Monero is one of the lesser recognized, but extremely important developments spearheaded by Monero.

*along with tail emission to make both work

Meeting here starts at 17:00 UTC (about 10 minutes from now)

.time

OK, let's get started with the meeting

GREETINGS

hello

Hi

Is this thing on?

Hello

Let's move to ROUNDTABLE, where anyone can share research of interest with the channel

Well I will start

My main contribution is on monero-project/research-lab #70

Yes, it looks like some recommendations for fees and block growth

UkoeHB_ also responded to it with questions

It deals with ah issue that is actually very serious once the block growth grows significantly

I haven't yet read in depth enough to comment, but can tell that this is very detailed/thoughtful work - thanks for contributing this pretty hefty analysis

hello

I will be talking about this also at Defcon on Friday

I second Isthmus's comment

ArticMine: awesome

At this point what I need of course is review and feedback

right

thanks sgp_

I assume that it is not your intent to get this into the October upgrade ArticMine?

The code freeze for that is August 17

speaking of that, did the janus mitigation stuff make it?

nope

darn

It is very tight for the October 17 upgrade

There are a few approaches, and not enough broad agreement about choosing one

ArticMine: I would not go for it

Next upgrade could include fee/block update, transaction structure if desired, etc.

The best alternative is to do nothing with respect to fees / scaling at this fork and keep the current reference transaction size etc.

Even with the CLSAG transaction size change?

There is no problem leaving things as they are

Which drops the transaction size by 32*(N-1) bytes per spent input, at ring size N

The other option can be a partial implementation

The drop is from ~2600 to ~2000 bytes over all for a 2 in 2 out tx

2.5 kB to 1.9 kB for 2-2

So the fees will still drop.

I noticed you also commented on sgp_'s coinbase idea ArticMine

is it okay if the fees drop? honesty fees seem super low already

Yes this is where it gats a bit interesting

If the response is to increase the ring size to mitigate this

"If the selection is algorithm is weighted towards current transactions then one would expect at most about 5% of compromised coinbase outputs in a ring" I don't think this is correct

it's closer to 20%

"If the response is to increase the ring size to mitigate this" :- D

It is also the reason I provided a second option where the reference tx is basically the same

SO it can accommodate a ring size increase

"Sorry everybody Monero got too efficient, so we had to add some extra privacy to round things out" 😅

Isthmus: lmao hilarious

transactions were so tiny we just HAD to improve privacy, sorry all

My 5% figure came from using current tx data. If one takes tx data from a year ago the results are very different

the fee stuff is not time sensitive (we need a lot more tx volume for it to be serious) so I feel it's safe to hold off one hardfork

ArticMine: I don't agree with your assessment, but it's probably not worth discussing before my Defcon talk

FWIW increasing ringsize 12-13 would put verification where it is right now

The best place is to comment on the issue in response

ArticMine: I get that, but I have nothing to add now before the talk

OK, anything else to discuss presently ArticMine?

No that is a good summary. Thanks

Thanks ArticMine

You are welcome

Isthmus: you had something on the agenda issue

Ah yea, just some quick notes

just to be clear: we are deciding we do not need to make a decision on ringsize and transaction size/fees for this month?

Unless there is a compelling reason, I do not think increasing the ring size for October should be done

and big changes to fee/size so quickly seems unwise

I am neutral on the ring size question. I will wait for sgp_ 's talk first

... but I do agree it is getting very close for the October fork

Note that it was repeatedly stated that transaction size _will_ go down

my vote is no unless it's critical

OK, Isthmus?

We drew up a rough schematic of how an outside observer with a quantum computer could might approach systematic deanonymization of the blockchain without participating in any transactions:

What assumes a candidate destination address suspected by the attacker?

Isthmus: ooooooh can we share?

sgp_: where

sgp_: without a ton of context, people might freak out unnecessarily...

I'm behind raising ring sizes. I would eventually hope we can hit three digits.

sarang: what was your question?

This assumes a noninteractive attacker just analyzing the blockchain

idk, twatter

Payment IDs and amounts are encrypted using the DH shared secret, which involves recipient address and transaction key

So are you assuming the attacker has a list of addresses they suspect could be recipients?

If so, they could use these to check

Am I reading it right above "I have relevant info but I'll send it to the media, not you" ?

?

?

nicely presented figure Isthmus

< sgp_> ArticMine: I get that, but I have nothing to add now before the talk

I have no background on this so I might be misinterpreting (I hope).

Ah @sarang I see what you mean. I have a meeting with Adam later today, and will unpack the assumptions under the hood to clarify

Given that, let's not share yet sgp_

Isthmus: yeah, same with the stealth address stuff

I think it's important to clarify what requires candidate addresses

It doesn't make everything magically ok, but it's important IMO

okay I'll not share that image

I read what you have now as "you need the chain and no other information"

Maybe the rows should be reordered (3,1,2,4)

but I don't think that's the case

but re: moo: yes I'll share all the researhc I've done on coinbase rings at Defcon after discussing them here for years

also: "key signature" -> "key image"?

will be good to have a talk

Ah, so this is just stuff already discussed, fine then.

In other words, step 1 would be using Shor's + Grover's to extract real address from stealth address, then use that moving forward for the other decryptions

But yea, lemme have some offline conversations and clarify next week

ahhahaa "key signature"

that was my bad, brain fart

Can you briefly explain pulling addresses from stealth?

If you pull addresses successfully, then sure, you can derive the shared secret and use it to get pID/amount

Grover's algorithm kind of lets us brute force the address space in O(sqrt(N)) whereas classical computers are limited to O(N)

Maybe O(N^(1/3)) but not committing to that yet

I'll try to get a better diagram/explanation for next week

OK

Will have thorough public writeups in the next few weeks anyways

Thanks for the update Isthmus

Completely unrelated, Neptune engineered some great systems for parsing and analyzing tx_extra

ah sorry, go ahead

We found some whimsical unencrypted PIDs, see github.com/noncesense-research-lab/…_tx_extra/blob/master/ascii_data.md

Nah, that's all

Another data point for stricter tx structure...

Thought y'all might get a chuckle out of those on-chain easter eggs

You misspelled "fingerprints" :/

If something is found just once, it's not really a fingerprint. Are there duplicates ?

haha cool stuff

Boatloads of duplicates

If boatloads, that points more to malice.

I don't think it's that magnitude of "boatloads"

well, intent is whatever, but not enough to impact network privacy for other users

"fluffypony is the best pony ever" alone was used 85 times

lol

Dates also often repeated

101 txns that had the uPID `EYEixhEvFzEcyJapqxJsoEwmeNULJYFV`

(to give some context for 'boatloads of duplicates')

cool treasure hunt

Any other questions/comments for Isthmus on his update?

If not, I'll provide an update

Shoutout to n3ptune who built the whole framework that made the treasure hunt possible

Pleased to announce that the CLSAG audit is complete: web.getmonero.org/2020/07/31/clsag-audit.html

Nice!

great post

Note that the audit report reflects the _original_ version of the preprint, not its update

cool logo too

The update contains many updates to address the reviewers' concerns and improve the security model and proofs

The code did not require any changes

Ledger and Trezor support is continuing nicely, and I'm in contact with their teams

I updated some branches/PRs for things like wallet signing, key encryption, transaction proofs

Some minor things for `monero-site`

Work related to BP+

There's been a fair amount of discussion since the BP+ CCS was posted

Isthmus: and that wasn't even me

As I'd brought up recently, the original numbers proposed for moving from BP to BP+ would not be nearly as good as the table suggests

Various people did that, IIRC.

since the authors didn't account for some optimizations consistently

The short version of this is that we'd drop 96 bytes from each transaction, with a marginal speedup (very marginal)

I'm of the opinion that BP+ is worth continuing to research and investigate, but I don't think the benefits are significant enough to rush into it

However, the CCS proposers did say they were open to the idea of auditing a hypothetical future implementation, since they have expertise relating to the BP+ construction

Any other thoughts on this?

What kind of timeline would be reasonable for BP+?

Certainly not the October upgrade

That is out of the question

But I think it could be within a few weeks to code and get initial tests up and running

Auditing would be a separate timeline, of course

Six months?

Absolutely, provided the auditors have availability

Six months between hard forks isn't manageable

At this point it's 9m min

Just want to pipe in and mention that, because the coordination is hell and a lot of people not involved don't realize how bad it got

Again, I don't think there's a particular rush for BP+ since the benefits, while present, are marginal

needmoney90: I'm not necessarily advocating for any particular upgrade timeline, to be clear

if it happens, then it happens, whenever the next update would happen anyway :p

I'm just trying to express that if it's not this update, we're nine months out min

It will not be this update

No way

No advocacy either, just statement of fact

And given how new the construction is, I would prefer that it receive additional scrutiny

It's straightforward, but still very new

Then lets us make it nine months for the next HF

I do agree with needmoney90 that a longer time would be very beneficial for coordination and ecosystem communication

Getting hardware device support for this update was a bit of an ordeal, for example

to say nothing of software wallets, exchanges, etc.

ping dEBRUYNE to remind them about the relevant post on upgrades ^

Plus code freezes, followed by translations team and wallet code

Lots of stuff has to be done in serial for a release

right

And only after code freeze

Which makes it a total nightmare

Well, it sounds like there isn't any major opposition here to a longer time

Lead time is a very valid issue

Fixing an airplane while it's in the air and all

and at any rate BP+ wouldn't make it for October

I do think the CCS proposers would produce a quality code review

And having additional researchers participating in the ecosystem is very positive

How would you suggest we go hunting

The proposers could write the code, but then they shouldn't audit it of course

needmoney90: ?

For additional researchers

What can we do to entice more people onboard?

Oh, I see you were referring to the CCS proposes as the researchers, I misread.

Still, relevant question

Proposers*

Yes, sorry for any confusion

That's also a good question, and not one I have a good answer to... researchers seem to find the project if/when they have aligned research interests

Link to the CCS for the record?

e.g. the DLSAG team, Isthmus and friends, the BP+ CCS researchers

one sec

Since we're talking about it.

BP+ CCS: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/156

Thanks.

For clarity, I am claiming that the improvements shown in Table 1 at that link are not representative of what we'd see in an implementation

at least not for verification

All right, in the interest of time, does anyone else wish to share research of general interest?

OK, in that case, let's adjourn!

Thanks to everyone for joining

I had a discussion with articmine about the potential for dynamic block times, in addition to block sizes (such that the block time can adjust in response to size increases to keep orphan rates low)

Logs will be posted shortly to the agenda issue on github

oh

nbm

we can talk about it later :D

No, feel free to continue discussion!

Adjourning is just for log purposes

So I know what to post

The general feeling I got from articmine was interest but infeasibility, but im still stuck on it.

You mean in terms of the difficulty adjustment?

It comes down to the network being able to measure the number of orphan blocks

yeah, letting it drift with some sort of multiplier as block sizes go up

I mean, does it?

thats the question. If it requires recording orphans its a nightmare

So what's the metric for this?

That was my point

Well, and the network needs to know it for verification

A miner becoming aware of orphans for recent block could include them in a subsequent block, for some reward.

that actually fixes my main concern

(small, to avoid encourating mining on not-the-tip)

ofc

my main concern was the inability to determine if an orphan from a block in the past was generated then or now

sgp_: Yes, still on my list

Only the hash is needed for that, too

to prove it passed the diff check

With respect to BP+, I am kind of hesitant about touching sensitive code in case of mere size optimizations

Seems not worth the trade-off

You need the block, or you could put some random hash with the high bits zeroed.

do we not use some sort of double hash?

hash(Blockhash)?

Because if you have the end hash passing the diff check, I dont think the block would be necessary then

dEBRUYNE: would you have felt similarly if CLSAG had no verification benefits?

only proof the work was done

sarang: yes

I would have objected against implementing it

interesting

I would have disagreed

So you'd want to supply preimages of hashes passing diff check ?

sarang> dEBRUYNE: would you have felt similarly if CLSAG had no verification benefits? <---- or BP causing the drop from 13.5 kB to 2.5 Kb?

sounds about right, yes. You wouldnt need the block by any means, just proof the work was done for it (and therefore its orphan)

ArticMine: That drop is significantly larger though

which dramatically cuts the storage requirements

I don't know if randomx does that eacxt thing at the end, but it'd seem possible to just pass the preimages if it does.

There is a risk / reward issue here so it come down to how comfortable we are with the change vs the reward

13.5 -> 2.5 was definitely worth it.

CLSAG is simple enough that it is worth it even if the verificatoin performance was unchanged IMHO.

So, now I'm wondering how to prove that the orphan presented came from the current tip

you could probably just not prove it, because you have proof its not a duplicate

Blocks have a previous block hash field :)

yes, but if we use preimages the block isnt being passed

And passing the block is out of the question for this

(onto the chain that is)

A scheme that allows people to 'redeem' orphans (any orphans) if their difficulty is below the target and previously unredeemed could work, but could possibly also be abuseable

because you could store a bunch and release them later to...I guess jump the block time?

isn't that what ethereum does? uncles?

something like that, but its for different reasons

this is intended to allow the network to raise its own block times in the event that orphan rates spike

Ethereums uncle block reward construction has been studied with respect to incentives for bad miner behavior

Could you use orphans as a way to lower your own difficulty?

That could be interesting.

Temporarily. For one block.

Doesn't create new coins, and gets balanced out by rising block times (possibly. I need to think more)

And also seems relatively less abuseable