13:59:38 <sarang> So I've been asked to participate in MCCVR (https://magicalcryptoconference.com/2020-vr)
14:00:03 <sarang> One activity will be joining a panel on the effectiveness of Bitcoin privacy
14:00:18 <sarang> But I've also just been asked to give a talk for their privacy track
14:00:27 <sarang> Any suggestions on specific topics that might be of interest to such an audience?
14:01:13 <sarang> The coordinator initially had offered a suggestion (after I asked) to discuss Schnorr signatures and Taproot (as they apply to Bitcoin specifically), but I don't really think talking about Bitcoin "privacy technologies" is the best use of such a talk
14:01:25 <sarang> Especially since the panel looks to be _entirely_ focused on Bitcoin privacy
14:01:50 <sarang> I agreed to give a talk but mentioned that I'd think more about the best topic/scope to cover
14:03:32 <kenshamir[m]> Brainstorming: something which may be interesting is the dichotomy between privacy and convenience
14:03:49 <kenshamir[m]> Since it needs to be quite general and apply to bitcoin
14:04:08 <sarang> Well, I don't think the topic necessarily needs to apply directly to Bitcoin
14:05:00 <sarang> The coordinator said I could be "very creative" in what I want to present
14:05:43 <sarang> She said the other current privacy-focused events will be the Bitcoin privacy panel and a panel/talk on P2EP/PayJoin
14:06:09 <sarang> I wonder if it might be useful to discuss privacy tradeoffs using technologies _other_ than those intended specifically for Bitcoin protocol compliance/extension
14:06:21 <sarang> But I do really like the idea of focusing on tradeoffs
14:08:24 <kenshamir[m]> Personally, I’d like to hear about what you think the future will look like for privacy
14:08:45 <kenshamir[m]> In general, it’s always interesting to hear what those who work in the field think the direction the field will be
14:10:26 <sarang> I'd have to discuss it _not_ in the context of regulation
14:10:34 <sarang> since who the heck knows what that might look like
14:11:33 <sarang> But I see projects and protocols working toward establishing scaling for new nodes, differentiating based on trust requirements, and focusing a lot on high signer ambiguity and network-layer mitigations
14:12:31 <sarang> I think the trust part will be an interesting differentiator... e.g. right now if you're willing to offload soundness to a single point of failure in a setup process, you can do interesting things with general proofs
14:13:06 <sarang> If you aren't willing to do that (like in Monero), then you have to get creative and make a lot of tricky choices
14:14:02 <sarang> Although perhaps the regulatory side is of interest as it applies to protocol development... you have projects like Zcoin and Zcash working on protocols where decisions on transparency and surveillance are influencing protocol decisions
14:14:13 <sarang> and not in a good way, IMO
14:14:34 <sarang> But I don't want to try and predict what exchanges and regulators will decide they want in 5 years...
14:46:47 <kenshamir[m]> Yeah predicting what regulators will do, may not be interesting as I would expect your insight to be more related to the technology.
14:46:47 <kenshamir[m]> The trust and succinctness trade off is very interesting. I’ve also wondered whether a trusted setup may be okay in most business usecases; maybe even a necessary stepping stone when trying to get traditional businesses to be more open.
14:46:47 <kenshamir[m]> Also whether, the fact that you can update the SRS with SNARKs like PLONK, SONIC and Marlin is now sufficient enough. Maybe we could update it every year or so?
14:47:42 <kenshamir[m]> That would counter the criticism, that the people who participated in the original SRS will be unknown in the future
14:49:02 <kenshamir[m]> Would also be interesting to hear some call to actions in the talk; what can applied/theoretical cryptographers do now or in the long term to benefit the community
14:49:18 <sarang> Sure, a trusted setup in a private or limited use case where there are already established trust profiles could make a lot of sense
14:49:41 <sarang> The trouble comes from distributed cases where such trust is hard to come by, or undesirable as a design principle
14:50:21 <sarang> FWIW I don't really know if the idea of updatable SRS really fixes things
14:50:46 <sarang> If soundness is in question and leads to false proofs being of concern, does an update really solve anything?
14:51:12 <sarang> I agree that it could be helpful for the "who were the original MPC participants" mythos that will arise long in the future
14:51:27 <sarang> Do you happen to know any concrete data for SRS updates?
14:51:45 <sarang> The last time I checked, the preprints in question never mentioned anything about update efficiency, which seemed sketchy to me at the time...
14:52:22 <kenshamir[m]> <sarang "If soundness is in question and "> Right, we have no way to check that soundness was not violated in the past. I think SHARKS was meant to fix it, but I have not heard about it for a year now
14:53:29 <sarang> Yeah, there was some kind of presentation on it, but not even a preprint...
14:53:34 <sarang> so it doesn't really exist :)
14:53:55 <kenshamir[m]> <sarang "The last time I checked, the pre"> I’m not sure of concrete data, but to update the SRS it would be quite expensive since we would need to restart the MPC
14:54:29 <sarang> And presumably all such data would need to be hauled around with the chain forever...
14:54:44 <sarang> The idea seemed interesting as a theoretical construction
14:54:44 <kenshamir[m]> In terms of efficiency, I think each participants takes about a day to generate the necessary data
14:54:59 <sarang> but seemed really bizarre as something to build in practice for a distributed system...
14:57:57 <kenshamir[m]> <sarang "And presumably all such data wou"> For the update I’m not sure, I think the chain would just need some sort of way to say “this is the new SRS”. If somehow the MPC could be done in a few minutes then my idea would make sense.
14:58:35 <sarang> Right, but the SRS tend to be huge
14:58:49 <sarang> and if you have a hundred updates, you need all of them
14:59:47 <kenshamir[m]> <sarang "but seemed really bizarre as som"> Yeah for SHARKS, it would involve a bunch of logistics such as when to run the trustless verifier and what to do if a previously accepted proof was malicious. Especially if you have finality
15:00:08 <sarang> Hooray for public CRS constructions :)
15:00:18 <sarang> Here's a hash function; use it; there's your CRS
15:00:21 <sarang> :D
15:00:25 <kenshamir[m]> <sarang "and if you have a hundred update"> Oh I see, yeah there is no way to compress that data
15:01:51 <kenshamir[m]> That’s a good point, I had not thought of the previous SRS for the chain.
15:01:51 <kenshamir[m]> But I guess once you update the blocks where the SRS applies, the node can throw it away. Still downloading all of those SRSs is non-trivial
15:02:10 <sarang> You can throw it away, but then you can't provide full-node capabilities to new nodes
15:02:21 <sarang> So it seems like a nightmare for scaling when new nodes join
15:03:36 <kenshamir[m]> Yeah, this is why I’m quite interested to see how HALO 2 solves their scaling problems
15:04:03 <sarang> AFAIK they haven't said if/how it can even apply to transaction verification
15:04:13 <sarang> The only demo code was for recursive PoW verification
15:04:17 <kenshamir[m]> With the linear verifier, maybe there is a way to decrease complexity if the techniques all work
15:04:40 <sarang> Well, there's the linear verifier, but also the entire concept of recursion, no?
15:05:04 <kenshamir[m]> I guess the prover time would not be a major problem? Since the individual Tx proofs will not be that heavy?
15:05:26 <sarang> No clue; AFAIK there are no benchmarks for this
15:05:54 <sarang> I'm taking a "let's wait and see the code, and not press releases" approach
15:06:08 <sarang> ECC claims they have internal work for this, but have not released it
15:06:22 <sarang> So once again, goes back to trust profiles :)
15:06:25 <kenshamir[m]> <sarang "Well, there's the linear verifie"> Yeah that too, I think there is always a delayed linear overheard with the recursion for the verifier, so it would be interesting to see how this is mitigated, as I believe it would need to be good enough to warrant replacing Groth16
15:06:53 <sarang> Well, and I haven't seen anything about how to even structure a recursive construction that works with transactions in a meaningful way
15:07:13 <sarang> So many questions
15:07:18 <sarang> I hope it works
15:07:27 <kenshamir[m]> Yeah same, I trust that there are some novel things being done, but I’m holding out until concrete numbers can be verified
15:07:58 <sarang> Yeah, I was peeved to see the idea of "this is definitely solved" come out of discussion about their press release
15:08:07 <sarang> It's definitely not publicly solved
15:08:42 <kenshamir[m]> Yeah, I personally think that “solved” should be publicly verified
15:08:44 <sarang> and the code they linked is very much WIP and, when I had checked, had no benchmarks relevant to a desired implementation
15:08:51 <sarang> Sure, and presumably it would be
15:09:07 <sarang> If they end up giving details, great
15:09:18 <sarang> If not, it's a press release
15:09:40 <kenshamir[m]> I think there is no choice but to give more details?
15:10:10 <sarang> If they want to implement it? Of course
15:10:14 <kenshamir[m]> Since claims have been made, details and numbers should presumably follow
15:10:31 <sarang> IIRC they said details sometime this year (but not sure on that)
15:11:11 <sarang> But until then, it's Schoedinger's Proving System
15:11:20 <sarang> It has no state of existence until observed =p
15:11:37 <kenshamir[m]> Even if they do not implement it, I think claims have been already made about things that are solved
15:12:00 <kenshamir[m]> What do you think the right course of action should should have been?
15:12:19 <kenshamir[m]> Wait until they had a paper and implementation?
15:12:29 <kenshamir[m]> Updated paper*
15:12:51 <sarang> Perhaps having technical discussions publicly?
15:13:27 <sarang> There was also a modified license with restrictions, so I don't know if the nature of its license affected their decision to develop only internally
15:13:50 <sarang> ECC seemed to be very concerned about other projects "scooping" this stuff
15:14:09 <sarang> But I _definitely_ don't want to speak for them or try to figure out how they run their business...
15:14:16 <sarang> that's certainly off topic for this channel
15:14:29 <sarang> But perhaps it speaks to the usefulness of doing technical development openly
15:14:41 <sarang> The downside is people misunderstanding the nature of works-in-progress, I suppose
15:14:54 <sarang> But the upside is transparency and verifiability and having more eyes on tough problems
15:18:51 <kenshamir[m]> <sarang "Perhaps having technical discuss"> Yeah very fair
15:19:39 <sarang> To be fair, I've found that Zcash technical discussion historically _is_ done openly, usually on GitHub
15:19:45 <sarang> and that's great for ease of access
15:20:12 <sarang> This stuff with Halo 2 seemed bizarrely different in its approach
15:20:58 <kenshamir[m]> Yeah I think the outrage was mainly due to; expectation
15:21:11 <kenshamir[m]> Not outrage... questions
15:21:17 <sarang> My utterly wild speculation is that it's to avoid other projects using the technology to gain some kind of advantage over the Zcash project, but this could be entirely not the case
15:22:14 <sarang> Trying to figure out why private businesses make decisions seems a losing effort most of the time...
15:23:07 <kenshamir[m]> This sound like the rationale conclusion. Another idea is that they were trying to usher in a way for open source projects to have an advantage over closed source projects
15:23:29 <sarang> I think it'd be wild to see a full Bulletproofs-based implementation of something like the Sapling or Heartwood protocols
15:23:50 <kenshamir[m]> I’m not proficient in licenses, so I couldn’t make heads or tails of it though
15:23:55 <sarang> Yeah, me neither
15:24:13 <sarang> There was some back-of-the-envelope stuff for Bulletproofs a while back, but I don't think anyone was crazy enough to actually build it =p
15:26:08 <kenshamir[m]> I’m actually not 100% sure what the license would cover because Halo is not well defined in my head
15:26:38 <sarang> Well, the code for sure... but you can't license math
15:26:56 <sarang> at least, you're supposed to not be able to do that...
15:27:01 <sarang> *coughRSAcough*
15:27:09 <sarang> *coughSchnorrSignaturescough*
15:27:31 <kenshamir[m]> So if I code up my own halo implementation, I can put it as MIT?
15:27:55 <kenshamir[m]> Haha, I’m glad it’s frowned upon now
15:28:01 <sarang> I am not a lawyer, but I'd think so
15:28:16 <sarang> I mean, Halo is a technique for proof recursion
15:28:24 <sarang> they didn't invent the underlying proving systems
15:28:33 <sarang> nor could they license the math behind those
15:28:58 <kenshamir[m]> I’ve also seen phrases such as “halo the commitment scheme”
15:28:59 <sarang> Of course, by the time you get it coded, the restrictive license period would be over
15:29:20 <sarang> Halo The Coloring Book!
15:29:25 <sarang> Halo The Breakfast Cereal!
15:29:28 <sarang> (Spaceballs reference...)
15:29:41 <sarang> Merchandising: Where The Real Money From The Movie Is Made (tm)
15:29:57 <sarang> "God willing, we'll all meet again in Halo 2: The Search For More Money"
15:30:17 <sarang> Was there a new approach to commitment schemes in the original construction? I don't recall
15:31:45 <kenshamir[m]> True, I guess it’s fine if that license does not affect MIT/Apache licenses
15:33:05 <sarang> No idea :/
15:33:23 <sarang> Hopefully some license experts can provide better analysis on the consequences of restrictive licenses
15:33:46 <kenshamir[m]> I don’t recall either, but I might have missed something
15:34:15 <sarang> I'm not a fan of technical topics being mixed with press and marketing messaging
15:34:22 <sarang> it just makes everything muddled and confusing :(
15:35:25 <sarang> Hopefully this project continues to improve on external messaging
15:35:42 <sarang> this project == monero
15:43:03 <sarang> kenshamir[m]: do you also follow Lelantus development at all?
15:48:00 <kenshamir[m]> <sarang "kenshamir: do you also follow Le"> Not recently, I heard there was a bug found, or do I have the wrong protocol?
15:48:18 <sarang> What bug?
15:48:39 <sarang> I know they recently overhauled their security model to follow that of Zcash a bit closer
15:48:51 <sarang> but I don't know if they ever really fixed some of the one-time addressing woes that we originally found
15:49:05 <sarang> and I haven't been following their audit/deployment at all
15:55:47 <kenshamir[m]> Oh wrong protocol, I think
15:56:01 <kenshamir[m]> <sarang "I know they recently overhauled "> Was there a rationale for this?
15:56:23 <sarang> I'm not sure
15:56:42 <sarang> Perhaps to more broadly capture the entire nature of a transaction, and not just proof security
15:57:00 <sarang> Since security of the proving system doesn't imply security of the overlying tx protocol?
15:58:52 <kenshamir[m]> <sarang "Since security of the proving sy"> Yeah that makes sense
15:59:18 <sarang> I'm really curious about what their batch processing times end up looking like
15:59:24 <kenshamir[m]> I guess unless the statement being proven encapsulates the notion of a “Tx being spent” ?
15:59:28 <sarang> The values in the preprint seem crazy good
16:00:07 <kenshamir[m]> <kenshamir[m] "I guess unless the statement bei"> Actually I’m not sure
16:00:17 <sarang> kenshamir[m]: their proof does capture that, but stuff like balance checking is outside the simple sigma protocol security definitions
16:00:30 <kenshamir[m]> <sarang "The values in the preprint seem "> Did they have code?
16:00:53 <sarang> Not at the time, but they recently released FOSS code
16:01:06 <sarang> I don't think it had full benchmarks for batching, but I'm really curious
16:01:17 <sarang> esp. since their anon sets are really large and you'd need to handle spending old funds too
16:01:25 <sarang> I had a lot of questions on how all that would work
16:01:44 <sarang> I think they were targeting something like 65K sets
16:05:06 <sarang> Reminder that our weekly research meeting starts at 17:00 UTC
16:05:07 <sarang> .time
16:05:07 <monerobux> 2020-09-16 - 16:05:07
16:05:14 <sarang> good bot
16:05:25 <kenshamir[m]> I’ll need to check out those numbers, didn’t really think that there were more improvements to be made
16:05:52 <sarang> Might have to do with library choice?
16:06:09 <sarang> And it's not clear how they compared for things like range proofs, point decodings, balance, etc.
16:06:22 <sarang> but I'm really curious how Lelantus works out in practice at the scale they were targeting
16:06:31 <kenshamir[m]> I have not been up to date with your work recently, were their numbers comparable?
16:06:49 <sarang> In theory they should be
16:06:58 <kenshamir[m]> For something like a conventional Tryptich proof <- sorry can’t spell
16:07:15 <sarang> The verification structure of Triptych is _extremely_ similar to that of Lelantus
16:07:26 <sarang> They're based on the same proving system
16:07:30 <sarang> and both require range proofs
16:07:49 <sarang> I think their bulletproofs will be a bit slower, but not by much (they use a variant of Pedersen commitments)
16:08:32 <sarang> Hmm actually they might have the advantage by avoiding separate commitment points...
16:08:41 <sarang> I need to check the verification routines
16:08:54 <kenshamir[m]> Do they compare Triptych in their updated paper?
16:10:45 <kenshamir[m]> @sarang btw were you able to draw any conclusions from your recent on these groth based proofs? Such as using one of them instead of MLSAG/CLSAG or is it still early days?
16:11:56 <sarang> Looks like they did not compare to Triptych or Arcturus, but yeah, they _would_ still have an advantage by avoiding using separate amount commitments
16:12:04 <sarang> However, they had to sacrifice one-time addressing security
16:12:08 <sarang> that was a kicker
16:12:25 <sarang> I think Groth/Kohlweiss-based protocols show a ton of promise
16:12:38 <sarang> Big downside is multisig complexity due to the change in linking tag format
16:13:03 <sarang> The only way I know to do it safely is using Paillier encryption, which requires arbitrary RSA groups
16:13:28 <sarang> I do have proof-of-concept code in Python and in C++ for both Triptych and Arcturus for non-batch timing purposes
16:14:15 <kenshamir[m]> <sarang "I do have proof-of-concept code "> Link?
16:14:16 <kenshamir[m]> <sarang "The only way I know to do it saf"> Is this a show stopper?
16:14:24 <kenshamir[m]> I’m guessing you don’t want to introduce the additional complexity
16:14:47 <sarang> It's not a show-stopper, but needs to be carefully considered
16:15:01 <sarang> esp. if it's intended for hardware devices to implement with low computational complexity
16:15:14 <sarang> and there are some annoying proofs you need to do for optimal security with the Paillier-based schemes
16:15:26 <sarang> C++ Triptych: https://github.com/SarangNoether/monero/tree/triptych
16:15:32 <sarang> C++ Arcturus: https://github.com/SarangNoether/monero/tree/arcturus
16:15:43 <sarang> Python Triptych: https://github.com/SarangNoether/skunkworks/tree/triptych
16:15:48 <sarang> Python Arcturus: https://github.com/SarangNoether/skunkworks/tree/arcturus
16:16:03 <sarang> Usual disclaimer that these were not written with production security in mind, and should not be deployed as is
16:16:46 <sarang> The Python code does support batching, but isn't useful for timing purposes
16:17:49 <sarang> Arcturus soundness also requires a non-standard hardness assumption
16:18:18 <kenshamir[m]> Thanks for the link!
16:19:02 <kenshamir[m]> <sarang "Arcturus soundness also requires"> Which one?
16:19:28 <sarang> a new one
16:19:28 <kenshamir[m]> Checking paper *
16:19:43 <sarang> I haven't been able to reduce it to a standard assumption yet :(
16:20:07 <sarang> Page 4, Definition 1
16:20:10 <sarang> https://eprint.iacr.org/2020/312
16:20:26 <sarang> A reviewer claimed to have broken it, but their example didn't work (I don't think they read the definition carefully)
16:22:46 <sarang> kenshamir[m]: if you're able to break the assumption, or reduce it to a known assumption, I would be unbelievably happy
16:22:53 <sarang> Right now it's just this weird thing
16:23:03 <sarang> I think it's a reasonable assumption, but it's totally untested
16:58:23 <sarang> OK, we'll start our meeting momentarily
16:58:35 <sarang> Agenda: https://github.com/monero-project/meta/issues/505
17:00:32 <sarang> Let's get started!
17:00:36 <sarang> First, greetings
17:00:39 <sarang> hello
17:00:43 <hyc> hey
17:00:51 <h4sh3d[m]> Hello
17:01:10 <Isthmus> Holla
17:03:00 <sarang> On to the roundtable, where anyone is welcome to share research of interest
17:03:04 <sarang> Who wishes to begin?
17:03:16 <UkoeHB_> hi
17:03:57 <UkoeHB_> not research, but it seems the hardfork protocol changes have been finalized
17:04:23 <sarang> Indeed!
17:04:42 <sarang> Binaries are set to be released, and the protocol upgrade will happen around October 17
17:04:55 <UkoeHB_> CLSAG, fixed block rewards, and chain-data-based  UTC timestamp timelocks
17:05:01 <sarang> This gives users and other ecosystem participants a month to update
17:05:03 <UkoeHB_> are the changes I know about
17:05:11 <hyc> on that note, I've been running teh new stuff on testnet for about 2 weeks
17:05:19 <sarang> Anything of note hyc?
17:05:26 <hyc> nope, decidedly boring
17:05:31 <sarang> Excellent
17:05:43 <sarang> Ledger and Trezor teams are ready as well
17:06:02 <sarang> So users of those devices should see a seamless transition, provided they keep their devices updated
17:06:16 <sarang> Thanks to everyone who participated in the upgrade process
17:06:30 <sarang> CLSAG was a particularly long road to walk...
17:07:11 <h4sh3d[m]> What's the best resource to see what changed in the transaction serialization, regarding the hardfork (directly the code I imagine)?
17:07:39 <h4sh3d[m]> So I can update the Rust library and include the new format
17:08:52 <Isthmus> Ooh I didn't know that we had a Rustnero. Where does that repo live?
17:09:26 <sarang> Good question h4sh3d[m]... I'm not sure there's something easier than examining the code, or perhaps something like the onion explorer source
17:09:28 <h4sh3d[m]> You mean this: https://github.com/monero-rs/monero-rs
17:09:52 <Isthmus> Sweet, ty
17:10:06 <h4sh3d[m]> sarang: ok, I'll check the code anyway then
17:10:38 <sarang> Might also be worth pinging moneromooo as well
17:10:41 <sarang> (ping)
17:11:10 <sarang> I can get you the serialization for CLSAG signatures specifically, if that's useful
17:12:06 <h4sh3d[m]> Yes, it is useful
17:12:28 <sarang> https://github.com/SarangNoether/monero/blob/master/src/ringct/rctTypes.h contains the signature structure etc. for CLSAG
17:12:52 <h4sh3d[m]> Thanks
17:12:54 <moneromooo> Oh hi
17:12:56 * moneromooo reads back
17:13:01 <sarang> Er, that's my branch, so it's probably not fully up to date with the project master branch
17:13:10 <sarang> whoops
17:14:04 <moneromooo> Data format changes ? I can look that up, gimme a few minutes.
17:14:10 <h4sh3d[m]> At least I have the right file with this
17:14:12 <sarang> :D
17:14:33 <sarang> Was there anything else that should be discussed related to the upgrade, now that it's been brought up?
17:15:50 <moneromooo> Oh right, what sarang pointed to actually :)
17:15:54 <sarang> :D
17:16:32 <sarang> Yeah, probably use https://github.com/monero-project/monero/blob/master/src/ringct/rctTypes.h just in case
17:16:45 <sarang> not my clone of it, which is probably a bit old
17:16:54 <moneromooo> and the rct type is 5 for those. 4 for MLSAG.
17:17:04 <sarang> Does anyone else wish to share research topics of interest?
17:17:38 <Isthmus> Quantum doc nearing completion, draft here: https://www.overleaf.com/project/5f4fc9e599cecd00017c5fe5
17:17:47 <sarang> Great!
17:18:03 <sarang> Anything of note to which we should pay particular attention?
17:18:13 <sarang> That link isn't for viewing
17:18:21 <sarang> You'll need to access the read link from the share menu
17:18:30 <sarang> It's different from the project URL
17:20:05 <Isthmus> https://www.overleaf.com/read/sqpqktvnvjkv
17:20:36 <sarang> success
17:21:02 <sarang> Any big recent changes of note?
17:21:12 <sarang> <3 line numbers
17:22:53 <h4sh3d[m]> I like 766 :D
17:23:44 <Isthmus> Added the sections about pq-crypto and mitigations
17:24:18 <sarang> No Oxford comma on L766?
17:24:20 <sarang> tsk tsk
17:25:41 <sarang> I had pointed out some issues to suraeNoether a while back, but they appear to have been addressed at first glance
17:26:18 <sarang> Namely about having access to multiple outputs, which included some incorrect math
17:27:19 <sarang> Isthmus: is there anything you'd like from this channel related to this new draft?
17:27:30 <sarang> Particular review, etc.?
17:31:50 <zkao> hello guys
17:31:59 <sarang> Hi zkao
17:32:04 <sarang> OK, well I suppose we can move on!
17:32:07 <zkao> since we're on research paper review topic, we'd like to get the atomic swap paper more widely scrutinized, vtnerd did a good job so far, so it would be great if more eyes look into it carefully and drop questions, could some people in here give more feedback?
17:32:26 <sarang> Can you summarize the comments from vtnerd?
17:33:22 <zkao> its public, on the comments of: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/168#notes
17:33:45 <h4sh3d[m]> and he wrote a little summary here https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/168#note_10278
17:33:53 <zkao> he picked up on all the differences btwn traditional atomic swaps and h4sh3ds assymetrical one
17:34:27 <sarang> Ah, there's more discussion there since I checked last; excellent
17:34:41 <sarang> Thanks for linking this
17:35:17 <zkao> his process of reading it and analysing it, made me feel like almost nobody tried to understand it yet
17:35:39 <zkao> because other people should have spelled some of that stuff before
17:35:46 <kenshamir[m]> <sarang "kenshamir: if you're able to bre"> Battery died on phone, I did think of something where we can use it to solve the DL of G with respects to H. But I think I might just have misunderstood the assumption
17:35:58 <zkao> except a few experts
17:36:35 <kenshamir[m]> > <@freenode_sarang:matrix.org> kenshamir: if you're able to break the assumption, or reduce it to a known assumption, I would be unbelievably happy
17:36:35 <kenshamir[m]>  * Battery died on phone, I did think of something where we can use it to solve the DL of G with respects to H. But I think I might just have misunderstood the assumption, or my maths is off
17:37:12 <kenshamir[m]>  * Battery died on phone, I did think of something where we can use it to solve the DL of G with respects to H. But I think I might just have misunderstood the assumption, or my maths is off.. Ahh meeting in progress, can wait for it to end.
17:37:21 <sarang> zkao: has the latest version of the preprint been posted to the IACR archive?
17:37:40 <h4sh3d[m]> Yes
17:37:44 <sarang> great
17:37:50 <h4sh3d[m]> it's submitted, not yet published
17:38:20 <h4sh3d[m]> I'll past a link as soon as it gets on the preprint server
17:38:35 <sarang> When was it submitted?
17:38:45 <sarang> They're usually pretty quick
17:38:46 <h4sh3d[m]> today :D
17:38:48 <sarang> Ah ok!
17:39:13 <h4sh3d[m]> pretty quick < some days/weeks?
17:39:14 <sarang> kenshamir[m]: I definitely want to know about this after the meeting :)
17:39:30 <sarang> h4sh3d[m]: yeah, maybe delayed a few days, but generally not too bad
17:39:51 <sarang> They're not as on top of things as arXiv for daily postings, it seems
17:41:32 <zkao> i guess you should drop it in bitcoin-wizards after its in the prepint server
17:41:49 <h4sh3d[m]> seems good yes
17:41:52 <sarang> Are you not in that channel?
17:42:00 <sarang> I can certainly link it there if you wish
17:42:28 <h4sh3d[m]> I am in the channel, yes please! :D
17:42:49 <sarang> OK :)
17:42:58 <sarang> You can of course feel free to post it there if you prefer!
17:43:08 <sarang> I don't have any particular sway in that channel
17:43:51 <sarang> I have a few things to share
17:44:11 <sarang> I did some review with suraeNoether on the post-quantum security draft
17:44:24 <sarang> Worked on the Arcturus security model to make it more clear after its last review
17:44:48 <sarang> Produced BP+ and BP Python updates to demonstrate additional hidden data embedding
17:44:51 <Isthmus> Sorry, lost internet a few. Yea, Sarang had a lot of very helpful comments
17:44:58 <sarang> Gave a presentation to a Chicago bitcoin group
17:45:12 <sarang> And am participating in this week's ongoing ESORICS conference
17:45:39 <sarang> Additionally, I've been asked to give an MCC talk soon relating to privacy
17:45:53 <sarang> I think they presumed bitcoin-related privacy, but I think that's not useful
17:48:32 <sarang> I welcome suggestions on particular topics you think might be of most use to that audience
17:49:42 <sarang> Anyway, did anyone else wish to share research topics?
17:49:48 <sarang> We're approaching the end of our scheduled hour
17:50:41 <sarang> I do wish to note that I will not be requesting community funding after the end of this month
17:50:53 <sarang> So any research meetings will need to be coordinated by someone else, if it's desired that they continue
17:51:50 <zkao> the transaction graph of bitcoin is on the clear, even if scripts get hidden with taproot, so u could push the agenda that it is not good enough, on that conference
17:51:56 <UkoeHB_> what will you be up next month, if I may ask?
17:52:27 <sarang> I have yet to finalize anything specific
17:53:50 <sarang> OK, well, I suppose we can adjourn then
17:53:58 <sarang> Thanks to everyone for joining today
17:54:07 <hyc> thanks for running the meeting
17:54:21 <sarang> kenshamir[m]: would be very interested in the details around that hardness assumption
17:54:22 <zkao> thank you for hosting
17:54:29 <h4sh3d[m]> Thanks everyone
17:55:04 <TheCharlatan> applause to sarang
17:55:09 <kenshamir[m]> <sarang "kenshamir: would be very interes"> Just looked over it again, and I'm quite excited to be proven wrong, since it will be an opportunity to learn
17:55:19 <sarang> If it's possible to reduce the assumption to knowledge of the DL of G w.r.t H then that's great
17:55:24 <kenshamir[m]> I have two ideas, will say the first one
17:55:25 <sarang> Since those are assumed to have no known DL relation
17:55:58 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/qxNMXlZSgCcPIhHWhGYOsTBR/message.txt >
17:55:59 * sarang fetches a pad and pen
17:56:28 <kenshamir[m]> Is this correct so fatr?
17:56:37 <kenshamir[m]>  * Is this correct so far?
17:57:05 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/NrRNdoknfPxSUBfpsluoSFIU/message.txt >
17:57:29 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/HiiiOwIeaAPUXZEJiCZseaVl/message.txt >
17:57:56 <sarang> n=1 looks fine, with appropriate variable renaming
17:58:43 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/DrrJkSgyyJWXIHChqZydLMtM/message.txt >
18:00:19 <kenshamir[m]> I then say that we can use this A to solve the DL of H wrt to G.  If we set R to H or Q to be G.
18:00:38 <kenshamir[m]> Can you spot an error?
18:01:01 <sarang> incorrect in that last paste
18:01:31 <sarang> The second condition is `y*(H-x*G) == 0`
18:01:58 <sarang> The last condition should be `x*Q != H`
18:02:22 <sarang> The point is that the way the indexing appears in the first two bulleted sums of the definition are "reversed" in a sense
18:02:42 <kenshamir[m]> Ahh right
18:02:58 <kenshamir[m]> updating *
18:04:24 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/LeXxcnlyMGobmnxBkzYRypil/message.txt >
18:05:18 <kenshamir[m]> sarang: What about the "I then say that we can use this A to solve the DL of H wrt to G.  If we set R to H or Q to be G." part?
18:05:40 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/fcZBpnfFmJOTEfuaHAHbQlTs/message.txt >
18:25:15 <sarang> Can you write that out as a wrapped security game?
18:25:22 <sarang> just for clarity
18:28:34 <sarang> i.e. the DL player receives `G` and `H` and needs to return the DL
18:28:41 <sarang> and passes things into the dual-target player
18:29:15 <kenshamir[m]> Ahh right, yep
18:29:33 <sarang> I think it's also important to identify the nature of the set parameter `n`
18:29:56 <sarang> Being able to pass in zero values, e.g., may suffice for arbitrary `n`
18:31:31 <kenshamir[m]> <sarang "I think it's also important to i"> Good point, I think the second idea deals with n=2 which may generalise to arbitrary n. Will need to check it again though
18:32:41 <sarang> Yeah, hopefully this approach is more straightfoward than I've been making it
18:39:20 <kenshamir[m]> I think I might have something mistaken, but not sure what
18:39:28 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/cgXgCJuFtMVbddYmfZCtRSTD/message.txt >
18:39:46 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/VOgHEILhdzYMftVGcZXewGBH/message.txt >
18:40:21 <kenshamir[m]> The Dual Target game is modified slightly, so that instead of the Challenger choosing a random G, H. It is now the G, H from the DL game
18:41:25 <sarang> Sure, the DL player takes on the role of the dual-target challenger in a wrapped game
18:42:09 <sarang> So it provides the dual-target player's input and receives its output, and can do what it wishes with them
18:50:17 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ZnUIMgQsUZotIXehONLdrJxZ/message.txt >
18:52:08 <kenshamir[m]> If the adversary sets H_k == xG. Then x will need to be the DL of H wrt to G
18:53:09 <kenshamir[m]> sarang: does that work?
18:57:18 <kenshamir[m]> My second idea was to show that if the adversary tries to cancel out each term, then he will need to know the DL of multiple pairs of random group elements which I think would be harder than the DL.
18:57:18 <kenshamir[m]> I used the fact that no matter what group element the adversary chooses, as long as it is not the identity. When we multiply by the challengers random _mu_ value, or _y_ in the case above, the element can be seen as random too.
18:57:34 <kenshamir[m]> Assuming a group of prime order
19:08:55 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/UZhDoyylfgMyThyPgYSxlQtc/message.txt >
19:09:22 * kenshamir[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/IuLvcaIsXehneBUXuROUyLzG/message.txt >
19:11:24 <kenshamir[m]> This is assuming the first part works
19:25:40 <kenshamir[m]> Have to head off now, let me know if you find any errors in the logic
19:27:04 <sarang> kenshamir[m]: sorry, have been watching a livestreamed privacy talk
21:24:20 <sarang> kenshamir[m]: if I'm reading it right, I don't think that approach works
21:24:42 <sarang> The DL player can manipulate the inputs it sends to the dual-target player, but it can't change how that player operates internally
21:25:07 <sarang> It can only receive its outputs, and use the fact that the dual-target player can win with some advantage