Isthmus is your big bang paper published anywhere? I would like to cite it

In jtgrassie's presentation he mentioned upgrading miner tx to allow multiple outputs. Are miner tx still required to have 1 output?

jtgrassie

There was never such a rule.

They curently happen to have one output, but a two or more ouput coinbase would be accepted just fine.

ok thanks

are miner tx limited to 16 outputs like RCTTypeBulletproofsV2?

No.

is the miner tx size limited in the same way as normal tx? (sounds like half the penalty-free block size)

Yes.

Well, twice the penalty free block size.

Oh, right, there's that new constraint now. I had forgot. It does not apply to the miner tx.

so plausibly someone could make a ridiculous block with just a miner tx? i.e. using a TON of outputs

Yes.

Hey @koe glad you enjoyed the Konferenco talk! Plenty of Easter eggs in the blockchain/protocol, recently found a whole new set of leaks of for the next monkon :- )

I’m with family at the moment, but I’ll give the Big Bang paper a final proofread and try to push it out later this week

(I can also point you towards a draft if it’s time sensitive.)

Very interesting questions, I hadn’t realized the miner txn had problematic structure edge cases!

We’ve been looking at miner payout/strategy anomalies over in #noncesense-research-lab (there’s some odd stuff)

When people deploy software that makes suboptimally selected blocks you can see exactly which blocks they mined (and gave up money on) and how long it took them to catch the error and fix it

no time sensitivity at all lol, let's call it a miracle if I publish ^.^

oh interesting, by monitoring the tx pool?

moneromooo according to check_tx_semantic the max transaction size is m_current_block_cumul_weight_limit - default_blob_size, am I missing something?

koe: "In jtgrassie's presentation..." I was IIRC refering to the amount of destinations the code allows for a miner tx. i.e. create_block_template

not what consensus allows.

I made a patch localy while I was building a p2pool implementation to split a miner tx to multiple recipients and it worked fine.

Miner tx as far as consensus goes it basically the same as any other tx. Apart from obviously ensuring it is not generating more XMR than it should!

thanks :)

what's the story on CLSAG? will it ever be implemented in any way?

Regarding your other question w.r.t. miner tx, a miner tx is not a rct bulletproof tx, so it has no 16 output restriction.

nvm moneromooo, jtgrassie helped me find get_transaction_weight_limit()

BTW if anyone knows about random protocol rules that belong in ZtM2 let me know when I'm online. My goal is at least 500 footnotes!

CLSAG is ready to go, basically

Proofs were being updated

does that means MLSAGs will be deprecated in 2020?

They could be

In what situation would they not be deprecated?

If there are issues found with CLSAG and it isn't deployed for some reason

It's good to see you guys making such steady progress

Since v7 there have been: bulletproofs, better commitment format, big bang mitigation, RandomX, better output selection, and better protocol level indistinguishability via >=2 outputs & dummy payment ids & 10block lock.

and pruning

What's this RingCT3.0? Future implementation for Monero?

It's a tx protocol

is there a discussion thread regarding the janus attack? very interesting exploit

I think the discussion happened on IRC.

were any decisions made?

btw monerologs.net might be helpful

12:03 <koe> were any decisions made? <-- did you read web.getmonero.org/2019/10/18/subaddress-janus.html ?

yeah it mentioned encrypting pub key or requiring a schnorr signature

and that other mitigations were being explored

Schnorr proofs will do the trick

I think you need less than that

just include rG

then verify that r*Kv = kv*(ks + Hn(kv,i))*rG

the interesting decision is what to do about 'bad' outputs, since they contain real Moneroj after all

