Hello all

Now that I have permission to post an updated version of CLSAG to IACR, I'll be doing so after a final proofreading with minor edits

If anyone knows how to contact the folks involved with Trezor/Ledger integration, please do in order to help coordinate CLSAG integration; this would be helpful prior to any reviews/audits that may happen

Heh, next research meeting is on April Fools' Day

Fitting.

moneromooo: I've reached out to trezor and ledger folks about CLSAG support

It's been recommended to get the device_defaut CLSAG-specific functions offloaded, which I'll do presently

So me pinging cslashm right now was probably redundant.

I've just finished chatting with cslashm now, and emailed ph4r05

but thanks for reaching out as well!

Having uninterrupted trezor/ledger support during the next upgrade would be a huge benefit to users

Hi sarang

hello

What are some current projects?

CLSAG hardware support, CLSAG preprint, CLSAG code, suraeNoether's matching project, etc.

Triptych1/2 multisig support and join-type operation research

cool, is there still interest in the atomic swap project? I was working on it, but I ended up getting quite busy the last couple months

I think it's absolutely worth continuing research

Ok cool. I will get back to it. I still have some Python code

but I will probably using Rust

as it was something we had talked about previously.

How is CLSAG btw? hardware support sounds cool too

It's finishing up nicely

Getting ledger/trezor support from the start will be important

is XMR supported on Trezor one?

yet

No, only the model T currently

hey @atoc, did u see: github.com/h4sh3d/monero-swap-lib

Oh nice. I didn't realize he had a Rust lib.

I read through this though: github.com/h4sh3d/xmr-btc-atomic-swap

i think its a good starting point forking that library

dEBRYUNE what will it take to get Trezor one support? Will the Trezor team need to allow support?

yes definitely @zkao

atoc: if u would be happy at hacking bullletproofs for proving that the preimage in bitcoin and monero are the same, that would be amazing

Trezor has to write firmware for it.

zkao: a hash preimage proof was used for data in the original bulletproofs paper

that hash preimage isn't really usable in general

as in, the code was really shitty and i don't remember how to use it, and the specific preimage was hardcoded by pieter and i never quite figured out how to verify it

I definitely wasn't suggesting directly implementing it!

but in any case there is a simpler way to prove "equivanent discrete logs" across curves like what you need for an adaptor-signature based atomic swap

Yeah, I was contacted about the adaptor approach using the DL equivalence method

where you do like, a bit decomposition of the value then simultaneously rangeproof in the two curves

Right, I wrote up a version of that

ok awesome

i knew it was floating around somewhere but idk if there is a reasonable writeup

(I had previously asked you for permission to post this)

I had found an early post that had some errors, and wanted another write-up

lol wow, my memory is terrible

but awesome

nice sarang

No the idea was all andytoshi

I just wrote it down to help me understand the notation better

Oh I see.

This looks cool.

The plan is still to write a Rust implementation of this: github.com/h4sh3d/xmr-btc-atomic-swap

corrent?

It's one approach, but as andytoshi said there have been ideas for using adaptor signatures that I haven't investigated yet

to avoid the need for hash preimage stuff

I see

Yeah for now, I think an implementation will be good.

If we want to look into adaptor signatures we can discuss that too anytoshi

andytoshi *

yeah i'm around

i'm not familiar with the approach in that github link

Cool thanks. I will need to go through your ideas more in depth

oh i see, the github link involves general zkps of hash preimages etc

Ah I see. Yeah sarang introduced me to h4sh3d's work

if you can find these off-the-shelf then maybe you could do this

but if yuo have to implement the raw crypto then the adaptor signature approach is way simpler .... except that bitcoin uses ECDSA

yeah we still need an idea of the zkp portion

which makes everything harder

what is ECDSA?

it's still possible to do using a schnorr multisig on the monero side, and OP_CHECKMULTISIG on the bitcoin side

but it's a bit ugly and i haven't written it out anywhere

elliptic curve DSA sigs

andytoshi: can u elaborate a bit on the "bit decomposition of the value then simultaneously rangeproof in the two curves" or is this on sarang's writeup?

It's a way to prove knowledge of an equivalent discrete log across two groups with different generators

where you don't have a meaningful map between the groups

sarang we probably should discuss ways of implementing the zkp portion. I actually have this in my notes that it was something we needed to figure out

atoc: I have an example of the DL proof in Python

ooh nice

is that linked in your writeup/

^ research only; don't use in production

ty

that example uses the prime-order subgroups of ed25519 and ed448

this will be really useful

we still have research meetings Wednesdays?

Wednesdays at 17:00 UTC (see channel topic)

You can always add comments to the agenda issues on github if you want to provide information in advance

or just show up and present research

cool

thanks zkao sarang and andytoshi

I'll be around

hi there

sarang: can you prove for secp256k1 and ed25519 that a scala `a` result into `S` (on secp) and and `E` (on ed)?

`a` must be valid for secp and ed

You mean prove the DL equality in zero knowledge?

If so, yes

Assuming suitable hash functions are available

The example I linked used edwards groups for convenience (since I had a Python library)

Reading your python, yes. So `S = aG` and `E = aH` on respective curves and generators.

but you can replace your favorite groups

Right. Given group elements `S` and `E`, you can prove that the prover knows `a` such that (for fixed generators) `aG = S` and `aH = E`

Where `G` generates the `S`-group and `H` generates the `E`-group

