00:10:38 For linkable ring signatures, is there a reason key images are k*Hp(K) instead of k*H where H is another basepoint? Just that it means solving the discrete logarithm once wouldn't break all ring sigs? Or is there an inherent flaw in using the same basepoint for all keys in a ring? 00:11:27 sarang suraeNoether ^ 00:11:27 I believe using a constant basepoint would be faster since you can precompute it to some degree, and hash to point functions are a pain from what I've seen. 00:12:45 Using a common basepoint can be used to link signatures due to linearity 00:12:59 It's described in the CryptoNote whitepaper on page 18 00:14:07 Some newer constructions use a common basepoint but invert the scalar instead (and account for this in the signature/proving systems) 00:14:18 Thanks! 00:15:13 Interestingly, this same issue arose in the construction of the dual-key DLSAG construction 00:43:45 are bulletproofs verified faster than borromeans? 00:48:32 Extremely 00:49:41 An entire batch of bulletproofs can be verified in a single multiscalar multiplication operation, which scales well 00:49:55 (and it's only a marginal added cost per proof in the batch) 00:51:26 ah nice 00:55:57 There are benchmark tests 00:56:07 I don't have the numbers handy anymore comparing them, but it's substantial 00:57:01 Aha, found some old numbers 00:57:38 To verify a batch of 128 separate 2-output borromean proofs would take 12186 ms (on one test machine). The same operation with bulletproofs would take ms 00:59:24 ^ koe 00:59:59 The current numbers _may_ be faster... we applied some further speedups, and I don't remember if the numbers I just gave account for this 01:00:44 Whoops, the earlier line should have said that with bulletproofs would take 420 ms; sorry about that 01:00:55 That's only 3% of the old time 01:01:13 I did not remember that was such a speedup for the common case :o 01:01:59 I should re-run those numbers and confirm those are current 01:02:08 but at any rate, batching yields substantial improvements 01:02:51 damn! 01:05:02 Praise be to Buentz/Bootle et al ^_^ And MRL. 01:05:56 I discovered Monero is down to around 10x bitcoin transaction sizes, one order of magnitude reduction from before bulletproofs 01:06:52 Heh, we didn't invent bulletproofs, they did 01:06:52 Heh, we didn't invent bulletproofs, they did 01:07:00 AFAIK my only contribution was reporting some errors in the algebra (didn't affect the correctness, just the presentation) 01:08:24 You wrote the code from the paper. 01:08:54 that's a feat in itself 01:08:54 And if not for that, you deserve praise anyway :D 01:25:56 hey sarang what happened with your technical note "Application of Bulletproofs in Monero Transactions", I have a copy dated March 5, 2018 01:29:32 The updated bulletproofs paper covered it 01:31:50 is this the updated version? https://eprint.iacr.org/2017/1066.pdf 03:14:58 the size difference is less than 10x, ignoring difference in functionality 03:15:09 1 in 2 out bitcoin is >200 bytes, 1 in 2 out monero is 1.7 kb 03:16:19 2 in 2 out btc is 250, 2-2 xmr is 2.3kb, so still <10x 03:16:48 actually 2.5kb so right around 10x 03:22:05 If my dream of compressing MLSAG scalars comes true it will be reduced an additional 670 bytes per input 03:22:25 640 03:25:32 That's a LOT for inputs... 03:26:01 Su much that it might even go negative. Typo ? 03:27:20 I have a dream that one day this protocol will scale into the heavens 03:27:58 MLSAGs take up a lot of space, 32bytes*ringsize for just the scalars 03:28:30 Well, I'll not bother you again then, give you all the time you need to cook that up ^_^ 03:28:46 32*2*ringsize actually 03:31:36 koe: I do not think your method is possible 03:31:44 But prove me wrong :D 03:54:42 Does anyone think the general donation fund's custodians would be willing to pledge a bounty to anyone who provided a solution? Probably no bounty for proving it has no solution though. 04:37:08 Ill offer 5 XMR. Any recommendations on formalization? Draft 3 https://justpaste.it/3i70b 19:14:30 I was thinking more about the problem you brought up, koe 19:14:38 Ah rats, koe is away 19:15:19 I think that a solution to the problem would imply that the underlying PRNG is insecure, since you'd effectively be finding a preimage 19:15:38 and that in turn would break the security of the signature construction 19:15:46 (but I haven't formalized or proven this!) 19:17:16 Tiny *and* works even with insecure PRNGs! 19:18:32 int prng() { return 4; } 19:18:43 there ya go 20:16:45 Is there a writeup for the possible mitigation of the Janus attack? Third schnorr sig right? 20:19:44 There's a much better approach: adding the point `R' = rG` to the transaction, and doing a particular equality check 20:19:48 quite efficiently, too 20:21:50 I'm working on a short writeup of possible consensus updates that includes the mitigation, as well as hidden timelocks and CLSAG signatures 20:47:52 sarang I also have a hard time imagining a solution, but it could be my own ignorance which is why I don't want to give up. Much more precise writeup https://justpaste.it/3ilv7 21:09:00 @sarang: +1 to all of that 21:10:55 important point with that mitigation is it doesn't work on view-only wallets 21:10:55 The short Janus mitigation costs 32 bytes per subaddress output and has a single extra equality check only for outputs you detect (so there's no extra full-chain verification required) 21:11:09 true 21:11:18 Hidden timelocks cost 32-64 bytes 21:11:27 and some extra verification 21:13:18 actually it should be 32 bytes per transaction which contains subaddresses, since you only need one transaction private key for all the subaddresses (reuse r for all subaddresses, and generate new r for non-subaddresses, so rG applies to all the subaddresses) 21:16:25 suppose 3 outputs, 2 are subaddresses; include in tx extra: r1G, r1Ks1, r1Ks2, r2G, where r2G is used by the non-subaddress 22:24:06 hey guys, i've been horribly sick for the past few days 22:24:09 i've been in a hole 22:24:17 please accept my apologies for not bringing the community up to speed 22:24:24 sarang, i have notes on CLSAG for you 22:25:51 biggest problem first: for two rings R and R*, a secret key x with public key X in both, for two messages m and m*, the definition of linkability does not imply that Link(Sign(m, R, x), Sign(m*, R*, x)) = 1 22:25:55 unless I'm misreading it 22:26:21 In particular, use R = R* = {X, Y} for any other fixed public key Y 22:26:57 then R \cup R* has 2 elements, 2 signatures have been computed, the definition provided allows Link to output 0 22:27:38 the rest of my notes are copyediting notes, which i'm going to dump into your PMs 22:29:13 hi suraeNoether, you feeling better? 22:40:35 suraeNoether: I don't see a way to set up a challenger-player game to capture precisely the case you mentioned 22:41:00 There isn't a good way to know that the player used the same private key 22:41:09 (from the challenger's perspective, I mean) 22:41:21 The Backes-style (k+1)-signing game does capture this, at least 23:05:53 koe hi not really 23:05:56 sarang: i'll think about it tonight 23:06:04 i braindumped the rest of my notes on you in PM 23:06:47 damn 23:21:06 Oh, I'mma copypasta some stuff over here from -dev for later reference (otherwise I'll lose it in backlog) and because some might find it interesting. 23:21:32 I've been looking a bit into transaction selection algorithms employed by miners 23:21:35 Let’s say the mempool contains apathetic or many transactions, such that including them results in a decrease in the *total* payout. We define two types of miners: altruistic miners mine the transaction(s) and take a hit to their bottom line (i.e. make a donation) so that transactions get processed. A rational miner will only mine subsets of the mempool that don’t decrease the total reward 23:22:21 https://usercontent.irccloud-cdn.com/file/yVK2xGYV/image.png 23:22:57 (We see lots of altruistic blocks, anything below the main trend) 23:23:32 It used to be very common, many blocks in a row would be altruistic: 23:23:33 https://usercontent.irccloud-cdn.com/file/iCVsGlLH/image.png 23:23:52 Now it is rarer, but still happens. Here is some very recent data: 23:23:53 https://usercontent.irccloud-cdn.com/file/5lk0dzFM/image.png 23:24:59 (Altruism is disabled in the current core software, so this indicates that somebody is using customized software to construct their blocks). 23:25:47 Oh, I should calculate their hashrate 23:25:49 1 sec 23:29:47 Eh, it'd be a lower bound anyways, since convoluted with mempool history 23:29:53 * Isthmus loses interest 23:31:25 are all those blocks actually larger than the penalty free zone? e.g. it's not people accepting less than the block reward for no reason 23:33:56 could probably just check if size > 300kB, no need to go all in 23:35:05 it's 20kB v1, 60kB v2, 300kB v5; where v1 April 18, 2014; v2 March, 2016; v3 September, 2016; v4 January, 2017; v5 April, 2017 23:37:58 https://usercontent.irccloud-cdn.com/file/3UJdUmBI/image.png 23:38:16 just a hair over 300 kB 23:38:40 x-axis = block height 23:38:43 y-axis = emission 23:38:48 color = size 23:39:17 interesting 23:39:20 Looks like a string of almost-full and slightly-too-full blocks in a row 23:41:29 Still don't have an easy way to look for underclaiming, without implementing a bunch of block weight tracking 23:41:34 * Isthmus makes a general note: 23:44:35 Differentiation between altruistic mining (where emission + fees + penalty = payout) with underclaiming (emission + fees + penalty != payout) 23:45:49 The reason I can't tell the difference between them yet, is because I haven't implemented the calculation for the penalty 23:45:53 So I can't tell if the sides of the equation balance 23:46:48 are you plotting emission or total payout? 23:47:03 emission 23:47:13 Calculated by `payout - SUM(fees)` 23:47:14 emission always falls when block sizes are high 23:48:39 Yea, the penalty term 23:48:44 might as well plot total payout, then visual outliers below the curve are altruistic 23:48:57 or underclaiming 23:49:07 Sure, I've got that handy too 23:49:41 https://usercontent.irccloud-cdn.com/file/M4J3dpG7/image.png 23:50:07 some people are paying a lot of fees lmao 23:50:15 Ah yea, to be more precise, miners below the curve in *THIS* plot are altruistic 23:50:35 (not the plot that I showed earlier, since that didn't take into account fees) 23:51:03 someone screwed up back around 1300000 23:51:25 otherwise 0 altruistic miner visible 23:52:05 Heh, yeah looks like blocks are constructed rationally these days 23:52:46 there still might be suboptimal blocks (transactions that aren't justified by fees when block weights above penalty free zone) 23:53:30 Here's a closeup of that whoopsie around 1300000 23:53:33 https://usercontent.irccloud-cdn.com/file/WPwPqZlM/image.png 23:54:14 Which almost looks to be independent of block size 23:54:18 But maybe I need to adjust the color scale 23:54:56 well at 1270000 the block size changed color but pattern remained 23:57:06 * Isthmus adjusts colorscale upper limit to 100000 bytes 23:57:08 https://usercontent.irccloud-cdn.com/file/xPhYUXKp/image.png 23:57:21 Sorry, I wish there was a color bar on here. 23:58:33 https://usercontent.irccloud-cdn.com/file/l54vifdF/image.png