00:00:21 thanks 00:01:28 slow-hash.c under src/crypto/ has all the hash algorithms from what I can tell 00:01:36 pow algos* 00:01:58 where is this? 00:02:08 which repo? 00:02:28 rx* is randomx, slow-hash.c is Cryptonight. 00:02:59 It's a layer above librandomx, in tevador's repo. See submodules list for the url. 00:03:11 cool - thanks 00:03:23 ah I see 00:03:43 the repo is monero core 00:04:57 cool, I originally thought you were talking about monero core 00:05:02 but wanted to confirm lol 00:05:19 what's your background btw? Math as well? 00:05:53 mechanical engineering 00:06:39 oh nice (y) 13:44:23 good morning ^. 13:44:26 ^.^ 13:45:14 good morning koe! 13:48:26 Hello 14:51:13 Research meeting is today at 18:00 UTC (a little over 3 hours from now) 15:49:01 have updated my personal roadmap list, if anyone would like to review before the meeting. Some of my ideas have only been mentioned in passing https://www.pdf-archive.com/2020/01/29/moneroroadmapkoe012920/moneroroadmapkoe012920.pdf 15:53:23 sarang what about stirring or blending instead of mixing? e.g. "This allows block miners to spend their miner transaction outputs just like a normal transaction's output, stirring them into MLSAG rings with other normal and miner tx outputs." 15:54:15 You mean when discussing the inclusion of decoys in MLSAG/CLSAG rings? 15:54:31 interpenetrate there's another synonym 15:54:39 yeah 15:57:31 I use 'include' in 29 pages already x.x 16:00:39 Good listing of items in your roadmap for ongoing discussion 16:00:59 thanks :) 16:01:30 What do you think of including 32-64 bytes of sender-only data inside Bulletproofs? 16:01:46 I had hoped it could be used for sender-recipient data, but that isn't safe with multiple-output proofs 16:02:35 It's possible to use the rewinding process to brute-force the commitment amounts in the proof, so has to be limited to an entity that's allowed to know those 16:04:07 Im wondering about pruning, as knaccc mentioned 16:04:09 If we used per-output proofs it would be straightforward to set up sender-recipient data hiding, but then you lose all the logarithmic aggregation scaling 16:04:57 I was thinking something like the tx private key, which isn't included anywhere right now 16:05:37 Of course, that key could be generated via an indexed chain instead 16:06:37 At any rate, the data hiding couldn't be consensus-enforced anyway 16:06:40 yeah tx private key would be useful 16:06:57 If you don't know the PRNG seed, the BP data appears random (and has to) 16:07:48 Im guessing nodes would have to store the extra scalar(s) separately, to harmonize with pruning, which hyc may have a perspective on 16:08:38 which actually implies not much space savings 16:08:53 But the sender could also generate tx privkeys deterministically if it's guaranteed they aren't reused 16:09:06 meaning storing them in the BP using a seeded PRNG doesn't do much 16:09:49 You can guarantee that mostly by deriving it from your spend key + key image being spent. 16:10:02 right 16:10:06 it's possible, but necessary :) 16:10:24 Hmm. Actually. I guess if a tx fails somehow and you resend, you might reuse it... 16:10:43 right and I like that idea, as wallets can recover all the private keys by generating a list and scanning the chain for owned output's key images. With janus mitigation the base key is used for all subaddresses, and easy to test. 16:12:11 although with subaddy not much utility unless you know the recipient's address 16:12:46 or really any tx for that matter 16:23:17 moneromooo you could make it an indexed hash of vin (index corresponds with output index, if necessary); how likely is it to reuse vin for a failed tx? 16:52:19 So perhaps the ability to have prunable sender-only data stored in a BP is not as useful as I had initially hoped 16:53:27 At least it's certainly available if a use case were to arise 17:01:01 As part of this analysis, I'm investigating how data inclusion could work in RCT3, which shares an underlying proving system technique with Bulletproofs 17:01:26 Getting sender-only data included inside its proof could work similarly 17:02:03 Sender-recipient data would end up leaking the signing index, though 17:03:29 Reminder: research meeting is at 18:00 UTC (an hour from now) 17:12:15 Very high since they're recorded to be reused. 17:45:42 Good morning everyone. Friendly reminder that our research meeting begins in about 15 minutes (click the link in room topic to see the agenda). 17:54:59 Hi! 17:57:41 Agenda is here: https://github.com/monero-project/meta/issues/432 17:57:50 Logs posted there after the meeting as well 17:58:29 Let's go ahead and get started with GREETINGs 17:58:36 Hello 17:58:58 Hi 17:59:25 v Greetings 17:59:40 Heyo 17:59:43 greetings 18:00:09 hello 18:00:26 Hi 18:00:41 Let's continue with ROUNDTABLE, where anyone is welcome to share research topics of general interest (and discuss any questions arising from them) 18:00:59 Since there was so much to discuss last week, I'll try to keep the discussion focused to the extent possible, for clarity 18:01:09 I have a few brief things to mention 18:01:38 hello 18:01:40 First, I wanted to better understand the effects of including hidden timelocks in CLSAG signatures, and worked up a version of 3-CLSAG in C++ for performance tests 18:01:59 Including timelocks would negate the verification time advantages of an MLSAG-CLSAG transition 18:02:06 but would still give size benefits over MLSAG 18:02:38 A similar approach would work in Triptych, so I extended the Triptych test code to 3-Triptych for this purpose 18:02:57 And, just for completeness, updated the Triptych preprint on IACR to a general d-LRS construction 18:03:16 Here is the 3-CLSAG test code, for those interested: https://github.com/SarangNoether/monero/commit/db33d18bb889043c4bdea6d8582ffe2f6c581d28 18:03:30 And the 3-Triptych concept code: https://github.com/SarangNoether/skunkworks/commit/f7581a385d72baa3dbb60c83e8d856a9335bec1f 18:03:42 And the updated Triptych preprint: https://eprint.iacr.org/2020/018 18:04:18 I also found a very minor change to make in the existing CLSAG test code 18:04:41 Finally, suraeNoether and I have been doing more security model stuff 18:04:51 Any questions on these items from anyone? 18:05:52 not directly for sarang, but at Isthmus regarding timelock; what is the prevalence of non-zero timelock for non-coinbase tx? 18:06:09 * Isthmus starts digging around for plots 18:06:18 Absurdly prevelant 18:06:23 whether or not to include encrypted time lock depends in part on how much use it actually gets 18:06:26 used 18:07:10 Yeah, and I'm not formally advocating for it at this point; only curious about the implications 18:07:26 I think our options are to remove the silly timelock field (It's just an arbitrary integer memo field currently) or encrypt it. 18:07:34 I like that it's a straightforward application of concepts already used in Monero 18:08:03 Yeah, conceptually it's really neat 18:08:09 Will we be the first privacy coin to roll it out? 18:08:15 I expect that it will become industry standard 18:08:29 Does Zcash offer such functionality? 18:08:33 (I have not checked) 18:08:42 no clue 18:09:06 I don't think so, but not 100% confident 18:09:09 ZCash has serious scaling issues 18:09:27 Anyway, whether or not Zcash does it should not be the determining factor IMO :) 18:09:31 Merely curious 18:09:32 Oh wait. Zcash inherited nLockTime from Bitcoin 18:09:40 👀 18:09:47 I'mma fish out their information leaks too 18:09:57 And OP_CLTV 18:10:01 If implemented, it would make the most sense to bundle the timelock range proofs with the existing Bulletproofs 18:10:25 So this means the sum of timelock-enabled inputs (all inputs, if mandatory) and outputs is restricted 18:10:34 for Triptych, what are the steps between now and considering it for replacing RingCT? 18:11:19 Formal review, a determination about its effects on multisig (particularly on compute-limited hardware), a decision on Triptych vs something like RCT3 18:11:38 I have not yet examined how easy it would be to include timelocks in RCT3 with their security model 18:12:12 ^ ... and estimated recommended tx size for Triptych 18:13:35 Also note that, as I think I mentioned last week, it would not make sense to deploy hidden timelocks with MLSAG due to the poor scaling 18:13:51 agreed 18:13:51 (though technically possible) 18:14:17 Anyway, I want to make sure others have time to speak as well 18:14:22 Who else wishes to share research topics? 18:14:57 Zebra network stack looks interesting, potential applications in Monero? 18:15:12 * needmonero90 wanders in and takes a seat in the back 18:15:17 I saw that yesterday! 18:15:27 Blag post about it: https://www.zfnd.org/blog/a-new-network-stack-for-zcash/ 18:15:54 cool, will check out 18:16:08 And a corresponding forum post (not much activity there yet): https://forum.zcashcommunity.com/t/a-new-network-stack-for-zcash/35870 18:16:24 It's from Zcash Foundation research 18:18:29 Monero maintains a single state across all the peers, right? 18:19:43 That's a good question, and I don't know the answer 18:19:53 ping vtnerd 18:20:04 I had thought so, but not confident in that 18:20:23 not even sure what that means. single state? what is included in that state? 18:20:32 there is an aggregate state for bandwidth limiting 18:20:46 but sync info is per-connection 18:21:34 Oh so maybe we already take the Zebra approach? 18:21:39 It seems pretty elegant. 18:23:11 Isthmus: did you have other topics you wanted to bring up as well? 18:23:22 "Unlike zcashd, which maintains a fixed number of outbound connections, we attempt to connect to as many peers as possible, subject to resource limits " 18:23:40 this approach will be troublesome for them, since they use levelDB/rocksDB for storage 18:23:55 lvelDB/rocksDB requires thousands of file descriptors for its storage. 18:24:06 that competes with the demand for socket descriptors 18:24:14 Interesting... worth bringing up as a question on the forum? 18:24:24 One of the developers (Henry) opened the thread 18:24:27 not from me. I have no interest in helping zcash project 18:24:30 ok 18:25:03 I'm trying to make the unlock time plot, but my laptop is struggling with the 1.5 GB data set 18:25:08 they should have already known by now that their DB choice is inappropriate for a network service that uses lots of connections, but it seems they haven't discovered that yet 18:25:18 Isthmus: no rush! 18:25:31 In the meantime, koe: did you wish to address anything in particular? 18:25:39 yes muahaha 18:25:41 not technically research, my roadmap has been cleaned up a bit; in particular I want to get opinions on item koe_11, which would enable view-only wallets to know when owned outputs have been spent; also item koe_9 which would allow all wallet implementations to more or less deprecate pre-RingCT transaction versions 18:25:41 https://www.pdf-archive.com/2020/01/29/moneroroadmapkoe012920/moneroroadmapkoe012920.pdf 18:26:13 koe_11 sounds like a high priority 18:26:39 also, sarang helped me work up a decentralized CoinJoin-esque protocol (temporarily named JoinMo), which is available as chapter 9 of current ZtM2 draft 18:26:46 https://www.pdf-archive.com/2020/01/29/zerotomoneromaster-v1-0-21/zerotomoneromaster-v1-0-21.pdf 18:27:08 chapter 10* 18:27:42 I like the JoinMo approach of using per-participant shared secrets to obscure the input-output mapping 18:27:47 also, rbrunner at one time investigated OpenBazaar integration, and ran into some roadblocks, so my 'research' has been engineering solutions to those problems, which should be available next week 18:28:04 I'm giving extra scrutiny to the specifics around SAG/LSAG since the keys are per-output only 18:28:23 I was thinking about the implications of using a separate keyset for inputs as well 18:28:34 (keys = per-join participant keys, I mean) 18:28:56 however, OpenBazaar integration would likely entail a large update to the code-base, to optimize communication rounds 18:29:34 moreover, multisig in general should be updated to comply with suraeNoether's paper on the subject 18:29:39 Yes 18:30:06 Somewhat related to item 10, I'm still concerned about any blockchain observer being able to identify which transactions do not include any outputs to subaddresses. 18:30:15 n3ptune and I will make a plot of subaddress adoption over time : -) 18:30:18 But ideally that should not be possible.3 18:30:25 Also yes :) 18:30:54 It's been suggested before to standardize on some form of per-output keys for this purpose 18:31:00 but it never gained traction 18:31:59 koe: nice list! koe_9 may be controversial since spending pre-rct would stand out more, no? 18:32:15 Yeah looks like a nice list koe 18:32:32 it already stands out like a sore thumb 18:33:07 but that sort of problem will exist for RingCT as well, since spending ancient outputs is always somewhat unusual 18:33:32 and my suggestion is to start using pre-ringct outputs as decoys as well 18:33:36 If we told everyone to sweep them to themselves, would that also be too obvious? you could assume that every txn with pre-RCT inputs is going back to its sender 18:33:47 so gamma select over entire site of outputs 18:33:50 set 18:34:05 koe: do we currently only select rct randomly as decoys? 18:34:30 yes, and coinbase (not sure if pre-ringct coinbase are included) 18:34:45 coinbase are included as decoy in normal tx, which is where this idea comes from 18:34:58 then this actually makes spending pre-rct slightly less suspicious, no? 18:35:03 And the handling of coinbase outputs is by no means solved 18:35:20 This is 80% a joke: We implement Koe_9 and sgp_coinbase_only rings, *but* require each and every one to include N coinbases and M pre-ringCT transactions, for fixed consensus parameters N and M 18:35:21 sgp_: the distribution tail falls fast 18:35:37 sarang: indeed, but it's near-zero better, not near-zero worse I think 18:36:18 Yes, but does provide slightly more information (amount) 18:36:22 https://usercontent.irccloud-cdn.com/file/R26YQwiJ/image.png 18:36:53 ^ which is hilarious, because all of these would hypothetically unlock at HEIGHT 2 and HEIGHT 12 back in 2014, IIRC what mooo said 18:37:21 Due to the non-standard handling of that field, you mean? 18:37:28 Isthmus: hmm, I would need to see a lot more info on how many people actually spend pre-rct (suspected) compared to coinbase. My intuition leans no 18:37:28 (which should be standardized anyway) 18:37:32 So include a single pre ring CT fake if the real output is not pre ring ct 18:38:57 @sarang: Yes, currently, 3 things are being put in the unlock field: 18:39:28 https://www.irccloud.com/pastebin/0Y87gTTq/ 18:39:35 Argh sorry 18:39:36 Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks" 18:39:39 Large integers like "1980000", presumably to be interpreted as block heights 18:39:41 Very large integers like "1578561720", presumably to be interpreted as unix timestamps 18:39:51 yup 18:40:31 I am working on a first version implementation of xmr-btc atomic swap in Rust 18:40:35 more info here: https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/whitepaper/xmr-btc.pdf 18:40:45 atoc: did you identify a suitable zkp? 18:41:45 Aside from things like the handling of non-compliant participants etc., the zkp of hash/log preimage was not specified 18:41:58 the paper proposes two transactions for each token 18:42:04 yep 18:43:12 is there is a zkp not specified I will look at it. So far I have just gotten some initial stuff implemented 18:43:20 however I have not gotten to the swap part yet 18:43:31 for the implementation, I have read through the paper and it seems sounds 18:43:35 sound* 18:44:11 Yeah, you'll notice there's a requirement for a particular proof that a hash preimage and discrete log preimage are equal in equal knowledge 18:44:46 Something trustless like Bulletproofs could be used for this, with a suitable circuit 18:44:54 I see 18:45:19 The BP paper had data on such a circuit, but I was specifically told it was for testing only and was not yet suitable for any kind of deployment 18:45:38 I will take a look at that 18:46:18 We will need it. Perhaps we can see if that circuit works okay, and if not hopefully we can look at ways to improve. 18:46:36 koe: thanks for that roadmap writeup; it's nice to see many suggestions put together in one place 18:46:59 It might be useful to open research-lab issues for those that require ongoing discussion 18:47:11 I still advocate for those two mining pool-related proposals btw :) 18:47:13 sarang I send you a link to my repo once I push some changes 18:47:15 even though most discussion happens on IRC 18:47:19 I will send* 18:47:24 Thanks atoc 18:47:36 You can take a look and I would like to get your feedback on it 18:47:40 Happy to help 18:47:45 Thanks for taking a look at that 18:47:52 (y) 18:48:31 sure I can put on research github; was just wondering if koe_11 should go on main repo's issues 18:48:38 Np, it seems interesting. This week I was just l familiarizing myself with different atomic swap techniques i.e off-chain and on-chain 18:48:57 And looking at the dalek library in Rust 18:49:29 koe: I'd say anything that requires ongoing unsolved research is definitely suitable for research-lab 18:49:57 But I don't dictate the scope of issues! 18:50:06 OK, we have about 10 minutes left (there's another meeting taking place at 19:00 UTC for the Konferenco) 18:50:18 ok can put them up there 18:50:19 Any research topics that have not yet been brought up, and should be? 18:50:26 sarang btw have you considered publishing your list? 18:50:50 Of topics I am personally working on? Not really, it's more to help organize my own work 18:50:51 The private list that you had of research topics that need attention. 18:51:07 I should open issues for them as well 18:51:24 TBH github issues for research are not used as well as they could be 18:51:32 Yeah I think it would be could to have a public list to look through as important topics for Monero that need attention 18:51:35 Since so much of the discussion happens on IRC in real time 18:51:41 yes indeed 18:51:52 But at least those issues could be used as a central posting location 18:51:59 I currently go back to the logs, but that list was helpful. 18:52:01 I don't want people to have to scour IRC logs 18:52:09 Sure, I'll make some issues 18:52:17 We should clear out old issues as well, or request updates 18:52:29 peanut gallery here. Now that suraeNoether 's matching project is complete (?) or nearly so, what is the plan to use it going forward ? 18:52:30 'scouring IRC logs' - story of my life :') 18:52:41 nioc: good question for suraeNoether! 18:53:04 He has also been working on LRS security models lately 18:53:11 (which are a blocker for CLSAG review) 18:53:39 OK, let's move to ACTION ITEMS for the time being (discussion can of course continue after we formally adjourn) 18:54:19 I am writing up some material on transaction proofs/assertions, and writing up new code for a proposed InProofV2 and OutProofV2 18:54:56 As well as security model updates, some work on proof rewinding for data storage, and some odds and ends 18:55:01 Anyone else? 18:55:15 my action item: mkW my private .git repo (of atomic swap implemntation) public on Githuv 18:55:21 neat 18:55:28 Github* 18:55:30 my action items: multisig and escrowed-marketplace protocol writeup, possibly start bulletproof study if time permits 18:55:47 BPs for the ZtM writeup? 18:55:48 I want to make a website where you can type in a stealth address (or list of them) and see what future transactions have used them as ring members 18:55:59 But need a little bit more backend work before that is ready 18:56:01 at the very least studying it 18:56:24 I think the concerning part will be seeing the outputs that have been used in no subsequent rings, and thus have a known spend state and no plausible deniable for spendedness 18:56:26 Let me know if you have any particular questions that I may be able to answer 18:56:33 of course :) 18:56:59 Any other action items, or final comments before we adjourn? 18:57:01 (from anyone) 18:57:06 actually spoiled my writeup from several months ago in the latest ztm2 draft whoops 18:57:55 It's great to see so much research lately into so many different areas of interest from so many people :D 18:58:06 Gets tough to keep up with everything 18:58:14 Which is a great problem to have, in some sense 18:58:25 Anyway, thanks to everyone for attending; we are now adjourned! 18:58:32 Logs will appear shortly on the github agenda issue 18:58:38 Success problems :) 18:58:46 @sarang yea, can't beat the Monero community :- ) 18:58:47 Feel free to continue discussion 18:58:58 Grassroots cypherpunk xD 18:59:21 mebbe more bitcoin researchers will find their way here, since their ideas will actually have a chance of being implemented :P 18:59:44 * Isthmus chuckles 19:02:15 you mean like confidential transactions 19:02:57 wasn't that originally a bitcoin-focused researcher's paper? 19:03:01 Maxwell 19:04:29 Yep 19:05:01 * sarang will be afk for a bit 19:12:56 mebbe more bitcoin researchers will find their way here, since their ideas will actually have a chance of being implemented :P >>>> only if those rolling hardforks keep going! 19:16:08 Eventually less often, from what I understand... 19:16:18 To reduce the workload on the ecosystem 19:16:58 once next gen of transaction protocol is live there will likely be diminishing returns on hardforks 19:17:46 koe I was actually reading Maxwell's paper the other day: https://people.xiph.org/~greg/confidential_values.txt 19:18:06 yeah his paper helped me a lot for chapter on commitments 19:18:25 yes, Maxwell's CT is the most prominent example 19:18:36 but I recall stealth addresses were originally proposed for bitcoin as well 19:18:48 Has bitcoin tried implementing his CT? 19:19:00 the Bitcoin team* 19:19:02 no, Greg's own company forked it 19:19:07 Elements 19:19:23 forked bitcoin? 19:19:58 https://elementsproject.org/features/confidential-transactions/investigation 19:20:04 ah, blockstream 19:20:37 Greg is no longer with Blockstream, FWIW 19:20:40 yes, forked bitcoin 19:21:04 I see, what's his fork called? Elements? 19:21:12 yes 19:21:47 Interesting, I can't seem to find a coin associated with it 19:21:55 sarang where is Greg now? 19:22:20 BTC-specific discussion is probably for #monero-research-lounge 19:22:50 the btc community would never have accepted it with the drastic increase in txn size, old style range proofs 19:23:04 ok, will continue in -lounge 20:01:41 https://github.com/monero-project/research-lab/issues/58 20:02:32 :D 20:15:37 So for Triptych, I think you could store 64 bytes of data per spent input 20:16:22 prunable or non-prunable? 20:16:26 the cost is that anyone with access to the PRNG seed can determine the signing index (but nothing else) 20:16:37 Depends if you want to prune ring signatures :D 20:16:52 The storage is with the ring signature 20:18:13 We'd need new technology to extract a 64 byte chunk of data from it and keep it. Sounds daunting. 20:18:27 To extract data from the ring signature? 20:18:33 Not really; it's pretty straightforward 20:18:42 You can do it easily as you verify the signature 20:19:31 The cost is something like 2 hash-to-scalars and a couple of scalar-only ops 20:19:36 and then bam, you have your data 21:03:36 as per my ping above: with the exception of lmdb, monerod doesn't really have some complex "consistent" state across connections 21:03:53 and already has async requests, although some of the requests are synchronous 21:04:06 and remote node must respond in same order as received 21:05:59 there is potential improvements for cleaning up some blocking code on I/O threads to improve throughput, but I dunno enough about BTC network code to know how it compares to monerod 21:07:15 reads as more marketing madness or an engineer exagerating the problems with the existing code 21:07:49 They were already doing a Rust implementation of the Zcash protocol 21:07:58 (zebra) 21:10:04 monerod can process messages from multiple connections, but there may be some blocking in certain areas 21:10:54 as an example, theres some locks on DB read calls that should be removable if LMDB did its thing. but everything was written with berkleydb initially, so you'd have to re-design some things 21:12:12 there isn't enough information in that post for me to know whether they've properly identified problem/solutions to what bitcoin is doing 21:12:19 but they are certainly going to take another whack at it 21:46:38 hey Isthmus would you happen to have on hand an example tx that was apparently sent to a subaddress? trying to verify number of pub keys.. 21:47:02 We're still building the parser for that 21:47:13 And by "we" I mean n3ptune who does all the hard work 21:47:21 ah ok :p 21:50:51 stagenet incoming! 21:55:45 oh my, it created 5 total tx pub keys, and I only have 4 outputs! 21:56:34 sarang janus won't even change current number of pub keys rip! 22:03:47 ah Isthmus, it might be nice to know if any implementations are NOT creating the extra tx pub key (e.g. num_outs == num_pubkeys) 22:05:06 lolwut 22:06:27 https://community.xmr.to/explorer/stagenet/tx/a963388a0c3c8ad6bfb065733d8bc6c4fde8c5ad289d8f25cca808532185039b/1 check transaction details, tx_extra has normal tx pub key (tag = 0x01), and 4 additional pub keys (tag = 0x04 followed by amount of keys = 4) 22:07:23 function is construct_tx_with_tx_key() 22:07:43 only the additional pub keys are actually used by outputs 22:10:11 which makes sense, it's more like a small bug; janus base key should go in additional pub keys as well, to save the 1 byte single-pub-key tag 22:10:34 If extra pubkeys are in, the tx pub key is redundant. 22:10:42 It could be omitted, I dare not touch what's not broke though. 22:12:55 well it's 32 bytes per tx with a subaddress in it (assuming >2 non-change outputs) 22:13:06 >1* 22:17:27 sarang I am looking back at the ZKP in section 4.1 of the paper 22:17:48 remind me again why you feel this does not work 22:18:17 probably ok to leave it alone until sarang is ready for discussion on janus, then fix it in code passthrough if janus gets implemented 22:23:26 Oh I see the hashlock requirement now. 22:25:54 btw suraeNoether I have consumed with this xmr-btc atomic swap implementation project. 22:26:18 however I am still willing to run some tests and contribute to the bipartite matching project 22:26:32 if you still need it 22:36:42 atoc: you mean the zkp for preimage equality 22:36:43 ? 22:36:52 They assume you have access to one 22:37:16 koe: I am in favor of the Janus mitigation 22:37:27 especially given that CLSAG implies size savings already 22:38:43 were you doing a writeup about it? 22:39:12 Yes 22:39:24 Along with super-simple code to demo it, for clarity 22:40:15 I would not say there was broad consensus for making it mandatory when it was initially brought up 22:40:41 But if it would only displace existing unnecessary transaction elements, why not 22:41:43 yes sarang 22:42:08 Yeah, they don't actually present an implementation of that zkp 22:42:15 They presuppose it exists 22:42:25 Yeah I noticed that; however, at least Monero will not require timelocks. 22:42:32 iirc not much discussion was had when initially brought up, but the chat scrollback has become quite much since I showed up so who knows 22:42:39 You mean hash timelocks? No, it will not provide those 22:43:05 koe: I think it should be brought up again 22:43:08 in a dev meeting 22:43:19 Well there is a hashlock and a timelock 22:43:29 yes 22:43:30 The protocol won't require timelock 22:43:53 however with hashlocks revealing some data like pre-image 22:43:55 * sarang is still very proud of the Janus naming... 22:43:59 theat may be required 22:44:05 that* 22:44:15 Monero does not support native preimage locks that aren't part of signatures 22:44:53 I see, so does the protocol need to be modified? 22:45:15 Or can we use pre-image locks that are part of signatures (if they exist)? 22:46:37 IIRC that proposal didn't require any kind of non-supported lock 22:46:52 I will need to review tomorrow if you want an answer 22:47:30 Yes you maybe correct. 22:47:47 The DL preimage effectively takes care of that 22:47:54 hence the need for the preimage zkp 22:48:00 I am just trying to confirm as it seemed it may need hashlock, but there is a section that says it does not need timelock or hashlock 22:48:12 In 3.1 22:48:24 Can you link plz? 22:48:30 I hate scrollback 22:48:38 Yes sorry one sec 22:48:42 ty 22:48:44 I have the paper downloaded 22:48:51 but I will get the link 22:50:09 got it, no worries 22:50:15 https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/whitepaper/xmr-btc.pdf 22:50:37 aren't dev meetings getting deprecated? iirc the last one had low turnout 22:50:38 sorry for delay, but yes in section 3.1 - primitives for Monero 22:51:03 koe: ? 22:51:20 Their frequency tends to increase near releases 22:51:30 Unless something has changed that I am not aware of 22:51:44 What primitive are you questioning atoc? 22:51:44 can make some repo issues for discussion once your writeup is ready 22:51:45 It still mentions that "we need to provide proofs of the correct initialization of the protocol" 22:52:09 Where? 22:52:27 section 3.1 22:52:29 IIRC all the proofs required were off-chain 22:52:42 Ah, those are off-chain 22:52:48 between the two participants of the swap 22:53:03 It assumes a secure channel between them 22:53:06 which is reasonable 22:53:33 I see - also you brought up concerns about the zkp during the research meeting 22:53:40 so I thought I would clarify with you on that 22:54:29 Well, the paper _assumes_ a preimage zkp 22:54:34 it does not define one 22:54:42 You have to supply your own :) 22:54:52 Ah okay 22:54:54 I have seen reference to exactly one such zkp 22:55:04 but it was not deployment-ready, as I was tol 22:55:07 *told 22:55:16 Was it in BP paper? 22:55:19 I remember you mentioned that 22:55:20 yes 22:55:36 Do you have the preprint handy? 22:55:39 Okay cool it's all confirmed then - I will need to go back and read it 22:55:44 Not atm, but it is on my todo list 22:55:48 as per our meeting 22:56:23 BP preprint: https://eprint.iacr.org/2017/1066.pdf 22:56:30 see e.g. Table 3 22:56:37 page 33 22:56:38 Great 22:57:16 long paper lol 22:57:24 Yes, but very well-written 22:58:18 Nice - thanks for the link. I will read this a little later 23:00:14 righto 23:38:00 btw if anyone intended to use ztm2 draft this week, I updated the one from earlier today with a few things I originally wanted done for the meeting (probably hard to notice, but anyway). Here is this week's official draft https://www.pdf-archive.com/2020/01/30/zerotomoneromaster-v1-0-22/zerotomoneromaster-v1-0-22.pdf 23:39:31 ah forgot line numbers sry sarang, maybe next week :p 23:41:03 Hehe, no worries =p 23:42:01 Aha, JoinMo is included! 23:42:08 I see you changed the name from MoJoin... 23:42:11 hehe 23:42:20 8) 23:42:37 I don't actually care about the naming, in case that wasn't clear 23:42:57 i cried myself to sleep sarang, tears of pain 23:43:05 lol 23:43:15 it may be an enduring trauma 23:43:25 I think the many-to-many communication is awful, but we do what we can 23:43:52 Maybe go with "Joinero" 23:45:06 I think it can be hosted by a service, post things to the message board and then each person accesses it; actual p2p would be a nightmare I think 23:46:13 big problem is participant discovery.. if not hosted then idk how it can work 23:46:21 KoeJoin 23:46:24 (tm) 23:46:30 im sold 23:46:36 Better claim that domain name, and fast 23:46:59 .in is a TLD... 23:47:02 koejo.in 23:48:28 aw snap, sara.ng is taken :( 23:48:34 damnn 23:49:36 FWIW: mone.ro used to be https://web.archive.org/web/20170428215936/http://mone.ro/ 23:49:39 I have many questions 23:50:12 (this is -lounge territory, I know...)