14:34:38 <sarang> Hello all
14:35:07 <sarang> 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
14:35:53 <sarang> 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
15:16:27 <sarang> Heh, next research meeting is on April Fools' Day
15:21:42 <Inge-> Fitting.
15:21:47 * Inge- ducks
16:00:10 <sarang> moneromooo: I've reached out to trezor and ledger folks about CLSAG support
16:00:35 <sarang> It's been recommended to get the device_defaut CLSAG-specific functions offloaded, which I'll do presently
16:03:07 <Inge-> So me pinging cslashm right now was probably redundant.
16:04:01 <sarang> I've just finished chatting with cslashm now, and emailed ph4r05
16:04:10 <sarang> but thanks for reaching out as well!
16:05:23 <sarang> Having uninterrupted trezor/ledger support during the next upgrade would be a huge benefit to users
17:57:57 <atoc> Hi sarang
17:58:24 <sarang> hello
17:59:08 <atoc> What are some current projects?
18:00:56 <sarang> CLSAG hardware support, CLSAG preprint, CLSAG code, suraeNoether's matching project, etc.
18:01:06 <sarang> Triptych1/2 multisig support and join-type operation research
18:02:20 <atoc> 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
18:03:46 <sarang> I think it's absolutely worth continuing research
18:07:06 <atoc> Ok cool. I will get back to it. I still have some Python code
18:07:30 <atoc> but I will probably using Rust
18:07:45 <atoc> as it was something we had talked about previously.
18:11:03 <atoc> How is CLSAG btw? hardware support sounds cool too
18:11:24 <sarang> It's finishing up nicely
18:11:35 <sarang> Getting ledger/trezor support from the start will be important
18:11:56 <atoc> is XMR supported on Trezor one?
18:11:58 <atoc> yet
18:15:47 <dEBRUYNE> No, only the model T currently
18:24:48 <zkao> hey @atoc, did u see: https://github.com/h4sh3d/monero-swap-lib
18:27:42 <atoc> Oh nice. I didn't realize he had a Rust lib.
18:27:53 <atoc> I read through this though: https://github.com/h4sh3d/xmr-btc-atomic-swap
18:29:02 <zkao> i think its a good starting point forking that library
18:30:39 <atoc> dEBRYUNE what will it take to get Trezor one support? Will the Trezor team need to allow support?
18:30:52 <atoc> yes definitely @zkao
18:38:18 <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
18:38:49 <selsta> Trezor has to write firmware for it.
18:42:56 <sarang> zkao: a hash preimage proof was used for data in the original bulletproofs paper
18:46:22 <andytoshi> that hash preimage isn't really usable in general
18:46:50 <andytoshi> 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
18:47:15 <sarang> I definitely wasn't suggesting directly implementing it!
18:47:17 <andytoshi> 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
18:47:37 <sarang> Yeah, I was contacted about the adaptor approach using the DL equivalence method
18:47:42 <andytoshi> where you do like, a bit decomposition of the value then simultaneously rangeproof in the two curves
18:47:51 <sarang> Right, I wrote up a version of that
18:47:57 <andytoshi> ok awesome
18:48:09 <andytoshi> i knew it was floating around somewhere but idk if there is a reasonable writeup
18:48:37 <sarang> https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf
18:48:43 <sarang> (I had previously asked you for permission to post this)
18:49:40 <sarang> I had found an early post that had some errors, and wanted another write-up
18:49:55 <andytoshi> lol wow, my memory is terrible
18:49:59 <andytoshi> but awesome
18:51:15 <atoc> nice sarang
18:51:34 <sarang> No the idea was all andytoshi
18:51:47 <sarang> I just wrote it down to help me understand the notation better
18:51:56 <atoc> Oh I see.
18:52:32 <atoc> This looks cool.
18:53:03 <atoc> The plan is still to write a Rust implementation of this: https://github.com/h4sh3d/xmr-btc-atomic-swap
18:53:05 <atoc> corrent?
18:53:30 <sarang> It's one approach, but as andytoshi said there have been ideas for using adaptor signatures that I haven't investigated yet
18:53:53 <sarang> to avoid the need for hash preimage stuff
18:54:43 <atoc> I see
18:55:27 <atoc> Yeah for now, I think an implementation will be good.
18:55:56 <atoc> If we want to look into adaptor signatures we can discuss that too anytoshi
18:56:02 <atoc> andytoshi *
18:56:11 <andytoshi> yeah i'm around
18:56:42 <andytoshi> i'm not familiar with the approach in that github link
18:56:55 <atoc> Cool thanks. I will need to go through your ideas more in depth
18:57:41 <andytoshi> oh i see, the github link involves general zkps of hash preimages etc
18:57:42 <atoc> Ah I see. Yeah sarang introduced me to h4sh3d's work
18:57:49 <andytoshi> if you can find these off-the-shelf then maybe you could do this
18:58:09 <andytoshi> but if yuo have to implement the raw crypto then the adaptor signature approach is way simpler .... except that bitcoin uses ECDSA
18:58:10 <atoc> yeah we still need an idea of the zkp portion
18:58:12 <andytoshi> which makes everything harder
18:58:34 <atoc> what is ECDSA?
18:58:37 <andytoshi> it's still possible to do using a schnorr multisig on the monero side, and OP_CHECKMULTISIG on the bitcoin side
18:58:45 <andytoshi> but it's a bit ugly and i haven't written it out anywhere
18:58:45 <sarang> elliptic curve DSA sigs
19:01:27 <zkao> 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?
19:02:14 <sarang> It's a way to prove knowledge of an equivalent discrete log across two groups with different generators
19:02:21 <sarang> where you don't have a meaningful map between the groups
19:02:30 <atoc> 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
19:02:57 <sarang> atoc: I have an example of the DL proof in Python
19:04:28 <atoc> ooh nice
19:04:41 <atoc> is that linked in your writeup/
19:05:47 <sarang> https://github.com/SarangNoether/skunkworks/tree/discrete
19:05:56 <sarang> ^ research only; don't use in production
19:06:12 <atoc> ty
19:06:12 <sarang> that example uses the prime-order subgroups of ed25519 and ed448
19:07:21 <atoc> this will be really useful
19:07:59 <atoc> we still have research meetings Wednesdays?
19:08:52 <sarang> Wednesdays at 17:00 UTC (see channel topic)
19:09:19 <sarang> You can always add comments to the agenda issues on github if you want to provide information in advance
19:09:28 <sarang> or just show up and present research
19:09:59 <atoc> cool
19:10:23 <atoc> thanks zkao sarang and andytoshi
19:10:30 <atoc> I'll be around
19:15:10 <h4sh3d[m]> hi there
19:16:39 <h4sh3d[m]> sarang: can you prove for secp256k1 and ed25519 that a scala `a` result into `S` (on secp) and and `E` (on ed)?
19:17:15 <h4sh3d[m]> `a` must be valid for secp and ed
19:17:35 <sarang> You mean prove the DL equality in zero knowledge?
19:17:52 <sarang> If so, yes
19:17:59 <sarang> Assuming suitable hash functions are available
19:18:42 <sarang> The example I linked used edwards groups for convenience (since I had a Python library)
19:19:10 <h4sh3d[m]> Reading your python, yes. So `S = aG` and `E = aH` on respective curves and generators.
19:19:11 <sarang> but you can replace your favorite groups
19:19:48 <sarang> 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`
19:20:07 <sarang> Where `G` generates the `S`-group and `H` generates the `E`-group
19:20:32 <h4sh3d[m]> Ok, then I think we can use this for the swap
19:21:08 <sarang> This also assumes a proper restriction on the limit of `a` (since the groups are not assumed to have equal order)
19:21:38 <sarang> So you need `a < min(|<G>|,|<H>|)`
19:23:16 <h4sh3d[m]> 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.
19:23:30 <h4sh3d[m]> (don't know if it's clear)
19:25:24 <zkao> h4sh3d: yep, thats how they do it in grin as well, but there the btc and grin use the same curve secp256k1
19:25:57 <zkao> so they dont need the DL equality
19:27:29 <h4sh3d[m]> 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
19:27:53 <sarang> nice
19:27:54 <sarang> !
19:27:59 <atoc> yeah that's pretty cool
19:28:08 <sarang> Do you plan to update your writeup, so it can be examined in more detail?
19:29:44 <h4sh3d[m]> Will do it right now!!!
19:29:51 <sarang> excellent
19:29:58 <sarang> please link here when complete
19:31:56 <atoc> I look forward to reading it h4sh3d
19:51:49 <sarang> CLSAG device support: https://github.com/SarangNoether/monero/commit/94a7daad0f53074a28dbfb39c0ed1d68d5c40e86
19:51:53 <sarang> ^ moneromooo
19:54:10 <moneromooo> Thanks, will merge.
19:57:00 <moneromooo> Doesn't compile. Missing an override for clsag_prepare, as the base class signature is pure.
19:58:07 <sarang> hmm compiles for me
19:58:52 <moneromooo> Ah, right, this leaves the ledger part off, fair enough. I guess cslashm will add the ledger part, and I'll merge then.
19:59:23 <sarang> Yeah this just takes care of device_default
19:59:33 <sarang> to get the functionality offloaded from rctSigs.cpp
19:59:37 <moneromooo> OK.
20:00:01 <sarang> Ah crap, this also doesn't include the prehash offloading
20:02:25 <sarang> Hmm, although that can use the existing MLSAG routine
20:02:40 <sarang> Nvm about that
20:07:45 <sarang> Anyway, I think that commit should be sufficient to indicate what CLSAG functionality needs to be implemented for trezor/ledger integration
20:13:34 <sarang> moneromooo: I assume not worth it to rename mlsag_prehash, even though it's common to CLSAG as well?
20:13:59 <sarang> (this would require adjusting in ledger/trezor device files too, and perhaps somewhere in firmware...)
20:14:07 <moneromooo> Rename what ?
20:14:31 <moneromooo> Oh, that's the name.. Feel free to.
20:14:38 <sarang> https://github.com/SarangNoether/monero/blob/clsag-device/src/device/device.hpp#L225
20:14:56 <sarang> On one hand, renaming is good for clarity. On the other hand, needs to be changed for all devices
20:15:11 <sarang> Alternative is to create an identical clsag_prehash that's used for the clsag routines
20:15:53 <sarang> Unrelated... it isn't clear if this version of mlsag_prepare is actually used anywhere: https://github.com/SarangNoether/monero/blob/clsag-device/src/device/device.hpp#L227
20:16:05 <sarang> But I don't want to leave off functionality that's needed, if there's something that I am missing
20:18:07 <moneromooo> Does not look used to me either.
20:32:58 <h4sh3d[m]> Damn! It would work with this https://eprint.iacr.org/2016/1184.pdf
20:33:47 <h4sh3d[m]> 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.
20:37:27 <h4sh3d[m]> It would work between ether and monero... but that's not as sexy as btc/xmr
20:41:38 <atoc> h4sh3d[m] hmm interesting. Any ideas on a general zkp then?
21:22:08 <h4sh3d[m]> No, not yet
21:34:38 <atoc> ok, I will be thinking on this too
21:40:59 <zkao> 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
21:40:59 <zkao> will become valid in monero
21:51:07 <zkao> sorry errrr, tripping, that doesnt work
21:58:00 <sarang> It would be so nice to get a solution that didn't require a hash-preimage-and-discrete-log proof
21:58:18 <sarang> Avoiding the complexity of a SHA-256 circuit would be great
21:58:43 <sarang> and especially given the relative simplicity of the cross-group discrete log equivalence proof
21:59:19 <derpy_bridge> [keybase] <seddd>: Poly1305 circuit? :)
21:59:51 <sarang> Avoiding circuit proofs altogether perhaps!
22:00:10 <derpy_bridge> [keybase] <seddd>: Impossibru!!
22:01:11 <derpy_bridge> [keybase] <seddd>: Could try sth w bulletproofs or rsa commitments if pq desired
22:01:42 <sarang> Right, bulletproofs are an obvious candidate for a trustless circuit proof (up to some complexity barrier), but even so
22:02:01 <sarang> As andytoshi had said, verifying the circuit would be quite the task
22:02:09 <derpy_bridge> [keybase] <seddd>: Ye
22:02:13 <sarang> Whereas DL equivalence is a single straightforward Schnorr-type proof
22:02:58 <derpy_bridge> [keybase] <seddd>: ok, what efficient schnorr zkp are available?
22:03:21 <sarang> There are many things you can do with Schnorr-type proofs
22:03:42 <sarang> Depends what the goal is
22:04:22 <sarang> 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)
22:04:56 <derpy_bridge> [keybase] <seddd>: Efficient circuit verifiable on secp + Ed25519 is goal right?
22:05:12 <sarang> The goal is a protocol that could enable safe swaps
22:05:41 <sarang> The current version that's been proposed requires a proof of equality of a SHA-256 preimage and an ed22519 DL preimage
22:05:56 <sarang> It does not provide such a proof
22:05:59 <sarang> you must supply your own
22:06:45 <sarang> If it's possible to develop such a protocol to avoid hash preimages, it's probably safer in terms of demonstrating proof correctness
22:07:49 <derpy_bridge> [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
22:08:50 <sarang> 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
22:09:51 <derpy_bridge> [keybase] <seddd>: for sure, will post helpful articles/reading when I come across any
22:10:49 <sarang> Please do!
22:11:26 <sarang> 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
22:13:09 <derpy_bridge> [keybase] <seddd>: Yeh it's above my knowledge level, y I asked for learning resources 😂 happy to go on this journey together
22:15:06 * sarang going afk for the day; see everyone tomorrow
22:15:13 <zkao> can we do 3 out of 4 multisig in monero?
22:15:32 <UkoeHB_> yes
22:16:04 <UkoeHB_> it requires several rounds of communication though, user be warned
22:39:29 <UkoeHB_> 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: https://www.pdf-archive.com/2020/03/27/zerotomoneromaster-v1-1-4/zerotomoneromaster-v1-1-4.pdf