[keybase] <seddd>: How much of a concern are side-channel attacks? May I humbly suggest a constant-time switch for the ultra paranoid?

That would likely require _significant_ restructuring

[keybase] <seddd>: Mb a long-term thing for next minor/major point release?

[keybase] <seddd>: If too much work for too little added protection, I understand. Would be willing to help w/ impl fwiw

I think side-channel is only a threat to private information. There is no private information involved in validating blocks (or shouldn't be).

[keybase] <seddd>: Still going though the diffs, making headway. What is a good date for final review?

[keybase] <seddd>: UkoeHB_ only time it would concern private info iiuc is in tx recovery (includes at least pvt view key). Agreed non-constant-time doesn't seem like a huge thing in the validation context, but the proving side definitely involves long-term private info, and the variable time functions. Please correct me if I have misunderstood something

Afaik constant-time is used on the proving side, and also wallet scanning side

[keybase] <seddd>: Hmm, then I must have missed something. Will pay close attention to he proving code on my next read-through

[keybase] <seddd>: the* proving

seddd: monero-project/supercop #3

AFAIK this is constant time, but not merged yet.

[keybase] <seddd>: selsta: ty, I definitely didn't see that

Weekly meeting begins here at 17:00 UTC (about 20 minutes from now)

OK, let's go ahead and get started

The usual agenda: monero-project/meta #451

GREETINGS

Hi

Heya

Sorry I fell asleep last week

I'm feeling a bit under the weather today, so I'll try to keep things short and sweet if possible

No problem Isthmus

Let's move on to ROUNDTABLE

My list is short but hopefully interesting

The CLSAG preprint has been revised and updated on the IACR archive

Link: eprint.iacr.org/2019/654

New security model and proofs

Oh hi forgot about this :p

Alongside this, the code has been updated to make it easier to include trezor/ledger support

Plumbing for device support: SarangNoether/monero 94a7daa

Support for ledger, courtesy of cslashm: SarangNoether/monero #1

Smaller items are proofreading for UkoeHB_'s Zero to Monero update, and finalizing a PR for hash function domain separation, along with the usual literature review

Does anyone have particular questions, or otherwise have research of interest to share?

I see that Isthmus has just added to the agenda issue

n3ptune and I have been exploring tx_extra some more

neat

A few months ago @UkoeHB_ suggested that the *ordering* of tags might leak some information

This intuition turned out to be correct

link to the issue: monero-project/research-lab #61

If we look at tx_extra in the wild since 1978433 (v12) we see 8 different ways that tags are assembled

Enforcing an ordering and certain fields makes sense for uniformity; I wonder what the added time complexity would be for parsing overall

This also ties in with an idea for Janus mitigation, which would enforce a per-transaction Janus transaction key and per-output tx pubkeys

+1

And, FWIW, there was a PR yesterday from moneromooo with an idea for an encrypted-memo-type addition to extra: monero-project/monero #6410

(I have concerns about that one)

I would support encrypted memo if *length* and *inclusion* enforced in protocol. :- )

Zcash has a 512 byte encrypted memo on all z2z transactions, and people are having a lot of fun with it

(mostly whimsical fun at the moment, but I expect fun applications to follow)

Of course, this seems to overlap in functionality somewhat with encrypted pIDs

Oh yea, could just roll the PID into the memo

But yes, I agree that if included, length should be enforced for uniformity

Would it be per txn or per output?

Im a bit skeptical about scope creep, since Monero is money, not random messages

and kept small

or email

or a replacement for twitter

AIUI that PR requires a single non-change output

at least from my initial read of the code

Its use in Zcash is per-output, I believe

Can we actually do away with this messaging entirely?

?

Isthmus's research indicates that even though the extra field is technically open ended, in practice people arent implementing random things

supporting random messages with core code would directly lead to more random things in the chain

Wait can we clarify "random"

Do we mean a fixed tag that supports arbitrary payload

non-standard

I guess 'memo field' implies to me 'any random message you feel like'

Ideally encrypted

To clarify, this PR uses chacha to encrypt with the DH shared secret, including padding as needed to hit certain size resolution

what are pros of including memo field?

but it's not possible to enforce that the data are actually encrypted

does chacha index each chunk in some way (so no two chunks are likely to be the same)?

That is my question

I think the goal was to enable encrypted recipient data as desired, to reduce the likelihood of non-standard inclusion of data in extra

UkoeHB_: the chunks are appended before passing to chacha

If I'm reading the PR correctly, the chunking is just to enforce size resolution

From a technical/statistical info leak standpoint, we should either have *no* messages, or an encrypted message on *every* transactions. Which option we choose is partially a UX/design conversation.

And at that point, you basically have a larger pID setup

Yea

Which was part of my concern

