hmm might not need to migrate; just thinking about best way to do robust key aggregation; need to think more about this

ok no need to migrate, just change the way private keys are created for future wallets

Earlier suraeNoether asked me to work up how hidden timelocks would work with something like Triptych

Yeah, brag about this bro

With the single-input version, extending from 2-Triptych to 3-Triptych (as a 3-LRS) would add a single proof element regardless of ring size

This is good

It would add (for ring size `n`), an additional `n+1` elements the final verifier multiexp

This is better scaling than CLSAG, since multiexp scales as `O(n/lg(n))` or so

It's as cheap as timelocks could reasonably get in a discrete log setting afaict

The other computational complexity arises from having to do commitment offsets before passing timelock data into CLSAG/Triptych

that can't be avoided

It could be worked into the multiexp, I suppose, by adjusting how the F-S challenges are handled

and that would still be safe

This is similar to how amount commitments are offset by the verifier prior to MLSAG

You construct your new commitment list, and one of them is to zero

Do you think that the triptych paper should include the triple triptych case with encrypted time locks as a detailed example?

that construction requires `n` 2-multiexp operations

Well, it can be generalized to any dimension, like CLSAG

I hadn't done so specifically in the paper since we had a particular use in mind

Can we have a long paragraph alliterating with "triptych" and "triple"?

Triplych?

Silly rabbit, triplych's for privacy

Interestingly, the proofs for $d$-Triptych are almost identical; almost nothing changes

We can embark on the Oregon triplych

It's like how in CLSAG you deal with a single aggregated key

!!!!!!!!!!!!!!!!!!!!!!

?

this is exciting

In monero point compression is based on the even/odd distinction for y coordinate. This (github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) says verification would be faster if "Implicitly choosing the Y coordinate that is a quadratic residue". Is it worth looking into? I think monero uses this ge_frombytes_negate_vartime() to

decompress points.

It'll be like that movie road triplych with that idiot Tom green from 90s mtv

Iirc computing quadratic residues is lickety split

But I probably don't recall it corrctly

Oh duh it is easy: quad res of x in Z_p is x^((p-1)/2)

Mod p

Which is always +/- 1

1 indicates x has some y such that x = y^2 mod p

-1 indicates not

koe ^

I see

:p

Does that mean it's worth looking into (using)

Hey sarang we could take a triplych beyond the stars

Ok I'm going to stop

Uh sarang: what do you think? I know field ops are super fast, computing the quad residue should be quick. I'm not sure what sort of gains we would see, though

General field exponentiation is not fast

Oh. Then it's not worth it

After all we are talking about a parity, just a single but.

A single but what?

:D

Bit + autocorrect = butt

It's probably worth it to update Triptych to reflect the general-dimension case

show that it's effectively a `d`-LRS (but with slightly different definitions)

From the Bitcoin doc "Note that in general, taking a uniformly random 256-bit integer modulo the curve order will produce an unacceptably biased result. However, for the secp256k1 curve, the order is sufficiently close to 2256 that this bias is not observable (1 - n / 2^256 is around 1.27 * 2^-128)." I recall bringing this up some time ago. If the

rand is 2^256 then in monero 1-l/2^256 is 0.9375. IIRC Monero uses 64 byte rand, so 2^512, which would make 1-l/2^512 = 1 - 5.4e-79 (presumably acceptable). Does this story seem accurate?

Current code loops if the random number is >= l IIRC.

Yeah, this was brought up before

ok

For good reason, though

Avoiding randomness bias to the extent possible is important

should monero be using a key tag to prefix the MLSAG hash? or maybe the one-time address hash? since they both use cn_fast_hash without tag AFAIK

You mean for hash function domain separation?

It can't hurt, cryptographically speaking

MLSAG on its own does not need it

but there's risk in big implementation changes too

right, wondering since the bitcoin guys are using it with their schnorr standard, and suraeNoether recommends it for multisig

Are they just prepending some fixed flag?

yeah

Mlsag hasn't had a correct formal security definition; a new random prefix tag certainly won't hurt things and is really cheap to put in, but the security implications aren't as clear as for clsag

How so?

You don't need index-based separation for each round hash

But using a single separator for the round hash function cannot hurt

It isn't needed for the protocol in isolation

The benefit would be that the same function is used elsewhere

Fortunately for CLSAG it's an easy change, and since it isn't deployed there's no additional risks to that marginal change

That's not my point: what I am saying is that with, say, thring sigs, we have security proofs that use assumptions about the hash functions. These proofs only go through if those assumptions are true, like prefixing. But for mlsag, we don't presently have any security proof that is correct iirc, so we can't say "without prefixes, security proofs start to fail."

