00:03:42 hmm might not need to migrate; just thinking about best way to do robust key aggregation; need to think more about this 00:11:57 ok no need to migrate, just change the way private keys are created for future wallets 15:29:11 Earlier suraeNoether asked me to work up how hidden timelocks would work with something like Triptych 15:29:36 Yeah, brag about this bro 15:29:40 With the single-input version, extending from 2-Triptych to 3-Triptych (as a 3-LRS) would add a single proof element regardless of ring size 15:29:49 This is good 15:29:59 It would add (for ring size `n`), an additional `n+1` elements the final verifier multiexp 15:30:16 This is better scaling than CLSAG, since multiexp scales as `O(n/lg(n))` or so 15:30:21 It's as cheap as timelocks could reasonably get in a discrete log setting afaict 15:30:40 The other computational complexity arises from having to do commitment offsets before passing timelock data into CLSAG/Triptych 15:30:42 that can't be avoided 15:30:58 It could be worked into the multiexp, I suppose, by adjusting how the F-S challenges are handled 15:31:02 and that would still be safe 15:31:39 This is similar to how amount commitments are offset by the verifier prior to MLSAG 15:31:50 You construct your new commitment list, and one of them is to zero 15:32:08 Do you think that the triptych paper should include the triple triptych case with encrypted time locks as a detailed example? 15:32:08 that construction requires `n` 2-multiexp operations 15:32:24 Well, it can be generalized to any dimension, like CLSAG 15:32:36 I hadn't done so specifically in the paper since we had a particular use in mind 15:32:41 Can we have a long paragraph alliterating with "triptych" and "triple"? 15:32:49 Triplych? 15:33:10 Silly rabbit, triplych's for privacy 15:33:21 Interestingly, the proofs for $d$-Triptych are almost identical; almost nothing changes 15:33:35 We can embark on the Oregon triplych 15:33:47 It's like how in CLSAG you deal with a single aggregated key 15:33:50 !!!!!!!!!!!!!!!!!!!!!! 15:34:00 ? 15:34:04 this is exciting 15:34:16 In monero point compression is based on the even/odd distinction for y coordinate. This (https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) says verification would be faster if "Implicitly choosing the Y coordinate that is a quadratic residue". Is it worth looking into? I think monero uses this ge_frombytes_negate_vartime() to 15:34:17 decompress points. 15:34:21 It'll be like that movie road triplych with that idiot Tom green from 90s mtv 15:34:58 Iirc computing quadratic residues is lickety split 15:35:07 But I probably don't recall it corrctly 15:40:24 Oh duh it is easy: quad res of x in Z_p is x^((p-1)/2) 15:40:54 Mod p 15:41:00 Which is always +/- 1 15:41:18 1 indicates x has some y such that x = y^2 mod p 15:41:24 -1 indicates not 15:41:58 koe ^ 15:42:11 I see 15:42:15 :p 15:43:00 Does that mean it's worth looking into (using) 15:43:09 Hey sarang we could take a triplych beyond the stars 15:43:13 Ok I'm going to stop 15:44:05 Uh sarang: what do you think? I know field ops are super fast, computing the quad residue should be quick. I'm not sure what sort of gains we would see, though 15:45:18 General field exponentiation is not fast 15:47:06 Oh. Then it's not worth it 15:47:53 After all we are talking about a parity, just a single but. 15:48:04 A single but what? 15:48:06 :D 15:48:21 Bit + autocorrect = butt 15:48:33 It's probably worth it to update Triptych to reflect the general-dimension case 15:48:51 show that it's effectively a `d`-LRS (but with slightly different definitions) 16:15:21 From the Bitcoin doc "Note that in general, taking a uniformly random 256-bit integer modulo the curve order will produce an unacceptably biased result. However, for the secp256k1 curve, the order is sufficiently close to 2256 that this bias is not observable (1 - n / 2^256 is around 1.27 * 2^-128)." I recall bringing this up some time ago. If the 16:15:22 rand is 2^256 then in monero 1-l/2^256 is 0.9375. IIRC Monero uses 64 byte rand, so 2^512, which would make 1-l/2^512 = 1 - 5.4e-79 (presumably acceptable). Does this story seem accurate? 16:17:50 Current code loops if the random number is >= l IIRC. 16:17:58 Yeah, this was brought up before 16:18:29 ok 16:19:29 For good reason, though 16:19:38 Avoiding randomness bias to the extent possible is important 16:36:21 should monero be using a key tag to prefix the MLSAG hash? or maybe the one-time address hash? since they both use cn_fast_hash without tag AFAIK 16:37:01 You mean for hash function domain separation? 16:37:18 It can't hurt, cryptographically speaking 16:37:29 MLSAG on its own does not need it 16:38:02 but there's risk in big implementation changes too 16:38:13 right, wondering since the bitcoin guys are using it with their schnorr standard, and suraeNoether recommends it for multisig 16:39:04 Are they just prepending some fixed flag? 16:39:14 yeah 16:39:49 Mlsag hasn't had a correct formal security definition; a new random prefix tag certainly won't hurt things and is really cheap to put in, but the security implications aren't as clear as for clsag 16:40:02 How so? 16:40:28 You don't need index-based separation for each round hash 16:40:41 But using a single separator for the round hash function cannot hurt 16:40:52 It isn't needed for the protocol in isolation 16:41:14 The benefit would be that the same function is used elsewhere 16:41:45 Fortunately for CLSAG it's an easy change, and since it isn't deployed there's no additional risks to that marginal change 16:44:01 That's not my point: what I am saying is that with, say, thring sigs, we have security proofs that use assumptions about the hash functions. These proofs only go through if those assumptions are true, like prefixing. But for mlsag, we don't presently have any security proof that is correct iirc, so we can't say "without prefixes, security proofs start to fail." 16:46:37 we use hash tags in other contexts as well, notably encoded amounts and masks for amount commitments; for CLSAG the tag can be "clsag" 16:46:59 Do tag do you mean salt ? 16:47:04 yeah 16:49:11 if clsag doesn't go in the next hard fork, adding salt to MLSAG might be worth considering; since it is useful for many security proofs, it's harmless to assume it would be useful for a hypothetical mlsag security proof 16:52:45 moneromooo: so a particular hash function could be h_1(x) := hash_to_scalar("1" | x) etc. 16:53:11 and then h_1 would be used for all the MLSAG round hashes 16:56:23 there are two kinds of precedents in monero use: encrypted payments do a ENCRYPTED PAYMENT ID TAIL = 141 which goes on end of hash h = H(x | 141), and current amount/mask encoding use "amount" and "commitment_mask" at the beginning e.g. h = H("amount", x) 16:57:29 Yeah, it's not particularly standardized 16:57:36 It could be nice to have a global table of prefix flags 16:57:44 then it's clear which is being used, and how 16:58:21 and then you can ensure there's no accidental duplication, if a standard becomes that different hash applications must use a flag from the table 16:59:47 there's also chacha key tail 140, something related to wallet encoding 17:05:39 ah right, block IDs and transaction IDs also use cn_fast_hash() without prefix 17:08:26 Those applications should be fine, TBH 17:09:55 yeah; block IDs depend on miner tx which includes unique height, and non-miner transaction IDs include key images for spent coins, which must be unique within the blockchain 17:12:21 anyway, it's on my roadmap list for future discussion 17:13:05 It's a good discussion to have 17:13:12 Downside is that adding complexity carries risk too 17:13:32 which has to be balanced against the risk of, say, unintended collisions between protocols 18:08:03 sarang, i have a dumb question about clsag 18:08:15 right now we use these dummy key images for all the amounts 18:08:27 but linkability only depends on the one key image 18:08:57 yep 18:09:08 The aux linking tags are only there for the algebra 18:11:11 wait, your offhand response answered my question. nvm 19:05:14 Hey, anybody know what's up with EXMR? 19:05:15 https://exmrfoundation.org/summary.pdf 19:06:06 what an illustrious team of advisors. how do I invest? 19:11:30 Never heard of it 19:34:04 wait where's the engineer ?? 19:34:47 ceo 4 advisor 4 manager secretary and assistant; its a bureaucracy! 19:51:21 Triptych paper is now generalized to a full `d`-LRS-type construction: https://eprint.iacr.org/2020/018 19:51:56 sounds like my wheel house to do a report on them. Also, is altruistic mining still a thing? 20:09:18 Altruistic mining is not known to be a thing, although there may be some edge cases from suboptimal implementations (analysis not performed) 20:53:17 Correct, there have been thousands and thousands of significantly altruistic blocks over the last few years, but none recently. 20:53:45 Although, to be fair, with all that proves and low transaction volume I don’t even know if they have been opportunities to construct altruistic blocks 20:54:02 *with bulletproof and low transaction volume 20:54:28 Only possible if mempool > penalty free size 21:02:04 Psh, thanks bulletproofs... 21:05:16 there's a mini project for atoc: optimal algorithm for choosing tx to go in a block, given any combination of tx weights, max block weight, and long term median 21:06:08 and fees of course 21:06:13 I guess this would be an NP-complete problem 21:06:23 Knapsack problem. 21:06:34 yes, with additional constraints 21:06:36 Well, not quite. But pretty close. 21:10:38 of course lol, people have been thinking about it for 100+ years '=D 21:59:35 sarang I've been reading the Bitcoin-Monero Atomic Swap paper and looking at the dalek libraries and familiarizing myself with Rust. 22:00:11 I am hoping to have a decent amount to discuss by our next research meeting 22:00:21 Word 22:00:33 Looking forward to it 22:00:49 (y) 22:01:13 Yes there's some interesting stuff here. I was thinking I would go back and update my CCS a little later today 22:01:46 I'll probably just update it to this project, if that's cool with you? 22:07:13 I saw this, haven't looked into it, might be relevant https://github.com/ElementsProject/scriptless-scripts/blob/master/md/partially-blind-swap.md 22:08:32 rbrunner has been doing god's work with pursuing multisig usefulness, notably MMS and investigating OpenBazaar, im tearing up 22:09:56 interesting 22:10:36 atoc: you're free to do a CCS, but I have seen previous examples where there was doubt about a proposal since the person had no history with the project 22:11:14 Donors may wish to see both value to the community and some assurance that the proposer will complete the proposal 22:11:26 This is my observation, at least 22:12:07 I can't personally speak to your expertise or experience for any CCS, of course 22:12:45 hmm I see, yes this is why I was thinking I would do part-time for a month just to build up some credibility with the community 22:13:03 I am not asking you to endorse the CCS or even support it 22:13:27 just making sure I am following guidelines properly - to me it's worth a short just to see how it is received by the community 22:14:32 That being said, I'm glad you are interested in research! 22:15:04 also if you advise a better approach, i am happy to hear it. I'm not really exactly sure the best path that others have used to get funded 22:16:24 people usually want to see contributions to monero before being funded thru the CCS 22:16:30 my experience is: wrote ZtM1, asked for CCS for ZtM2 and it's been funded for over a year; it helps to coincide CCS with actual brain availability :p 22:17:15 and of course, my advice is make a good estimate of how much funding you need 22:17:48 *before they will fund a CCS proposal