00:38:49 sarang: new paper title is "Non-slanderability is unforgeability for linkable ring signatures." 00:38:53 *grumbles* 00:38:56 freaking equivalency 00:47:17 Ready for a read? 01:00:03 sarang: just shared it with you on overleaf; it's a frankenstein copypasta at this point, but there are probably around 12 pages of solid narrative that i thinkyoiu should read 01:00:12 that was ... a long day 01:00:15 i'm logging off for now 01:00:27 i have doctor's appointments again in the afternoon tomorrow so i'll only be on in the morning 02:32:20 There are probably all sorts of variations in spend times. Time of day, seasonal, market conditions, etc. 05:50:35 btw i'm late to the party on sarang's janus mitigation idea: just read it and it's very elegant and nice saving vs the older schnorr proof idea. fyi minor typo where you wrote b_j = H(a,j)*G + b instead of b_j = H(a,j) + b 06:46:27 ooh actually how about this 06:47:33 for a couple years, people have observed that there was a shared secret between sender and receiver (when a subaddress is involved) calculated as rG == txpubkey * d^-1 06:48:24 (where txpubkey is called R) 06:49:36 first observation: this shared secret can be preserved as a secret by instead of publishing R'==rG, publishing H(R') and checking if H(R') == H(Rd^-1) 06:50:16 second observation: save 16 bytes by publishing only the first 16 bytes of the hash, which I think should be more than enough 06:50:53 so the janus check would be lower_16_bytes(H(R')) == lower_16_bytes(H(Rd^-1)) 06:51:24 where d is b_j in your notation. 06:56:00 where where H in this case would be keccak256 and not Hs 06:58:00 so in your notation, for each txpubkey R, publish janus proof j = lower_16_bytes(keccak256(r*G)), then janus proof verification is j == lower_16_bytes(H(R*b_j^-1)) 06:59:06 maybe i shouldn't have used the symbol j for the janus proof :) 07:32:25 for a couple years, people have observed that there was a shared secret between sender and receiver (when a subaddress is involved) calculated as rG == txpubkey * d^-1 <-- not sure I understand this, subaddresses have never used d^-1 afaik 07:38:04 UkoeHB_ maybe i didn't state the point clearly. When funds are sent to a subaddress, the txpubkey rB_i is published, and since rB_i==r*b_i*G, the recipient can calculate (b_i^-1)*txpubkey to get R'==rG 07:38:39 and R' is thus a shared secret between the sender and receiver 07:38:44 ah 07:39:44 that's actually a really interesting point, a way to recover the other person's pub key from a shared secret if it's forgotten (or in this case unknown) 07:40:13 could that be useful? 07:41:10 🤔 07:42:05 it's an interesting shared secret, because it's a shared secret between the sender and the full-wallet owner, but not known to a view-only wallet holder (since b_j needs to be known, which requires knowledge of the wallet private spend key b) 07:42:56 ah i see i see it might work 07:44:44 oh doh. i just realized the implication that sarang's scheme will not allow a view-only wallet to avoid a janus attack 07:44:50 it only helps full-wallet holders 07:45:45 saving 16 bytes is nice though 07:46:14 although this method does not harmonize well with any kind of join protocol 07:46:18 well both sarang's scheme and my modification of it both fail to work for view-only wallets 07:46:29 yes, view only is not possible afaik 07:46:36 without more bytes 07:46:51 right yeah, the 48-byte half-hash schnorr proof 07:48:22 can you write it up and add a comment to the repo issue? :) 07:48:27 sure 07:49:01 did you mean the 16-byte variation, or the thing about it only working for full wallets? 07:49:12 16-byte variation 07:49:25 cool ok, i might as well write up both 07:54:49 UkoeHB_ oh i only just read your comment underneath in the github issue, looks like you reduced the overhead to 32 bytes per transaction instead of 32 bytes per txpubkey? 07:55:40 and and i see you already commented about the view-only thing 07:57:08 yes it's been through some iterations, sarang always finds a way to break my ideas but I come back strong :p 07:57:12 haha 07:58:31 in my opinion, there isn't much point addressing the janus attack if it only works for full wallets 07:59:14 because the automated "i received your tx!" reply is going to come from view-only wallets in so many instances 08:00:49 it doesn't feel right to me, to not address it 08:01:36 users who may be vulnerable will never be able to detect the attack, creating a fundamental uncertainty about the currency's robustness 08:01:39 i'm saying we should address it, but in a way that fixes it for view-only wallets too 08:04:12 UkoeHB_ i'm confused about your variant on the scheme: if r_i := r + H(R,i), and if R is published, then r_i is now public for the whole world, which is a showstopper, surely? 08:04:52 nope, since r is unknown 08:05:04 ohhh right, i see :) 08:08:27 the basic problem is any shared secret between a subaddress and a tx author must necessarily depend on the spend key, so even if you communicate the tx private key to the recipient using another shared secret, the recipient still needs his spend key to validate THAT shared secret was for the right spend key 08:08:49 anything involving the view key gives the game away 08:11:17 "the basic problem is any shared secret between a subaddress and a tx author must necessarily depend on the spend key" -> i'm not sure if you were overly narrow in that statement because of its context, or if i'm missing something 08:11:32 because of course there is the shared secret r*A_i 08:11:43 which the view-only wallet uses for scanning 08:12:04 since the tx author doesn't know the true view key, as subaddress view pub key is (true view)*(subaddy spend)*G 08:12:16 right yeah i see what you mean 08:12:50 i'm confused in the github thread too, not sure if you made a typo there when you say: checks that the equality b_i*(R + H(R,i)*G) - R_i == 0 holds 08:13:02 that implies b_i*(R + H(R,i)*G) == R_i 08:13:06 you could make the subaddress have 3 components, and somehow leverage that to preventing Janus; I havn't thought abt it 08:13:06 but it doesn't 08:13:19 i mean that equality doesn't hold 08:13:32 b_i*(R + H(R,i)*G) == b_i*R_i though, if that's what you meant 08:13:59 i think you must have meant that 08:14:01 R_i is the tx pub key for our subaddress at output index i, and R is the base pub key 08:14:38 R_i = b_i*(r + H(R,i))*G, and R = r*G 08:15:33 oh sorry yes i see 08:15:49 i'm getting algrebra blindness here 08:17:06 anyway, so the 16 byte saving would be to check lower_16(keccak256(b_i*(R + H(R,i)*G))) == lower_16(keccak256(R_i)) right? 08:17:36 and to publish lower_16(keccak256(R_i)) instead of publishing R_i 08:18:46 no need to include my indexing dealio 08:19:32 publish tx pub key R_i, and H(R'_i) where R'_i = r_i*G, and R_i = r_i*A_i 08:20:44 heh ok i think i'm falling asleep, i'd better revisit this when my brain starts working again... or feel free to fill in the comment on my behalf, if you feel like it :) 08:21:07 Ill let you explain your idea :p 08:21:38 heh ok cool, i'll comment when my brain is reset 08:23:40 :) im heading to bed soon aswell, but Ill leave an extra comment for sarang's morning; put some thought toward high ringsize decoy selection; what follows is instinctual concepts not backed by hard reasoning 08:23:49 double layer binning: generate initial set of ring members for a ring (use standard gamma distribution or whatever is base distribution, equal in size to square root of ringsize), for each of those ring members generate a wide bin (width scales with generator age, number of wide bin members is sqrt(sqrt(ringsize))), for each of those wide bin members generate a tight bin (~1 block width, number of tight bin 08:23:49 members is sqrt(sqrt(ringsize))). For 128 ring size, there are 11 wide bins with 3 tight bins each containing 3 or 4 members. 08:25:31 it also might be fun to: randomly mix up the decoys between all the rings, and make some proportion of ring members be duplicated in other rings of the same tx 08:26:22 of course, these concepts may give moneromooo nightmares :) 08:30:43 UkoeHB_ a few lines above, when you wrote "and R_i = r_i*A_i", did you mean to write R_i = R_i*B where B is from a subaddress? 08:30:59 ah yes 08:31:19 cool ok thanks 08:31:42 and yeah i meant to say r_i*B there of course 08:41:08 hmm maybe i'm just not lucid, but i'm not sure if my 16-byte saving works at all with your proposed variant, UkoeHB_ 08:43:28 i think it only helps when used with sarang's original scheme 08:43:57 Ah I think I see what you mean 08:45:03 Since all outputs need a unique tx private key in case of multiple outs to the same address 08:47:11 oh good point, i didn't think about that bit 08:48:47 i don't think it affects things when all of the ||i bits are added in 11:07:58 knaccc: the non-Schnorr Janus mitigation was UkoeHB_'s idea, not mine :) 11:08:30 sarang ah thanks for letting me know 11:08:59 I just wrote it up with some sample code etc. 15:13:08 good morning everyone 15:14:08 sarang: the overleaf doc i shared with you last night - it's still just a draft. the proofs are copied from the previous draft, etc; what i need your feedback on is the narrative on security definitions before i go fine-toothed through the proofs (most of them still hold) 15:17:47 also, i must have missed sarang's new janus mitigation idea 15:17:58 er... koe's 15:18:25 UkoeHB_ and knaccc: if r_i := r + H(R,i) is published and if R is published anyone can compute r easily with subtraction. am I missing something? nothing's secret there if all of it is revealed. 15:20:30 3rd day in a row feeling good 15:20:39 so far that's my record for 2020. :( 15:20:43 but also :D 15:47:43 suraeNoether: will review that overleaf doc 15:48:11 when i described it as a frankenstein last night, i'm not kidding 15:48:18 Finishing up a quick tx proof unit test first 15:48:18 feel free to take a machete to it 15:48:27 awesome, i'm working on fixing my last matching unit test 16:27:55 r is unknown 16:29:25 As is r_i 17:59:35 oh i thought r_i was a public piece of info; nevermind 17:59:42 * suraeNoether found a bug in matching 20:00:50 * suraeNoether was comparing predictions from a single upcoming timestep against the results from a sequential execution of more than one upcoming timestep, and is foolish 21:42:17 The one big bad bug or a lowly unrelated bug? 23:02:05 WIP... updated transaction proofs: https://github.com/SarangNoether/monero/tree/txproof 23:02:14 tests are still incomplete 23:04:25 Replaces {In,Out}ProofV1 with {In,Out}ProofV2, with better Schnorr challenges 23:04:45 and, by extension, replaces ReserveProofV1 with ReserveProofV2 23:06:25 A question: should attempts to verify V1 proofs succeed (as they do with this code), or should they produce an error? 23:07:05 Right now, it will only produce V2 proofs, but verification is backwards-compatible (needs a test for this)