we use hash tags in other contexts as well, notably encoded amounts and masks for amount commitments; for CLSAG the tag can be "clsag"

Do tag do you mean salt ?

yeah

if clsag doesn't go in the next hard fork, adding salt to MLSAG might be worth considering; since it is useful for many security proofs, it's harmless to assume it would be useful for a hypothetical mlsag security proof

moneromooo: so a particular hash function could be h_1(x) := hash_to_scalar("1" | x) etc.

and then h_1 would be used for all the MLSAG round hashes

there are two kinds of precedents in monero use: encrypted payments do a ENCRYPTED PAYMENT ID TAIL = 141 which goes on end of hash h = H(x | 141), and current amount/mask encoding use "amount" and "commitment_mask" at the beginning e.g. h = H("amount", x)

Yeah, it's not particularly standardized

It could be nice to have a global table of prefix flags

then it's clear which is being used, and how

and then you can ensure there's no accidental duplication, if a standard becomes that different hash applications must use a flag from the table

there's also chacha key tail 140, something related to wallet encoding

ah right, block IDs and transaction IDs also use cn_fast_hash() without prefix

Those applications should be fine, TBH

yeah; block IDs depend on miner tx which includes unique height, and non-miner transaction IDs include key images for spent coins, which must be unique within the blockchain

anyway, it's on my roadmap list for future discussion

It's a good discussion to have

Downside is that adding complexity carries risk too

which has to be balanced against the risk of, say, unintended collisions between protocols

sarang, i have a dumb question about clsag

right now we use these dummy key images for all the amounts

but linkability only depends on the one key image

yep

The aux linking tags are only there for the algebra

wait, your offhand response answered my question. nvm

Hey, anybody know what's up with EXMR?

what an illustrious team of advisors. how do I invest?

Never heard of it

wait where's the engineer ??

ceo 4 advisor 4 manager secretary and assistant; its a bureaucracy!

Triptych paper is now generalized to a full `d`-LRS-type construction: eprint.iacr.org/2020/018

sounds like my wheel house to do a report on them. Also, is altruistic mining still a thing?

Altruistic mining is not known to be a thing, although there may be some edge cases from suboptimal implementations (analysis not performed)

Correct, there have been thousands and thousands of significantly altruistic blocks over the last few years, but none recently.

Although, to be fair, with all that proves and low transaction volume I don’t even know if they have been opportunities to construct altruistic blocks

*with bulletproof and low transaction volume

Only possible if mempool > penalty free size

Psh, thanks bulletproofs...

there's a mini project for atoc: optimal algorithm for choosing tx to go in a block, given any combination of tx weights, max block weight, and long term median

and fees of course

I guess this would be an NP-complete problem

Knapsack problem.

yes, with additional constraints

Well, not quite. But pretty close.

of course lol, people have been thinking about it for 100+ years '=D

sarang I've been reading the Bitcoin-Monero Atomic Swap paper and looking at the dalek libraries and familiarizing myself with Rust.

I am hoping to have a decent amount to discuss by our next research meeting

Word

Looking forward to it

(y)

Yes there's some interesting stuff here. I was thinking I would go back and update my CCS a little later today

I'll probably just update it to this project, if that's cool with you?

I saw this, haven't looked into it, might be relevant github.com/ElementsProject/scriptle…b/master/md/partially-blind-swap.md

rbrunner has been doing god's work with pursuing multisig usefulness, notably MMS and investigating OpenBazaar, im tearing up

interesting

atoc: you're free to do a CCS, but I have seen previous examples where there was doubt about a proposal since the person had no history with the project

Donors may wish to see both value to the community and some assurance that the proposer will complete the proposal

This is my observation, at least

I can't personally speak to your expertise or experience for any CCS, of course

hmm I see, yes this is why I was thinking I would do part-time for a month just to build up some credibility with the community

I am not asking you to endorse the CCS or even support it

just making sure I am following guidelines properly - to me it's worth a short just to see how it is received by the community

That being said, I'm glad you are interested in research!

also if you advise a better approach, i am happy to hear it. I'm not really exactly sure the best path that others have used to get funded

people usually want to see contributions to monero before being funded thru the CCS

my experience is: wrote ZtM1, asked for CCS for ZtM2 and it's been funded for over a year; it helps to coincide CCS with actual brain availability :p

and of course, my advice is make a good estimate of how much funding you need

*before they will fund a CCS proposal