08:08:08 [Global Notice] Hello, freenode will be undergoing maintenance 3 hours from now. Please disconnect from this network, connect to irc.quakenet.org, and join #Quakenet for updates, otherwise, you may be k-lined permanently from freenode. Thank you. -freenode staff 08:08:09 [Global Notice] Hello, freenode will be undergoing maintenance 3 hours from now. Please disconnect from this network, connect to irc.quakenet.org, and join #Quakenet for updates, otherwise, you may be k-lined permanently from freenode. Thank you. -freenode staff 08:08:10 [Global Notice] Hello, freenode will be undergoing maintenance 3 hours from now. Please disconnect from this network, connect to irc.quakenet.org, and join #Quakenet for updates, otherwise, you may be k-lined permanently from freenode. Thank you. -freenode staff 11:17:25 orly 11:36:59 Dump all your monero and buy zcash NOW - or we will ban you from the XMR network permanently. Thank you. -xmr staff 16:29:02 How goes it with people today? 16:29:34 I'm still working on preprint preparation for Triptych-2, getting all the necessary background material in place and tidied up for posting to the IACR archive 16:29:59 hi, starting final edits for proofreader draft 16:30:13 That's great news! 16:32:02 yeah im debating making a reddit post to ask for proofreaders, but it might be too aggressive. Not sure how many people (if any) will actually proofread 16:32:15 aside from me lmao 16:34:34 Heh 16:34:39 I will be glad to proofread if that's helpful to you 16:34:50 And I will get you the bulletproofs stuff you wanted, promise 16:35:15 :) 16:35:20 I'm just on a roll today with the boring parts of the Triptych-2 preprint (introductory material, background, definitions, etc.) 16:35:47 but I figure that putting it on IACR is a good way to encourage more eyes on it 16:36:02 especially given the new hardness assumption that it appears to require 16:36:12 (which may reduce to something better; unknown) 16:36:50 ah did you solve that problem you mentioned earlier? 16:37:02 or was that tryptich-3 16:37:07 triptych 16:37:38 The soundness question? 16:37:51 It's sound up to a particular non-standard hardness assumption that's related to DL 16:38:09 I think the assumption is reasonable, but untested 16:38:10 Reddit would be best for people proofreading syntax, spelling, etc 16:38:26 Triptych-3 is the name I gave to the version that supports timelocks 16:38:41 * sarang is not good at naming things 16:38:59 Tritriptych 16:39:23 The general form of a triptych is called a polyptic, but that sounds awful 16:39:55 Any ideas for the version I'm writing now, that supports single proofs and balance assertions for multiple inputs at the same time? 16:40:02 Right now my draft uses "Triptych-2", but that's hella dull 16:41:05 In my code it's called triptych-multi, but that's also dull and not very informative 16:41:14 triptych basic? 16:42:04 I use the variable `w` as an index across spends... Triptych-w sounds kinda cool 16:42:12 "The w stands for WOW" 16:43:24 this crypto_ops_builder folder always confuses me; is ref10CommentedCombined what's used throughout the code base? 16:43:38 lmao triptych-wow 16:44:13 The crypto-ops and crypto libraries are the ones referenced for rct ops 16:44:20 (with wrappers in ringct) 16:45:53 right but there is also ref10 with the same stuff in it 19:37:19 sarang: unblocking clsag. please check again the reremain.tex document. like every schnorr-based signature in the world, we are back to k-OMDL, rather than usual DL. The variant of the k-OMDL game I present in the paper with all non-zero coefficients is provably equivalent to the usual k-OMDL game, so it's not particularly exotic. I think this is the draft i want to submit, excepting 1) bibliographies 19:37:20 need to be merged with previous version, 2) your agreement that the proofs and defs seem to be correct, 3) any other copy-edits you want, and 4) we need a discussion section interpreting unforgeable + acst linkable + pigeonhole linkable + linkably anonymous all at once, to show that by relaxing our forgery definition slightly we haven't lost any power over Bender's definitions (assuming the other 19:37:20 security definitions hold) 19:37:28 brb to tackle the next thing i'm blocking 19:37:37 i hate blocking stuff, i love unblocking it 19:39:52 roger 22:23:12 hey knaccc do you know why hash-to-point for the ringCT second generator is different from hash-to-point for key images? 22:24:15 the second generator H = ge_frombytes_vartime(cn_fast_hash(G)), while key images are KI = ge_fromfe_frombytes_vartime(cn_fast_hash(K)) 22:24:45 (with a mul8 in there) 23:14:59 When nodes receive a txn is there any validation of output index range before it is put in the mempool? 23:16:24 Or could I make a bogus ring signature that references output 99999999 when there are currently 15258733 outputs and temporarily clutter up the mempool? 23:16:42 I assume it would get dropped after a bit? 23:16:47 Yes and no, respectively. 23:16:59 That was typed before your third question. 23:17:28 aren't tx validated before being added to mempool? so ring sigs have to verify to qualify 23:17:49 Cool, thanks :- ) 23:55:32 UkoeHB_ only 50% of random 256-bit sequences can be successfully interpreted as an EC point, and so they got lucky when they came up with a NUMS value for H by just interpreting a hash of G as an EC point. Hp for key images (i.e. key image = xHp(P)) can't afford to come up with invalid EC points 50% of the time, so the Hp() function there needed to work for any hash produced 23:56:26 right, but Hp has been around from the beginning; was there some reason it wasn't used to produce H? 23:56:51 good point 23:56:59 i'll think about it 23:57:42 I assumed it had simply been an oversight during the RingCT design, but I don't know for sure