any transaction with subaddresses is already exposed as such; all you need to do is add a tx_extra tag for `subaddress_base_tx_public_key' (or just assume the first tx pub key is the subaddy base key), then include rG with the set of tx pub keys corresponding to each output. Subaddy pub keys all use the same r scalar instead of all different ones

(the way it is currently), but non-subaddy pub keys still use different r scalars.

my notation is section 5.2-5.3 of ZtM

in 5.3.1 at the end of step 3 Bob computes the check r*Kv = kv*(ks + Hn(kv,i))*rG

it's not a protocol level defense, but only requires 32 bytes per transaction that has 1+ subaddy outputs; hell, a wallet could implement this right now

I think subaddresses and integrated addresses are in a fuzzy spot atm since originally they were not enforced in any way by the protocol, but now all tx have a dummy payment ID

You could require at the protocol level that there be a 'base tx pub key', and then either no more pub keys or exactly #outputs additional pubkeys

Without protocol requirements, any solution could be haphazard between all the wallets

which I'm sure Isthmus would have a heyday with

but at the same time it means protocol scope creep

field day*; of course, this implies Bob can use his spend key

requires*

how would you make a Schnorr proof without leaking the recipient's address (via guess and check)?

yeah nvm, just sign the shared secret rKv

Reminder: we have a research meeting in about 49 minutes.

koe: the Schnorr proof includes the expected public points in the hash challenge as usual, but does not include them as public parameters

In your notation, are you assuming the recipient knows the transaction private key `r`?

@koe "BTW if anyone knows about random protocol rules that belong in ZtM2 let me know when I'm online. My goal is at least 500 footnotes!" How about random things that should be in the protocol? In that case I've got 700 footnotes for you. 🤣

Ah curses did we lose koe

Oh Isthmus, always on about the protocol :)

Ah nvm, I see what koe meant by their notation from earlier

But I don't think it works if I'm reading it correctly; the recipient assumes one index for the LHS of the equation, but a different index has been used instead

suraeNoether: ready to get started?

sure thing, buddy

welcome everyone, to the last MRL research meeting of the year

if i had thought about it, i'd have something more in-depth prepared but it just occurred to me ;P

let's start with 1) GREETINGS

o/

hi

good and you, oh not so bad

isthmus was here mere moments ago

Kind of. Splitting headache. Looking at screen intermittently.

yikes

:(

C'est la vie.

okay, well; go away isthmus and come back when you're healthy

you'll get us all sick with headaches left and right

i have a headache now

See, we should just ban headaches at the protocol level

Not just in the wallet.

no your headache now

before we move onto 2) ROUNDTABLE I would like to bring up a single administrative issue

i would like to propose that we consider switching meeting times; we selected 17 UTC mondays essentially at random about 2 years ago

?

What's a preferred time?

nowadays, not all of our participants easily are able to attend that time, so often it's just sarang and i

so while i don't have a lot of time constraints, i wanted to hear from folks like isthmus who oftentimes have meetings at around the same time

and open the room up for general discussion about timing for meetings

ty

i know this is boring, but it's been on my mind for more than a month now

Suggestions on a better time?

an hr fro

I'm normally on Pacific time so Monday 1700 UTC is early and right when I'm getting swamped at the office

m now?

nm

I'm just here now cuz on holiday & EST

How about 18:00 or 19:00 UTC?

Weds?

Weds at 18 or 19 would be better

In that case, I think I could block it on my work calendar as a recurring event

We could always try a new datetime out and see how it goes

i second wednesdays at 18-19 UTC provisionally for the first month of the year just to see how it works out re: participation

I make sure the topic bar shows the meeting datetime

+1

OK, Wednesday at 18:00 UTC it is

Thanks! Will be very helpful for me.

okay, neato burrito

onto 2) ROUNDTABLE

since the holidays were last week, maybe we can make this not just a "here's what I did last week" thing but also a "here's what we did this year" thing, but that could end up being a... surprisingly long list

but we don't have to go in-depth

sarang or isthmus, do you guys want to begin? wait, no, isthmus: go away and treat your headache

I finished up a draft MPC for the aggregated version of RCT3 this past week

And am currently in the weeds with some Omniring stuff that has been puzzling

Additionally, my funding request is open: ccs.getmonero.org/proposals/sarang-2020-q1.html

i strongly recommend that everyone donate to sarang's funding request

well, i mean, whatever you are comfortable with

and I'm on pins and needles for any comments from suraeNoether on CLSAG or Triptych preprint updates

what i mean to say is: this is a valuable request, and if you have been considering donating to the CCS but don't know where your money will have a big impact, sarang's fund is a high priority ticket imho

Much appreciation for all the support

I'm eager to see what the next year holds in the research space, particularly relating to transaction protocols

Yea, what's our research theme for 2020

I'll obviously continue to be a huge PITA about information leaks

yes plz

"2020: zero knowledge, infinite heart"?

Ring size 2020?

Oh wait, it's not a prime number

People are going to think there's a technical reason for having prime-number ring sizes :/

Interestingly, for some protocols, you specifically _can't_ have a prime number size!

for any merkle-tree based approach, you have to stick with powers of 2

for 2020, a few things i'd like would be a formal protocol specification for a tryptich-based protocol, using ristretto, going down to the nitty gritty details of optimized arithmetic, tor integration, etc

thing is, i think we are eventually going to need to abandon the DL setting for efficiency and security reasons; either switching to multilinear pairings may be necessary for efficiency, but still boils down to computational security. on the other hand, switching to other hardness assumptions like RLWE, which are believed to be quantum-secure, is an area of active research. that assumption also has a

very different profile for use in cryptocurrencies because key sizes and signature verification speeds are very different in the new setting

my roundtable contribution from this past week: i got flu-like symptoms after xmas, so all I could do was sit around and be grumpy, so I ... copy-edited triptych and clsag

(best thing to do when grumpy is to grade papers???)

Looking forward to your notes on those

should be before 3PM today

Hooray!

It's a Festivus miracle!

i'll be switching back to matching simulation stuff literally next year

festivus miracles involve being able to use the aluminum pole on your grievances

i dont get that reference but i will google

I'll be continuing a deep-dive into some Omniring stuff this week, to determine if an issue I ran into presents a problem with any of the proofs

My roundtable is still plotting, but should be rendered shortly

after recovering from the flu, or whatever i had, though, i have to say: i feel like a million bucks and i'm super excited to finish off triptych today

endo and isthmus and sarang can all attest to the number of times per year i say i feel like a million bucks

:- )

1/4 times per year so far

when the moon hits your eye like a big pizza pie, thatsa N=1

Ah, here we go

i feel for the transcription translators who do these logs

^ non-coinbase TXNs as of late

oh my fkn god

I zoomed in on lower values there, there are some absurd outliers

so i like the idea of having an adjustable unlock time for smart contract reasons. ...

for m'kids

hey, sarang: think the range proof technique for the trigger block height in DLSAG could be janked around to hide *all unlock times*?

^ All from the last few months

Excluding the giant ones

I believe it could

Apparently unlock_time supports both unix timestamps and height... There are 13 transactions that used UNIX time and the rest are height-based

unix timestamps? did not know that

There's one transaction whose outputs will unlock in the year 46000, lol

hmmmm

i can't think of a good reason to allow unix timestamps

who uses unlock time currently?

costs of hiding all unlock times is a new range proof, but that can be batched with bulletproofs... and variable unlock times are desirable for smart contracting...

@endogenic apparently 8 different sets of people, and they all use it differently

xD

lol

the DLSAG connection is strong with this

surae is one of them

"unlock_time": 1420722551128,

i'm *really* bad at monero

Not only batched, but aggregated for logarithmic size benefits

can anyone think of a good reason to keep unlock time in plaintext?

auditability

It's also smaller

forgive me monero gods

Otherwise you have to put it into a commitment

What is the point of unlock time?

Serious question.

I need to understand the intended use cases to figure out how we should handle it

A reason to use UNIX timestamps is to not depend on block time changes.

(unreclaimable) vesting period; force-hodl

that's a fair point

If the unlock time is plaintext, then how can the hodl be forced?

Erm

*if is encrypted, how enforced

There's a range proof included, showing that the current block height exceeds the committed lock period

Can't you easily brute force it ?

The goal is to reduce heuristics around expected spends

endogenic: auditability in this case would be the same security/threat model as our confidential transactions, so that wouldn't reduce our auditability... not to mention, for the folks in the audience, monero balances are guaranteed by the unforgeability property of our signatures; if anyone is capable of cheating the monero system with our confidential transactions, they can also forge signatures with

elliptic curves, which breaks a lot more than just monero.

I second mooo's question

moneromooo: the lock time is in a Pedersen commitment

suraeNoether: was joke :)

which is perfectly hiding

isthmus: early cross-chain swap models require unlock times to elapse to use SPV

but how does recipient easily verify time til unlock isnt ridiculous through only range proof?

endogenic: it's a joke, but like a making a math joke in a math class, it's always followed up by a serious discussion of why it's funny. #mathteacherlife

That needs to be communicated to the recipient endogenic

suraeNoether: one-up'd

The range proof is included at spend time

not at output generation time

Ohhhh

So a verifier gets a yes/no, and at some point a no becomes a yes.

moneromooo: can't brute force due to sarang's observation about perfect hiding

Right ?

not quite

sarang: out of band?

When you generate the output, you specify an unlock time commitment, and transfer the plaintext version to the recipient either encrypted or out of band

I mean, from a verifier's perpective, they will need to either reject a spend, or ok it.

-_-

When the output is spent, a range proof is generated using a particular time offset against the commitment, to show the lock time has been exceeded relative to the current block height

When they stop getting a verification failure, there's no other reason (currently) other than that, no ?

Oh. I see. Thanks.

The method is a bit unintuitive until you write it out, TBH

but it's included in the DLSAG preprint

er.

moneromooo: you wouldn't be able to construct a range proof on [0, ..., N] with time offset -3

it wouldn't be a valid proof

the trickiness is in realizing how the DLSAG construction actually captures the offset

So you include the block hash at currnet block then ?

let me pull it up

But moneromooo, it's important to note that you can't simply brute-force the verification at each successive block until it succeeds

for the audience members: eprint.iacr.org/2019/595

OK, that's good enough for me. Thanks.

The signer generates the proof once, at spend time

There's some subtlety in choosing the offsets and such, to reduce heuristics, but the method makes sense

bottom of page 10, left hand column

Cost would be replacing plaintext lock times with commitments, and extending bulletproofs to include the lock proof

this would be the first step toward "private" smart contracts that depend on dev-selected unlock times

in a sense it's more basic than DLSAG, almost an independent component used in DLSAG. it should have occurred to me before that it was basically it's own construction...

It is an independent component... you can do DLSAG with plaintext trigger heights

*nod*

but it's probably a bad idea to do so

i have to step out y'all

which means it has its own stand-alone security definitions. in this case, the definitions rely on some adversarially generated blockchain, yadda yadda

I think that would be worthwhile to switch to unlock time commitments... Right now an adversary can partition (/fingerprint) the blockchain into ~20 different anonymity puddles based on unlock time alone.

When I first plotted it I was expecting a few Easter eggs, not heuristic info bleeding everywhere.

keep killin it Isthmus 🤜🤛

okay, anyone else want to present any research or thoughts at our roundtable?

If you guys are looking at making unlock time a commitment, maybe this is a good time to look at a possible semantics change for unlock time to ease future things like atomic swaps etc.

^ ooooh

How so?

yeah, please go on

Ok, my head is figuratively literally splitting in half, so I'mma peace out. Thanks y'all.

gg

By... er... thinking of the requirements you know of for atomic swaps etc, and what semantics would best match those.

See ya Isthmus; feel better

also see ya endogenic

I'm thinking in particular of the fact monero's unlock_time semantics do not match bitcoin's, and bitcoin's used for more fancy things like atomic swaps.

Ah ok

Oh but before I go, huge shoutout to @n3ptune who curated the data set

Ok ciao!

moneromooo: yeah, we need to nail down specific examples of usual atomic swaps with bitcoin and how the masked unlock times in monero will play with the unmasked lock times in bitcoin...

for sure

isthm and i are having a video call about it after he feels better. i'll take notes and we'll draft an issue.

allrighty, we are coming up on an hour

Action items, I suppose?

indeed

Mine: sending comments to sarang re: triptych and clsag, consulting with isthm about masking unlock times... which maybe we should do over IRC instead of a video call... to make a donation to sarang's funding request...

I'll be continuing that Omniring issue, editing CLSAG/Triptych based on suraeNoether's reviews, and a few odds and ends relating to code libraries and MPC

okay, my dog is crossing her legs, I have to take her out. >.< does anyone have any last questions?

Nay

I suppose we can adjourn then

when ringsize a bajillion

Soon (tm)

:)

Or the Futurama answer: "Soon enough." "That's not soon enough!"

I'll post logs to GitHub shortly

Oh, do any of (omniring, tryptich, lelantus, rct3) have "free" randomness to hide a message into ?

Remember next week's meeting will be on Wednesday (January 8) at 18:00 UTC

I haven't specifically checked this, but the use of a Bulletproof-style prover means I expect you could do this with Omniring and RCT3

For Lelantus and Triptych, unsure

But this is all speculation

OK. Don't go looking, I just thought about it and got curious, is all.

That's a good point, though

I hadn't thought about it

i agree with moneromooo that if timelocks are to be fiddled with, it would be beneficial to attempt to mimic bitcoins semantics and abilities

it seems that any changes to facilitate atomic swaps should be coordinated with tari as it is my understanding that they are planning to do atomic swaps with monero

I should see what they've been up to lately

pony mentioned it recently, and it turns out they don't know how they'll do it.

It was on this channel IIRC, if you have logs.

It's nontrivial for sure

I'll ask on their dev channel

Is "monero to monero fork" easier btw ?

Likely easier, but afaik has not been evaluated for security or other metadata leaks

The best would be "monero to fiat" ^_^

heh

DLSAG was intended to permit swaps in a way that preserves safety and indistinguishability

sarang: last activity on the tari dev irc channel was Dec 4

and it's not like they haven't been communicating

So the issue I noticed in Omniring (eprint.iacr.org/2019/580) was from the requirement on page 20 (figure 10) to invert `theta`

Which, based on the constraint vector construction, contains non-invertible field elements

Even if you define such an inverse to be zero as a matter of notation, it means you effectively zero out large portions of the vectors used in equation 3 on page 17, for example

and it's unclear what effect this has on the resulting proofs

Hopefully one of the authors can shed some light on this, in case it's simply an intended part of the vector inverse notation that carries through correctly in the proofs

Hmm, wondering now if a variation of the interactive DL game from Omniring (Theorem A.6) could be useful for the multi-index Triptych soundness proof...

They show i-DL is equivalent to standard DL

Rats, I don't think that Triptych problem reduces to a variation of i-DL

suraeNoether: I updated the multi-index Triptych soundness proof, and I think it works now

(note it also means that I updated the proof relation to account for random-weighted sums)

I'll take a look at some additional key aggregation for it later

That's fantastic; I've been delayed today so my comments will be coming tonight.

sarang, my bad just do r*Ks = (ks + Hn(kv,i))*rG; the LHS is the subaddy's tx pub key which is vulnerable to the Janus attack; the RHS is the subaddy spend key for index i times the base tx pub key

when scanning the blockchain you will see an output addressed to spend key Ks^{i} and want to make sure it's the same index key used in r*Ks^{i'}

Aye

I feel like encrypting the private tx pub key would be cheaper than Schnorr, since Schnorr is 64 bytes and a scalar is 32.

What are the drawbacks?

Having looked it over, I don't see any

The check is only done when an output is flagged, and it's cheap

If Janus has been attempted, the equality check will fail

There seemed to be not a lot of support for making mitigations default or mandatory in txs

I disagree personally