00:01:12 Commitment was recommended but never integrated AFAIK due to compatibility and communication complexity AFAIK suraeNoether 00:06:22 well my notes say a message is signed with the key, which is good news, though idk where in the code that is done 00:13:44 reading this, not promising https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/22-multisig-in-cli-wallet 00:13:53 "Now exchange addresses and compare, they must be the same." 00:15:24 ok that quote isn't relevent, but nevertheless I dont see evidence of signing 00:18:08 I would still like to see a commitment phase as indicated in our preprint :D 00:20:07 the whole thing might deserve an audit 00:25:15 It needs to be updated to reflect the paper, or acknowledged as not being what the paper represents 00:25:34 This isn't anything new 00:26:14 It required another round , and IIRC there was not interest for introducing this at the time 00:26:30 (again, I disagree) 00:30:51 https://www.youtube.com/watch?v=KOO5S4vxi0o 00:47:12 it seems like key cancellation isn't a problem for sub-N threshold aggregation 00:48:18 though maybe some edge cases.. 01:18:49 I think round robin can be reasonably avoided with 4 rounds of communication (assuming secure communication channel). Round 1: signing initiator sends the message to be signed to all possible participants (or a subset no smaller than threshold). Round 2: each participant who wishes to sign signals their intent by sending their opening components to 01:18:50 the signature to either the initiator or to all other participants. Round 3: once the initiator has collected enough intent-to-sign signals, he broadcasts a list of signers who are expected to participate (may be >= to threshold). Round 4: each participant makes sure they have all the opening components from list of planned signers (perhaps in 01:18:50 Round 3 the initiator sent out all the signer information along with the list, to each prospective signer), and completes their signature response, sending it to either the initiator or any number of other active signers. Once any signer (or observer, of any kind) collects a full valid signature, they may publish it. Each signer must make sure that 01:18:51 they only provide one response for a given opening component. If something goes wrong, repeat from Round 2. 01:21:47 in Round 4, the participant bases their response on the intersect of a sorted list of all participants, and the list of real participants, and assumes the lowest-index signer with a given key will use it to sign 01:22:32 although that implies broadcasting to >= threshold will result in some non-participating signers 01:23:04 > not >= 01:30:34 Have you read the description in the preprint? 01:31:13 not yet 01:35:02 Please do 01:35:15 ok starting now lol, got through all the other documents 01:35:59 you say preprint, was it submitted for peer review? 03:05:09 I believe suraeNoether had submitted for SBC 03:05:22 But that has a low acceptance rate 03:30:08 i think im misdefining a round.. 03:33:09 a round is more like.. 'everything you can send without doing computations' 03:38:20 or maybe 'the next round may not begin, until this one is over' 03:58:23 it seems to boil down to giving an adversary some level of control over the challenge value; the attacker can, after collaborating with the signer on a number of signatures (or maliciously aborted signatures), use Wagner's algorithm to produce a forgery 03:58:30 interesting 04:02:05 since the response is only secure when both opener and challenge are randomly distributed 13:01:53 So no CLSAG for this fork either, apparently ? 13:04:36 suraeNoether had requested that I put it aside temporarily while he considered additional aspects of the LRS definitions 13:05:56 So you'd have to ask him 13:06:28 FWIW the security model is better than that of MLSAG, and we had agreed that no LRS model we've seen is ideal 13:07:35 By "put it aside", you don't mean the searching for reviewers right ? That goes on in parallel. 13:08:55 Correct 13:09:26 And that is the main obstacle AIUI. 13:09:38 Availability, yes 13:11:08 What's planned for the upcoming fork so far? 13:11:52 Any intent to delay, either this one or for a generally longer period (9 months or a year between them)? 13:12:42 CLSAG only :) 13:12:53 I don't know about 9 months vs 6. 13:13:16 If no CLSAG, then delaying seems very likely. 13:14:03 Well I will wait until suraeNoether approaches, to get his thoughts on any further changes he wishes for the security model 13:14:44 But good point about delaying. We don't need to have that oncoming wall for any review to meet. 13:15:00 Otherwise the draft preprint is sitting in overleaf, being lonely 15:04:44 I think that it makes sense to delay the hardfork if no clsag. Just have a major release instead without consensus changes 15:15:48 then people aren't going to upgrade. 15:21:29 Isn't that basically the same situation as minor upgrades? 15:22:08 gingeropolous: flash a fancy feature in their face I guess. Otherwise I guess it doesn't matter if they don't since it doesn't impact consensus 15:24:08 Now in rose gold! 15:24:29 Comes with a coupon for a free beer! 15:28:13 the point of the rolling hardforks was to establish and maintain a network participant behavior to ensure a healthy network 15:29:42 lets just enjoy a nice, non PoW related hardfork like the good ol days 15:30:11 this is maybe getting a little off-topic for this channel 15:30:31 nah, we can sprinkle some math on this 15:31:27 How about that scalar multiplication 15:31:30 Crazy, amirite 15:32:27 moneromooo: I'll have a 10-line change to the CLSAG code, FWIW... it removes some unnecessary 0-entries from a hash input 15:32:39 It's not related to security, but currently wasted cycles 15:32:44 OK 15:33:06 The entries were going to be used for some index stuff that we ended up not needing, and I never removed the 0-allocation 15:33:30 Think of the savings! 15:33:35 Fractions of a microsecond! 15:33:45 adds up 15:34:02 We could... pre divide key images by 8... 15:34:10 Fractions of a millisecond! 15:34:15 lol 15:34:34 I'm getting some new timing code up and running for CLSAG-with-timelocks today 15:34:43 See what that effect would be 15:35:21 We do pre-divide auxiliary images in CLSAG currently (currently = the test code) 15:35:32 but not the linking key image 18:00:02 moneromooo: small updates for CLSAG 18:00:04 https://github.com/SarangNoether/monero/commit/6a51185d3966d987a60f8e9304cf0e6d40161538 18:01:43 Something's out of sync already. I do have that FIELD(D) in my version. 18:02:33 OK, then you must have added that 18:02:58 I can run a diff on the sign/verify if you like 18:03:09 The rest applies fine. 18:03:20 You never had it ? 18:04:01 Actualy... Did you write the C++ code ? 18:04:22 Oh, I'm confusing with bulletproofs. nvm. 18:05:08 I wrote the C++ code, but didn't include the serialization change since I was only writing for performance testing 18:05:22 I included it now because I noticed it 18:05:51 Anyway, that means the only change is to those unused hash inputs 18:05:58 OK, so I must have added it myself then. 18:06:06 There's no effect on overall timing since it's so minor 20:27:29 suraeNoether you here by any chance? 20:27:54 what's up 20:29:35 Have you gotten a chance to look at my response to the ccs submitted? If not yet, it's fine. I wanted to discuss it with you 20:29:53 ah hey 20:29:59 i haven't seen your response yet, sorry, let me take a gander 20:30:04 No worries 20:30:09 i hope you aren't discouraged! 20:30:44 Not at all, I wanted to make sure you saw my apology. I did not mean to put your name without your approval 20:31:06 I was meaning to run it by you, and I feel bad about it now. I have amended it so far by removing your name 20:32:11 Everyone was new here at one point; no worries 20:32:35 That's part of the GitLab process for this; getting feedback and making edits as needed 20:32:44 *nod* 20:33:40 sarang and i have been talking about a list of possible problems that could use tackling, he recommended a huge list of possible projects 20:34:06 Cool yeah this was my first time submitting and I was making sure I got all the steps right, one of the most important things slipped my mind lol.. 20:34:10 Yeah, my list of interesting-sounding project is usually pretty long 20:34:18 Hmm cool 20:34:24 I'd like to take a look 20:34:41 I can list a few here; it's not a public list 20:34:58 go for it 20:35:07 Okay yes, excited to hear 20:35:24 The DLSAG preprint mentioned the possibility of CLSAG-style key aggregation, but this was not included in the paper itself due to space and time limitations 20:35:34 and the security model for DLSAG needs updating for a future submission 20:35:49 Zero to Monero (by koe) has recent additions for which they'd like review 20:36:16 BLAKE3 was just released, and I thought it could be fun to write up a Python version for test library compatibility, just for the helluvit 20:36:32 This PR needs review, from vtnerd: https://github.com/monero-project/supercop/pull/3 20:36:46 Multi-input Triptych has soundness/proof-relation questions to be answered still 20:37:18 I'd like to see an implementation of a bulletproofs circuit proving knowledge of equality between a SHA-256 hash preimage and a DL preimage (on ed25519) 20:38:08 It would be nice to analyze the ability to include arbitrary field elements in bulletproofs using a randomness-unrolling method (there's a term for this that I'm blanking on), as well as determining applicability to Triptych, RCT3, and Omniring 20:38:22 Hmm okay this is good. Just looking at this so far. I can review ZtM and the BLAKE3 project sounds interesting. 20:38:28 ^ that BP circuit one would have implications for swaps between monero and bitcoin 20:38:28 I'd like to see a test implementation of Omniring, to determine if there are any algebra issues (I have found a few that are questionable) 20:38:30 etc. 20:38:34 (the list continues...) 20:38:40 blake may be appealing for a few reasons, including it's tree-like structure 20:38:52 Note that I don't have a particular application in mind for BLAKE3, but it's a really cool design 20:39:08 my understanding is that it allows partial verification of hashes, but that paper is not high on my priority list rn 20:39:08 that was a low-priority one, but it's so new that I haven't found many implementations 20:39:45 Tell me more about BP circuit one, that could be interesting too 20:39:57 The BP paper did some timing estimates for a SHA-256 preimage circuit 20:40:11 and someone did a writeup describing an idea for XMR-BTC swaps that requires such a zk proof 20:40:25 I'd like to see a proof-of-concept implementation of this 20:40:48 Is this higher priority than the BLAKE3 project? 20:40:50 The writeup: https://github.com/h4sh3d/xmr-btc-atomic-swap 20:40:58 It's likely more applicable 20:41:06 atoc higher likelihood of seeing app... damn sarang 20:41:07 type slower 20:41:07 at least more _directly_ applicable for sure 20:41:20 oh this looks cool 20:41:57 So does an initial implementation of this exist yet? 20:41:58 I looked it over a long time ago, but haven't done anything formal with it 20:42:03 or is that what you would like to see? 20:42:04 Not that I know of 20:42:25 Interesting. I think I will like this project 20:42:26 (Note: I didn't write this, obviously!) 20:42:41 So I can't speak to the safety or correctness of the writeup's proposed protocol 20:42:52 However, the preimage proof is a building block requirement 20:42:56 Ok that's fine. Yes but it would be something interesting to discuss 20:43:21 We have a bulletproofs implementation, but it's only for range proofs (not for arbitrary circuits) 20:43:34 the dalek project has a more general one in Rust that's faster and very well written 20:43:56 So a Python implementation of this is something good? 20:44:03 Oh yes I have heard of Rust 20:44:24 Well, if the protocol turns out to be feasible/safe/practical enough to warrant it 20:44:45 Doing a general circuit BP implementation in Python would be personally interesting to me, but a lot of work 20:44:52 btw - not necessarily super relevant, but are most of your research projects done in python? 20:44:55 mm I see 20:44:57 If you use the dalek libraries in Rust, you've already got a BP circuit framework done 20:45:10 I like Python for fast proof-of-concept iteration, but it's not claimed to be secure code 20:45:18 yes indeed 20:45:36 Rust provides nice guarantees, but I am not proficient enough to iterate quickly with it 20:46:05 (so don't use my Python curve library for anything except proof-of-concept stuff that's assumed to be insecure) 20:46:23 but it is great to start initial implementation as you mention, if there are libraries for a BP circuit then this is more attractive to start with 20:47:09 Does the dev team use Rust for final implementations? I assumed it was mostly Python 20:47:27 The Monero codebase is mainly in C++ 20:47:40 Ah I see - makes sense 20:47:57 The dalek BP library: https://doc-internal.dalek.rs/bulletproofs/index.html 20:48:16 There may be other good BP libraries in other languages too 20:48:38 Oh, Benedikt Bunz had a Java library 20:48:47 Can't believe I forgot about that 20:48:58 Not sure what your language of choice is 20:49:37 This looks good - hmm I'd be interested to see that. 20:49:52 So I don't necessarily have a preference but most of my work is in C, Java, or Python 20:50:08 Rust sounds attractive because I have heard it used for other projects 20:50:45 I will look at both and see which one seems quicker just so that we can start experimenting 20:50:56 Do you use Java / Rust? 20:51:20 atoc: just to clarify, if you *want* to tackle the matching code, feel free. it's still an interesting project, and the code is in a good state for someone new to mess around with. but the project overall is nearing completion, and this is why i sort of waved you away from it. 20:51:21 I have some Python curve library stuff (and BP range proof code) in my repo 20:51:21 I used Java in the past, but don't really like it 20:51:21 I'm starting to tinker more in Rust 20:51:30 I'd like to use a language that the you guys are also familiar with (incase I need you to review code) 20:52:17 suraeNoether yes I noticed that. I think what might be best is if I take on a larger project and also help where I an to complete it 20:52:22 but as you say it's near completion 20:52:31 sarang then Rust is good with me 20:52:39 I will take a look at the dalek library more 20:52:59 If you're interested, you might find this useful: https://github.com/crate-crypto 20:53:09 Another contributor worked up CLSAG and MLSAG in Rust 20:53:13 using the Dalek libraries 20:53:35 Ah very cool 20:55:05 Well this is really very great. The paper already looks very interesting. 23:42:16 suraeNoether in the Thring paper you use several `hash' functions, e.g. H_sign(), H_com(); these are equivalent to H_com(x) == H_n(000, x), H_sign(x) == H_n(010, x). How important is it for implementations to use those prefix tags? 23:50:54 The proofs of security assume that all of them are distinct functions. I would have to examine the proofs very carefully again in order to determine how dangerous it would be to exclude the tags, but there's almost no cost to including those prefix tags, and the scheme is proven secure with them. 23:51:39 if you held a gun to my head, I would say that it's probably safe to get rid of the prefixes, but that's not how we want to think about secure software development 23:53:50 ok thanks I'll put that in my chapter; code base needs an upgrade too, I think (on several fronts); not sure how easy it would be to migrate older multisig wallets moneromooo 23:59:07 If you want to change the way keys are computed ? And define migrate.