Is there no way to mathematically verify that a field is encrypted?

Not for the network AFAIK

Nor is it possible in Zcash either

It is possible to assure the _recipient_ that if they can decrypt properly, the data were encrypted as expected

Ohhh yea that's how that works

But otherwise, it's just uniformly distributed data

I think that encryption or not isn't a concern, since implementers should want to harmonize with other implementations. The core impl would encrypt, so others would too

All of this begs the question do we need this memo filed and even extra

So the worst case in Zcash is that you throw a bunch of unencrypted junk into a tx that gets accepted by the network, but that the recipient won't properly decrypt

" All of this begs the question do we need this memo filed and even extra" < I would be very happy to do away with both

ArticMine: I think ultimately the extra field is useful when/if hard forks are no longer feasible.

At the very least, enforcing ordering as UkoeHB_ listed in their issue would help a lot of this

certainly not all cases though

Imagine if Janus attack wasn't discovered until after hard forks stopped happening. We'd be in Bitcoin's situation of absolute chaos

(i.e. if no extra field for wiggle room)

How would extra help

Geez, if that happened I think the issue is ossification

wallets can implement janus mitigation on their own, since it's technically unverifiable anyway

I'd like to proactively avoid a situation like that by keeping an agile codebase, not having an anything-goes tx_extra field

Anyways, lots of different pros & cons to consider for each possibility

The question at this point, I think, is to decide whether doing order enforcement (e.g. TLV) is something that a develop wishes to take on

Which ties in to whether enforcement of a consistent Janus mitigation is desirable (I think yes, it is)

After next gen tx protocol gets implemented, I imagine the stuff that can go in a hard fork will drop off quite a bit. Rather than losing the ability to make hard forks, we might just run out of hard forks to make. Once the expectation of making periodic hard forks fades away, subsequent hard forks will become much more difficult (also the case if adoption rises concurrently).

Network upgrades also have the probable advantage of encouraging client upgrades

Yeah "we might just run out of hard forks to make" is a different situation from encountering an issue (e.g. Janus) and not forking

which provide other non-consensus fixes and benefits

Regardless, let's separate the metadata question (should we enforce ordered TLV) from feature questions (should we have a memo field)

Well, TLV enforcement has a big effect on non-standard data, since it requires a stated type

I did make pseudo code for enforced sorted TLV, about 200lines

yes

But I mean that the features and the layout enforcement are closely intertwined here

Current code already mostly does sorted tlv by default

So all that needs to change is in tx validation

👍

nice

OK, so I think what should be brought up in -dev is a well-considered position for 3 things related to extra

koe, what's your github

1. Decision on TLV enforcement, and responsibility for implementation

2. Decision on Janus mitigation, and implementation

3. Musings on the new encrypted-memo idea

atoc monero-project/research-lab #61

My position is 1: yes, 2: yes, 3: not unless enforced uniformly (and then it runs up against ePIDs)

1: agree, 2: agree, 3: agree

Anyway, good things to consider here

is the janus mitigation the thing with the subaddresses?

Yes

Janus monero-project/research-lab #62

Enforcing a mitigation has the added advantage of making the number of tx pubkeys uniform

!!!

yesplz

ima just throw it out there to play devils advocate, dunno if its been stated before. What about reverting to not having subaddresses?

So you have one Janus-specific tx pubkey per transaction, and a separate additional pubkey per output

is it possible to replace tx extra completely with memo, so you don't need to sort anything

You'd need to remove all non-recipient-specific data from memo

Which IIRC moneromooo said would be a significant engineering effort

Extra isn't an inherent problem if uniformity is reasonably enforced

Oh, I was wondering something actually

Suppose we decide that each transaction should contain X, Y, and Z

gingeropolous: then Janus would no longer be a problem. That's about it afaik

What's the performance difference between having 3 separate fields versus having 1 field with 3 enforced objects

That's a good question, and I'm not sure

right. so i guess the underlying question is whether subaddresses are worth it.

The scanning benefit is huge for large sets of addresses

Hash lookups are much faster than doing multiple scans of all transactions per address

and Janus checks are only needed for transactions that are already identified as being destined for you

(and those checks are quite fast anyway)

Also note that MLSAG -> CLSAG drops average tx size by 600 bytes already

s/average/typical

Like 2 in 2 out

Yes, a 2-2 tx drops already from ~2.5 kB to ~1.9 kB

So Janus mitigation adds something like about 64 bytes back in

(more for multi-output)

Meaning there's already plenty of wiggle room

well here's hoping its the last mitigation for subaddresses.

that's a pretty good drop

We can increase the ring size

meeting is getting toward the end, so Ill add my update here: ztm2 should be ready to publish this weekend, I'm finishing up my last proofreading atm

UkoeHB_: great!