Ok, then I think we can use this for the swap

This also assumes a proper restriction on the limit of `a` (since the groups are not assumed to have equal order)

So you need `a < min(|<G>|,|<H>|)`

In the swap protocol I use hash preimage to "sell" half of a private key (on ed25519), with your DL proof we can link the bitcoin address and the monero one, so the preimage is "prooved" because if one cheats the bitcoin are lost too.

(don't know if it's clear)

h4sh3d: yep, thats how they do it in grin as well, but there the btc and grin use the same curve secp256k1

so they dont need the DL equality

In the protocol we have (for each participant) a secret `k^s` (monero private spend half key) and a distinct `b` (bitcoin private key), if they are linked, with your DL proof, there is no more need for the general zkp

nice

!

yeah that's pretty cool

Do you plan to update your writeup, so it can be examined in more detail?

Will do it right now!!!

excellent

please link here when complete

I look forward to reading it h4sh3d

CLSAG device support: SarangNoether/monero 94a7daa

^ moneromooo

Thanks, will merge.

Doesn't compile. Missing an override for clsag_prepare, as the base class signature is pure.

hmm compiles for me

Ah, right, this leaves the ledger part off, fair enough. I guess cslashm will add the ledger part, and I'll merge then.

Yeah this just takes care of device_default

to get the functionality offloaded from rctSigs.cpp

OK.

Ah crap, this also doesn't include the prehash offloading

Hmm, although that can use the existing MLSAG routine

Nvm about that

Anyway, I think that commit should be sufficient to indicate what CLSAG functionality needs to be implemented for trezor/ledger integration

moneromooo: I assume not worth it to rename mlsag_prehash, even though it's common to CLSAG as well?

(this would require adjusting in ledger/trezor device files too, and perhaps somewhere in firmware...)

Rename what ?

Oh, that's the name.. Feel free to.

On one hand, renaming is good for clarity. On the other hand, needs to be changed for all devices

Alternative is to create an identical clsag_prehash that's used for the clsag routines

Unrelated... it isn't clear if this version of mlsag_prepare is actually used anywhere: github.com/SarangNoether/monero/blo…g-device/src/device/device.hpp#L227

But I don't want to leave off functionality that's needed, if there's something that I am missing

Does not look used to me either.

Damn! It would work with this eprint.iacr.org/2016/1184.pdf

But without the ability to force a key leakage in a bitcoin tx (as explain in the paper), the DL proof does not resolve everything.

It would work between ether and monero... but that's not as sexy as btc/xmr

h4sh3d[m] hmm interesting. Any ideas on a general zkp then?

No, not yet

ok, I will be thinking on this too

h4sh3d: what about 2 secrets, one controlled by bob the other by alice, that gets commited to in btc using hashes and in monero using adaptor signatures. so in monero two different txs (consuming the same output) one going to alice and valid if she learns secret s from bob, and one going to bob and valid if he learns secret s' from alice. depeding on the secret that is forced to be leaked in bitcoin, only one of txs

will become valid in monero

sorry errrr, tripping, that doesnt work

It would be so nice to get a solution that didn't require a hash-preimage-and-discrete-log proof

Avoiding the complexity of a SHA-256 circuit would be great

and especially given the relative simplicity of the cross-group discrete log equivalence proof

[keybase] <seddd>: Poly1305 circuit? :)

Avoiding circuit proofs altogether perhaps!

[keybase] <seddd>: Impossibru!!

[keybase] <seddd>: Could try sth w bulletproofs or rsa commitments if pq desired

Right, bulletproofs are an obvious candidate for a trustless circuit proof (up to some complexity barrier), but even so

As andytoshi had said, verifying the circuit would be quite the task

[keybase] <seddd>: Ye

Whereas DL equivalence is a single straightforward Schnorr-type proof

[keybase] <seddd>: ok, what efficient schnorr zkp are available?

There are many things you can do with Schnorr-type proofs

Depends what the goal is

For stuff involving hash preimages with SHA-256, seems you'd need a general circuit satisfiability proving system (which we do), as well as the circuit (which we don't)

[keybase] <seddd>: Efficient circuit verifiable on secp + Ed25519 is goal right?

The goal is a protocol that could enable safe swaps

The current version that's been proposed requires a proof of equality of a SHA-256 preimage and an ed22519 DL preimage

It does not provide such a proof

you must supply your own

If it's possible to develop such a protocol to avoid hash preimages, it's probably safer in terms of demonstrating proof correctness

[keybase] <seddd>: Do you recommended reading for relevant circuit design? Maybe we could start a reading list / current research state if one doesn't exist

TBH I don't know of any particular good resources on circuit design (versus circuit satisfiability proving system design), but would be interested to see any

[keybase] <seddd>: for sure, will post helpful articles/reading when I come across any

Please do!

I follow research on proving systems as much as possible, but know relatively very little about the state of the art on the particulars of circuit design

[keybase] <seddd>: Yeh it's above my knowledge level, y I asked for learning resources 😂 happy to go on this journey together

can we do 3 out of 4 multisig in monero?

yes

it requires several rounds of communication though, user be warned

Hi, ZtM2 proofreading is extended to April 1st (this coming wednesday) since this week I reworked chapter 3 to have a less daunting concept progression. Latest draft: pdf-archive.com/2020/03/27/zerotomo…1-1-4/zerotomoneromaster-v1-1-4.pdf