might take a bit for getmonero to update though, so we will see when I post about it

koe - i sent you an email but to reiterate it's looking really good

yeah saw that :)

Since the hour is indeed almost up, does anyone else wish to share any topics of interest?

^ thoughts?

I'm looking for projects for Fellows to work on, wondering if that seems like a good candidate

That sounds like a question for -dev or -gui TBH!

I could also have one of the software engineers implement ordered TLV if -dev wants somebody else to tackle it

Oh yea, good point

Any wish list projects for MRL? I have 2 software engineers, 1 mathematician, and some data scientists that are open to working on Monero stuff

Isthmus this seems good. i am willing to help but probably can't commit too much atm

Isthmus: perhaps pop over to -dev after meeting and let the channel know that a Fellow might be able to tackle TLV

see what the responses are

I bet moneromooo will have better knowledge of the effects that parsing would have on performance overall

well this never got much traction but Im still a fan monero-project/research-lab #59 could be a lot of work idk

Isthmus: I know this important PR needed review... monero-project/supercop #3

and if any Fellows have sufficient interest, the new CLSAG security model in the paper could use some eyes

Anyway, let's start to wrap up

I'll cover the fee, penalty and median proposal in the next meeting. By then I'll have most of this finalized

Any ACTION ITEMS to share?

Great ArticMine

@sarang i'll probably ping you tomorrow to go over some zkp ideas for atomic swap

I'll be doing some work on an older preprint, reviewing some ideas in a draft preprint that were sent to me by another researcher, and returning to some Triptych code

there are two other big projects: fully-formed audit functionality, and extensive updates to multisig; mentioned those to TheCharlatan but they really are beasts I expect

i have some resources i'd like to share

for sure

We can close up the meeting, but I'm curious later if anybody has speculation around what's going on with xmrchain.net/search?value=f6cff1edd…c4a7f42b5c3bf91457310d2166722c1316f

It has an unknown tag type, and the length is recorded incorrectly

are you sure it's a length and not a value byte?

Not sure, that's why I'm asking

All right, let's go ahead and adjourn for timing purposes, but discussions can of course continue

Thanks to everyone for attending!

Logs posted shortly on the GitHub agenda issue

fee is weird too

It breaks down like this: [tag 01][data 24485aaabc671f7d3069023c902109cf86fdd4c93fe65e042f25664c7118d260][tag 02][size 3e][data=fcaeccb51290c000c5c2748e017b2a02f58fbf97df4256d19bdaf54ab89944c7cc7b9db1ea9a3b614d7227b01b5b31d760323e23dec10b48675a70223c22][tag 0c]

Yea, it's an odd transaction in a few ways

0c isn't a known tag and it doesn't have any size or data field either, so I think the 02 tag should be size 3F

sorry I didn't mean to miss this

must be someone messing around who knows

0.002 is an old fee multiplier from v3, maybe an old implementation they are trying to bring back to life

That wasn't the multiplier, the fee was 0.002 XMR absolute

WOAH

Oops didn't mean to all caps

One of the ring members in that transaction is xmrchain.net/tx/3a2b02458c51b7f4342…7544033362e4e904fc2993f87abcf356f8c

Ha wait, nvm

all the ring members are really old

Oh yea, so it exhibits (1) anomalous tx_extra, (2) hardcoded fee, (3) unusual decoy selection algorithm

Are there any more easter eggs in this txn?

There is not much non recipient specific data in extra. Mostly the tx key. Easy to store separately.

found something a bit weird

Parsing extra should be very light performance wise.

the 1/6 in/out ring member is a subaddress tx, and has as ring member a 1/11 ring member which is also a subaddress tx, and that one too has a 1/11 ring member, and so on quite far back

moneromooo: the primary discussion, aside from Janus mitigation, was whether TLV makes sense from an engineering and performance perspective

Isthmus et al.'s investigation found that enforcing order would remove some fingerprinting

they go back to around march 2019 when a bunch of 1/11 tx appeared, and all reference each other

some kind of churning?

I'm not getting into that again. I still think it's pointless. You can stuff anything (including unsorted things) into something that matches your TLV structure. It just moves the problem one layer down.

there is a difference between what is theoretically possible, and what we can practically expect from people

case in point: as Isthmus found, barely anyone puts non-standard things in the tx extra field

non-miners/pools anyway

but, amongst those standard implementations, there are variations since there are multiple 'base configurations'

Please remember that enforcing ordering and enforcing contents are two *different* issues, and counterarguments for the latter are not applicable to the former.

Here is a concrete example:

In the last few months, we have had 473507 transactions with pubkeys followed by encrypted PID.

These are distinguishable from the 36384 transactions with encrypted PID followed by pubkeys.

(differentiated only by the ordering leaking non-standard software)

Enforcing ordering would make these 509891 indistinguishable transactions

^

moneromooo: what would be the cons of enforcing sorted TLV? My thought is, while the benefits may be debatable, at worst we have wasted some time.

Isthmus had also suggested an Insight Fellow might be interested/willing to do it

But there's little point in doing so unless there's enough consensus to accept such work in a network upgrade

It feels wrong to me. It's supposed to be freeform (though some form is needed by wallets).

If it's only me not liking it, it can go in. I'd much rather move the canonical stuff out of extra though.

It has all the advantages of "enforced TLV" and does not have the ickiness that comes with it of something half baked (my opinion only).

(all the advantages except maybe saving 32 bytes if someone doesn't want a tx key, but this is also a con (distinguishability)).

TBH simply moving all standard/enforced items out of extra seems entirely reasonable, and a much cleaner approach overall

^ I agree with mooo on implementation (designated fields for required features)

As to tx pubkeys, the proposed Janus mitigation would/should/could require tx pubkeys for all outputs (and an extra Janus key)

I am also fine without moving certain common items out of the field.

UkoeHB_: s/without/with ?

with

Heh, we need that substitution bot in here =p

(if you do a s/old/new in community, it'll repost the fixed comment for you!)

Even if that is done though, I still think sorted TLV is valuable. Enforced TLV makes it easier for wallets to coordinate on adding new kinds of features, and also makes it easier for them to ignore features they don't care about. Parsing TLV is very easy

The ability to do such coordination of non-standard features is, however, bad for uniformity in theory

and if they are allowed to add new things, might as well have some kind of expectations about uniformity

You still get fingerprinting with that

depending on adoption

yes but less fingerprinting than what we have

At the very least, enforcing order via serialization with set fields would be a huge benefit

if we have this extra field thing, what's the best we can do? imo, enforced sorted tlv

Just had a funny shower thought about PIDs but have to run into a meeting !RemindMe 3 hours

what is tlv?

type-length-value

thanks

Sarang: if you want monerobux in here you'll need to keep people from using price commands :p

But jwinterm would be happy to add it if you want sed replace, I'm sure

Oooh

having sed replace and UTC timing would be excellent

Probably other features that I don't know about too

PR notifications, maybe?

Invite monerobux

You're an admin

Add to room

it doesn't do PR notifications now

here goes nothing

Test

s/test/yay

it does have some meeting logging capability

Oh, that must be a different bot (I didn't really pay attention to bot names)

s/Tear/yay

Oof

Damn mobile

.usd

Noooooo

This room is already publicly logged (see topic)

.ban UkoeHB_

But yeah, would be nice to only have applicable features

well it works :p

like timing and sed

Okay let's try it again

.time

s/again/now?

Lemme try

Monerobux hardest worker in ecosystem

Pineapple on pizza is great

s/great/terrible

good bot

not sure if I can limit per channel commands, but sed and time module are just part of default sopel bot

so you could spin up fresh sopel bot instance for this channel

s/you/me or anyone

I suppose we can just leave this one as-is, and just remove if it gets misused

How does it log the channel?

The topic statement and link to logs should be sufficient to notify people that this happens already (and of course, anyone can log with their client anyway)

I believe it logs everything, but you can set it up to do meetings and then I can host logs on webserver

.meeting start

something like that

I forget

Oh, no need

brb

I put meeting logs on the github issues; it only takes a few minutes to do

FYI may be unavailable tomorrow; have been feeling under the weather today

sarang: hope you feel better soon

Thanks; I'm sure it's nothing of consequence

Oh yea, so I was thinking about encrypted versus unencrypted PIDs earlier. (right now both in use - 10% of txns have uPID, 83% of txns have an ePID, some have neither)

As many have pointed out - encryption cannot be verified by an outside observer. From an information content perspective, a PID tag provides contains two pieces of information:

(1) The PID itself (whose encryption or lack there of cannot be verified)

(2) A flag to mark whether #1 is encrypted or unencrypted

The second piece of information is self-reported on the honor system, could be a lie, and can’t be verified. In practice, it’s not a u/e flag, it’s a [core software]/[custom software] flag (useful mainly for transaction tree analysis)

If we do move required features/keys out of tx_extra, it’ll be nice to have just a single PID field that is officially handled as encrypted. :- )

Then if two users (sender & receiver) decide that they’re both going to flaunt core recommendations and use custom software that puts a plaintext ID in there I can’t stop them and I can’t prove it. (As opposed to now when it is literally declared to every blockchain observer)

It’s a nice silver lining, to remove 1 of the 2 pieces of information.

When you say right now, you mean when exactly ?

There are still people using long pids now that support was taken out ? 10% sounds grossly wtf...

AFAIK all wallets have taken out support for long PIDs