09:50:01 https://electriccoin.co/blog/halo-recursive-proof-composition-without-a-trusted-setup/ 09:51:41 Halo - old news probably 13:03:24 for those of you who are writing research papers, please consider submitting to the IEEE Security & Privacy on the Blockchain Workshop. Deadline is March 5, 2020, see https://ieeesb.org 13:15:38 koe: fyi: https://paste.debian.net/hidden/5c222de0/ 13:49:43 ah, testing the coinbase limit? nice; also, that nonce is pretty high, is next release (or current release) starting from a random nonce? 13:50:41 Yes. 16:02:10 Hello all; reminder that there is a research meeting here today at 18:00 UTC (about two hours from now) 16:02:55 Agenda, with some additions from Isthmus: https://github.com/monero-project/meta/issues/430 16:19:16 btw sarang the Janus attack also works on the normal address - subaddress intersection, so checking the shared secret should also be done with outputs owned by normal addresses 16:20:28 but the extra pub key is only required for tx with at least 1 subaddress recipients; only 1 extra pub key for such transactions 16:22:18 yup 16:31:01 Given the space savings already possible with CLSAG signatures, it's minimal 16:32:12 I find it unfortunate that a tx with subaddress is distinct from without, but don't see an alternative that doesn't cost additional 32 bytes per output 16:32:56 Not to mention scope creep, since subaddresses are already two levels outside the protocol (one time addresses are one level outside the protocol) 16:34:18 Yeah, there has been discussion about forcing uniformity in that way 16:35:18 To some extent I like that addressing is outside the tx protocl 16:35:28 It helps to simplify signature/proof constructions a lot 16:35:43 for modularity purposes 16:36:59 koe: will you be available at the research meeting to give a brief update on the status of Zero to Monero updates since the first release? 16:37:10 yeah 16:38:34 Great 16:39:37 I also have a list of future developments, some new others more recently discussed 16:39:48 monero developments (e.g. clsag) 16:39:59 I was going to ask about that, in fact :) 17:25:55 Good morning everybody 17:26:33 good morrow 17:26:43 I'm available this morning, but I've been recovering from a sickness, and I've been thinking deeply about the security models for CLSAG. I've made a couple of pushes to my get hub this week also... I'm just giving everybody a brief update in case I get sick during the meeting again :-( 17:26:57 GitHub* my gawd 17:28:23 Try new GetHub! We bet you can't taste the difference 17:46:43 Sarang I am fairly sure that just our analysis of backes' linkability and unforgeability is already an important contribution to the cryptography community 17:47:55 Yeah, it's more subtle than I had previously appreciated 17:48:17 Fortunately I think that even though it's limiting, it's an improvement on the existing Liu/MLSAG proofs (which make a lot of restrictions on the adversarial players) 17:50:09 Notably that Liu/MLSAG assumed linkability and unframeability players produced correct signatures, which doesn't immediately follow from their unforgeability 17:51:01 Whereas we extend this to allow for corruption and certain oracle access, but under a different framework for unforgeability 17:51:38 Backes is interesting in that linkability doesn't involve any oracle access, simply the adversary's output to the challenger 17:51:51 but tying this back to unforgeability doesn't really work for that 17:52:17 The unforgeability game is stricter in the challenger-player interactions 17:52:37 If we can just show that satisfying the verf equations implies matching across ring indices... 17:52:44 Yeah, that would do it for sure 17:52:50 very comprehensively 17:53:03 It seems like this should be possible, given the way the forking lemma operates 17:53:47 The alternative is to restrict corruption in the unforge game, but that doesn't play nicely with reducing link/unframe back to unforge 17:54:48 I'm going to continue looking at how changes to the unforge definition would affect the types of challenger-player interactions with link/unframe 17:55:03 In particular, linkability 17:55:55 The way that proof currently works is by identifying a signature that has a mismatch between linking tag and ring 17:56:18 (via the pigenhole principle and properties of the linking tag construction) 18:00:29 OK, it's time to get started 18:00:32 "I find it unfortunate that a tx with subaddress is distinct from without, but don't see an alternative that doesn't cost additional 32 bytes per output" Heh, I suppose everybody can guess where I stand on that xD 18:00:47 Agenda: https://github.com/monero-project/meta/issues/430 18:00:54 * Isthmus puts on goggles and lab coat 18:01:00 Logs will be posted there after the meeting 18:01:03 GREETINGS 18:02:26 hi! 18:02:28 hello 18:02:39 Hi 18:03:40 hiya 18:04:04 holla 18:04:51 Let's move to ROUNDTABLE 18:05:02 Isthmus: you posted some data on the agenda; care to discuss? 18:05:15 Link to data: https://github.com/monero-project/meta/issues/430#issuecomment-576455137 18:05:28 Sure 18:05:47 First, glanced at distribution of number of outputs on miner transactions 18:05:59 https://usercontent.irccloud-cdn.com/file/OB2UWpjs/image.png 18:06:01 This is mostly a historical novelty from back in the days of denominated XMR - since RingCT became mandatory at block 1400000 all miner transactions have been 1OTXs. 18:06:12 *single-output coinbase transactions 18:06:49 So that chart is for _all_ miner txns? 18:06:54 Throughout all of time? 18:07:08 From genesis block to last week 18:07:24 Courtesy of n3ptune's magic database xD 18:07:56 Another mostly historic novelty - altruistic transaction selection by miners who would include many/large transactions in their blocks, incurring a coinbase penalty that is not offset by the added fees. (In other words, they would have had a higher total block payout by mining an empty block.) 18:08:01 https://usercontent.irccloud-cdn.com/file/0pcNROcT/image.png 18:08:15 color is size, starting at blue = small 18:08:33 This seems to not be a very common practice these days 18:09:00 Altruistic mining could be banned at the protocol level, but at the moment I'm not inclined to do so 18:09:17 more advanced altruism based on suboptimal tx inclusion will involve more intensive analysis, which I provided pseudo code for this week, if that path is chosen 18:09:25 Any comparison against partially filled blocks rather than empty blocks? 18:09:39 @koe yea do you want to jump in 18:09:47 Yeah koe please do 18:10:04 * Isthmus has to get off the bus but will be back in 5ish minutes 18:10:11 * Isthmus turns off bunsen burner and puts IRC away 18:10:45 koe: if you have a link to the pseudocode can you include it here? 18:11:20 well this week I: made pseudo code for Isthmus blockchain analysis, deep proofreads of several ZtM chapters, talked with cohcho and jtgrassie about uniformity of coinbase tx 18:12:00 more or less improved a roadmap of future monero developments: https://justpaste.it/5io6e which we can talk about some items 18:12:26 latest ztm2 draft, I have honestly been pushing off multisig edits, but not making no progress https://www.pdf-archive.com/2020/01/22/zerotomoneromaster-v1-0-20/zerotomoneromaster-v1-0-20.pdf 18:12:28 Enforcement of exact block rewards seems straightforward and a good idea 18:13:19 pseodo code https://paste.debian.net/1127152/ 18:13:39 Regarding ZtM, are there topics in progress for which you'd like particular information or assistance? 18:14:23 currently working on multisig, and have already gone through most documentation available, but there are some things that aren't clear despite documents 18:14:38 so if anyone knows about multisig, Id like to discuss with them 18:14:51 otherwise will dive into code base 18:15:22 I'm not super familiar with the code base, but I'm familiar with what it's supposed to abstractly represent 18:15:22 Thanks koe 18:15:40 So if you have questions koe about how things are supposed to work (as compared to how things are currently implemented) 18:15:42 Lmk 18:15:51 ok Ill hit you up 18:16:32 Anything else of interest to share koe? You've clearly been busy! 18:18:29 well there are all the things in the roadmap, in particular enforcing 1 output from coinbase (since Isthmus found literally all coinbase for 4 years have been single output), and possibly enforcing single-type ring membership (only coinbase ring emmbers, only rcttypebulletproof2 ring members) since 99.5% of coinbase are owned by pools who are easy 18:18:29 to fingerprint 18:19:00 Single-type enforcement was brought up a few times by sgp_ in the past as well 18:19:09 see https://minexmr.com/pools.html where 99.5% of hash is accounted for 18:19:27 My concern was that a full segregation of coinbase outputs means certain heuristics are only moved "down chain" by a single hop 18:19:43 Meaning there's likely improvement for sure, but perhaps more marginal than desired 18:20:33 koe, do you still need proofreading of ZtM or are you good on that? 18:21:02 I'm in favor of enforcing single output coonbase txns by consensus. I'm in favor of enforcing block reward. I'm tentaticely in favor of type-restricted rings. 18:21:04 always need proofreading :) even after it's published lmao, I've received some good emails that are incorporated in v2 18:21:07 I actually was going to re-introduce the topic again here to keep it on everyone's minds, so nice timing 18:21:27 related: https://medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43 18:21:35 koe, I am have some notes that I need to send you. 18:21:43 I will try to get them to you soon. 18:21:53 ill look forward to them :) (email me) 18:22:16 Enforcing single output coonbase txns would prevent p2pool. 18:22:46 will do :) 18:22:53 Atoc, I believe that my mojojo branch is no longer bugging out, although data isn't being written to file how I want. The actual tracing game script I am running will be pushed soon(tm) 18:23:01 jtgrassie is p2pool your project? 18:23:15 AFAIK nobody is doing it yet. 18:23:40 But simulator is now successfully simulating a monero economy between Alice, Eve, and Bob to model flavors of EABE 18:23:41 cool suraeNoether I have been falling a bit behind and will catch up today and get you my thoughts 18:23:50 good to know the unit tests are working fine 18:24:01 Nice 18:24:01 It's all good, I'll still be plugging away 18:24:23 Any other questions/comments for koe? 18:24:47 no specific questions, but I have a related topic for mining pools besides coinbase outputs when time allows 18:25:02 OK, first, is Isthmus back? He had to step away briefly 18:25:10 * Isthmus gets back 18:25:19 Isthmus: care to finish up your data? 18:25:26 Also, it's not "kicking the can down the road" depending on how you implement it 18:25:28 (then we can move to sgp_) 18:25:28 But yea, moving on 18:25:43 Hold on 18:25:43 Discovered that everybody seems to use the miner_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a 18:26:22 Why would coinbase-only not do this? 18:26:51 If you assume the spend patterns would be sufficiently different, I agree 18:27:06 Uhm, I could get in the weeds with this 18:27:20 On like 4 levels 18:27:21 lol 18:27:44 From an *on chain* perspective, there's two questions we can ask 18:28:20 1) Is this ring spending a coinbase 18:28:22 \me pulls up lawn chair 18:28:24 2) Which coinbase is this ring spending 18:28:30 #1 is hard to hide 18:28:34 #2 can be accomplished 18:29:01 * Isthmus clarifies: 18:29:05 making #2 unanswerable can be accomplished 18:29:10 I'm an evil exchange 18:29:21 With current system, I can fingerprint which pools my users belong to 18:29:53 Aah ha, this person makes monthly deposits that are 4-input transactions each spending from a ring with 62 B null padding, so I know that they have about 3000 H/s attached to minexmr.com 18:30:08 *each spending from a coinbase whose miner tx_extra has... 18:30:21 But with coinbase-only txns, we strip the pool-to-user link 18:30:38 fair 18:30:49 Sure, as an exchange I can look at each user, and their average number of coinbases per ring 18:30:58 And if it's more coinbases per average I could suspect that they're a miner 18:31:08 But that's about all 18:31:27 while there are some concerns with coinbase-only having only a layer of separation, I think the real benefits are being minimized slightly, especially to non-mining users 18:31:35 also, coinbase is currently polluting normal tx rings, since a large proportion are identifiably spent/not spent 18:32:12 koe: the newer weighted selection algorithm does help this to an extent (relative only to tx weight, nothing else) 18:32:36 One thing that is important about privacy is that third parties that have data like this are lawyer magnets. If an exchange couldn't possibly identify their mining user habits, they can't be hacked or subpoenaed to determine one of their customer's hash rates 18:33:08 * Isthmus indicates agreement with last few comments 18:33:39 In my ideal world, we have 13 ring members and two selection algorithms. Precisely 11 of the members are non-coinbase, selected with current algorithm. Precisely 2 of the members are coinbase(/coinbase-only) that are selected independently. 18:34:10 Isthmus: that would not be good for many reasons :) 18:34:27 notably, you need a set of at least 3 18:34:41 Oh, I'm not married to the numbers 18:34:47 Just making an example 18:35:36 (trying to avoid the misconception that adjusting our coinbase ring member selection algorithm will somehow be zero-sum with the rest of the anonymity set or users) 18:35:46 koe: I know that rbrunner (sp) made an implementation of multisig so it might be good to speak with him. I don't see him online now and haven't seen him for a little while but should still be around 18:37:09 on the other hand, I wonder if enforced ring types is too much like reacting to how people use it; although the same could be said for many other protocol rules 18:37:09 Anyway, I derailed Isthmus's discussion of his other data with this topic... 18:37:40 Also, let M be the minimum plausible age between any output and it's temporally closest ancestor coinbase 18:37:46 :- P 18:38:01 That can either be a plotable feature, or fixed for all transactions at zero 18:38:18 nioc ok Ill reach out 18:38:58 I think n3ptune and I may plot this for all outputs just to show the point 18:39:27 Other two things on the agenda - encrypted unlock time, and tx_extra in coinbases 18:39:35 I can get into these if people are interested 18:39:38 Sure, I saw your information about encrypted locks 18:39:45 (I also wish to address timelocks anyway_ 18:39:46 ) 18:39:54 Cool, lemme copypasta real quick 18:39:56 Oh, and for the encrypted + enforced unlock time, we have to decide on a format. Currently, 3 things are being put in the unlock field: 18:40:01 Small integers like "12", presumably to be interpreted as height differences, i.e. "unlock in 12 blocks" 18:40:03 Large integers like "1980000", presumably to be interpreted as block heights 18:40:05 Very large integers like "1578561720", presumably to be interpreted as unix timestamps 18:40:07 While normally I'd be loathe to bring real world time onto the blockchain, I am inclined towards this approach: encrypted unlock time is a future timestamp recorded in unix seconds, and each ring must include a range proof comparing the unlock time to the oldest or youngest ring member (I haven't fully thought this through). 18:40:10 The minimum lock time of 10 is trivial for any outside observer/miner to enforce by delaying (or rejecting) transactions with rings containing members less than 10 blocks old. This requires no mathematical validation within the transaction. 18:40:12 The encrypted unlock time could actually be defined as timestamp - 1500000000 to save a bit of space by removing the offset from some of time between 1970 and deployment, but that could be overengineering. 18:40:18 * Isthmus hands the mic to sarang 18:40:38 We have a relatively efficient way to do encrypted timelocks, as introduced in DLSAG 18:40:46 Small integers are block heights. If you put 12 now, it's pointless. 18:40:49 I'm 100% in support of encrypted lock times... I know that sarang has done some work into the requirements on that in addition to isthmus 18:40:51 The method is described here: https://github.com/SarangNoether/skunkworks/tree/timelock 18:41:21 It works as follows: outputs come equipped with a timelock Pedersen commitment (units aren't relevant for this at the moment) 18:41:44 " Small integers are block heights. If you put 12 now, it's pointless." Ahhahahaha that's what everybody is doing. Lemme make a plot real quick 18:41:50 Signatures come equipped with an auxiliary plaintext time that's chosen semi-at-random 18:42:03 as well as a particular auxiliary commitment 18:42:29 There is a range proof constructed using all these values, and CLSAG/MLSAG gets a new set of entries too 18:42:55 This maintains signer anonymity, shows the timelock has passed, but does not specifically reveal information about it 18:43:24 The cost for CLSAG is 1 new group element; the plaintext timelock is replaced by a plaintext intermediate value 18:43:34 and the auxiliary per-signature commitment is 1 new group element 18:43:38 does this mean the no-locktime transactions will be indistinguishable from locktime ones? Or just that the locktime ones will have an obfuscated time lock? 18:43:48 The rangeproofs can be worked into the existing bulletproofs, likely for free due to padding 18:43:56 Indistinguishable plz 18:44:00 Depends on how it's implemented 18:44:32 indistinguishable would probably require no-locktime txns to have a dummy encrypted locktime 18:44:39 So the cost is 64 extra bytes per signature, and 32 bytes per extra timelocked output 18:44:57 Yep, you'd include zero locktime 18:45:07 and the rest of the process proceeds the same 18:45:17 So this is not free, but it's not terribly expensive either 18:46:12 Anyway, this information is to supplement what Isthmus brought up about how timelocks are handled now 18:46:15 It's completely offtopic but I personally like the idea that we can embed an arbitratry hash in a transaction in a way that is indistinguishable from other txs, for timestamping purposes. 18:46:18 * sarang returns the mic to Isthmus 18:46:33 Would only be half or a quarter of a hash in that case though 18:46:45 (using the encrypted time lock field) 18:47:20 @binaryFate if we add an enforced encrypted memo field, that would be a very good use case 18:47:24 binaryFate: well, you could always pick your txn key as the Hp of some message. is that not what you mean? 18:47:54 it works too, but require you don't lose your local storage. 18:48:34 sure. you want to be able to extract the message also, something like that? 18:49:31 just exhibit the message later on and point out to a past hash in the blockchain that timestamps it, without people taking notice this was a timestamping tx. 18:49:43 but if you have message you can get hash back, so tx key works perfectly I guess 18:49:50 oh neat 18:49:59 anyway, sorry to derail 18:50:06 Isthmus: take it away :) 18:50:24 Derailing conversation is a key part of research! :- D 18:50:31 I think that's where 2/3 of our interesting stuff comes from 18:50:40 *nod* i prefer these lively research meetings for sure 18:50:52 Anyways, last topic I had has been discussed significantly since I initially mentioned it. So I'll intro and then duck out of the way 18:50:52 You had some notes, Isthmus, on how timestamps are represented 18:50:53 https://usercontent.irccloud-cdn.com/file/Ovp9yP0j/image.png 18:50:57 I will most likely need to take off, so I'll bring up my other mining pool ring signature proposal (which I mentioned in the past) when I get back 18:51:18 @isthmus agreed, it seems that new ideas fluster that way. 18:51:41 Oh go @sgp_ 18:51:51 ah, so very fast 18:52:22 there are special ways we can construct rings for public mining pools to protect the "integrity" of outputs (make it no longer publicly known what transactions they are spent in) 18:52:47 for public mining pools that share transaction histories, it's clear which outputs are change outputs, which are later spent by the pools 18:53:13 to avoid this, public pools can select rings using exclusively decoys that they create as payments to miners 18:53:51 that way, outsiders have no way to distinguish the output from the other outputs given to miners. saves one output per payment, per public pool 18:54:27 this is not a consensus change, but it would require a separate "public pool selection mode" or similar 18:54:37 * Isthmus coughs *could be consensus* 18:55:07 Isthmus: how? payouts won't be from coinbase outputs 18:55:16 * Isthmus re-reads 18:55:37 Aah, maybe I was thinking of something slightly different 18:55:39 Carry on :- ) 18:55:47 this protects pool change outputs from being known as spent by the pool in specific transactions 18:56:06 that's about it, just wanting to make sure this idea is resurrected, since I introduced it nearly 2 years ago now 18:56:36 Thanks sgp_ 18:56:43 In the interest of time, Isthmus please go ahead! 18:57:55 * Isthmus recaps: 18:58:04 Everybody seems to use the miner_tx differently, including some really strange stuff like many blocks with 60 B of null padding(??!) https://xmrchain.net/tx/7dfcc4e5d8bd772e3373e51d4140052121503d9b4f3cb6587251292bf06ced9a 18:58:11 https://usercontent.irccloud-cdn.com/file/tXHruCE0/image.png 18:58:15 This has implications for privacy of all users. For example, I have a list of blocks mined by the pool that added 60 B null padding to each miner transaction. When this person creates multiple-input transactions to claim the reward, ring signatures offer them no protection. 18:58:19 (Multi input + miner fingerprint is statistically noisy, so we know when those outputs are really spent, and can rule them out as decoys in other transactions.) 18:58:29 To avoid fingerprinting, it's important that any implementation mimics the full hierarchy on any block. For example, if we accommodate {nonce, pool, proxy}, then every miner (including solo mining core software) should put random data in pool & proxy. Otherwise we've just made a fancier way to leave the same fingerprint. :-P 18:58:44 Anyways, others in this room have made a lot of progress on how to address this, so I'll let them jump in 19:00:31 Anyone have anything to add in particular to this? 19:00:59 nope, but I have to get going 19:01:09 OK, suraeNoether: any brief update before you go? 19:01:12 Otherwise, no worries 19:01:12 sarang is this the encrypted timelock? https://justpaste.it/2754y 19:02:22 just that sarang and i have been having some extremely deep discussions about unforgeability in CLSAG and the crappiness of linkability models... we are nearing some very valuable improvements to d-CLSAG as written... 19:02:51 i'll let him describe more; i've also gotten my matching simulations (apparently) working correctly on my matching-mojojo branch of mrl-skunkworks 19:02:54 other than that, i have to get going 19:02:59 sorry :( 19:03:04 i'll drop in later today for more of an update 19:03:39 koe: you include the auxiliary timestamp in the signature's extra commitment in the model I worked up 19:03:53 Isthmus: anything else that you hoped to share? 19:04:06 (sorry, trying to ensure everyone gets a chance to finish their presentations) 19:04:59 Thanks, I'm outta new material 19:05:04 OK, thanks Isthmus 19:05:47 I worked up some stuff on timelocks (shared earlier), did a blag post with sgp_ relating to supply auditing (to answer questions that often come up), and got into the weeds on security models relating to linkability 19:06:16 Linkability meaning the formal definition used in linkable ring signatures, not any particular transaction linking 19:06:34 koe: what you have may be algebraically equivalent; I'll take a look shortly 19:06:45 OK, did anyone else have something to share that was missed? 19:06:51 So many things to discuss today! 19:07:38 well does anyone have thoughts on enforced sorted TLV format for the extra field? I have spammed up the channel a bit recently, with that topic 19:08:12 Can you recap the benefits and tradeoffs briefly, for those who didn't see the earlier discussion? 19:08:19 If someone wants to stuff some random data in there, it's as visible as now, no ? 19:08:21 and pursuing coinbase extra field standardization by seeking an inter-pool committe 19:08:35 (note that monerologs.net has logs of this and other channels available) 19:08:39 What's an inter-pool commite ? 19:08:50 committee between pools 19:08:57 composed of 19:09:06 Oh you mean just talk to pool ops ? 19:09:12 lol yeah 19:09:44 these things are called standardization committees in industry 19:13:32 benefits of enforced sorted TLV + guidelines for use: a) makes sure all implementations are using the same essential format for constructing extra fields, since without guidelines or structure each implementation is ad hoc; b) for those who are privacy minded, there will be a clear way to blend in with other like minded implementers (for example, 19:13:33 who knew that the code base sorts field entries, but at least one live implementation does not?); c) leaves extra field almost as open ended as it is now, so those who choose opt-out privacy (choose to stand out from the crowd) for whatever reason, can still do so trivially 19:14:17 In the earlier discussions, were there particular opinions opposed to it? 19:14:23 If so, why? 19:15:58 tradeoffs: a) it may have limited real impact on transaction indistinguishability, especially among coinbase tx if most pool operators aren't on board; b) implies no stricter enforcement of the field will be pursued (which would directly address questions of indistinguishability; c) so far as coinbase tx go, many pools publish their mined blocks 19:15:59 (counter argument is Monero development is focused on on-chain, and can't concern too much off-chain activity) 19:16:27 Noted; thanks 19:16:45 Since you were interested also in the hidden timelock construction, any other thoughts on that as well (from your link above) 19:17:18 actually I just felt inspired, and wanted to confirm my understanding 19:17:21 Keeping in mind that the range proof can be absorbed into the existing one, meaning no effective change in size or verification for that portion of it 19:17:31 Your construction appears algebraically equivalent to what I listed 19:17:46 I dont know enough about CLSAG to make a real judgement 19:17:54 The CLSAG part could apply to MLSAG as well 19:18:01 Perhaps if we knew how much timelock is being used in the wild 19:18:07 The only difference is how the commitment to zero is handled in the signature 19:18:37 In MLSAG it would be _very_ expensive, but in CLSAG it adds only a single auxiliary linking tag, and makes the verification multiexp a bit more expensive 19:18:54 oh nice, I was imagining all those extra mlsag scalars 19:18:55 If people think it's worth seriously considering, I can get more precise timing estimates on those curve operations 19:19:04 Yeah, for CLSAG you don't add scalars 19:19:25 It is in no way worth it for MLSAG 19:19:30 either in size or extra verification 19:20:05 The current CLSAG data has some custom curve-op code for efficiency that wouldn't apply to this new 3-CLSAG timelock construction 19:20:13 (the Python code is not suitable for timing, only to see how it works) 19:20:46 Anyway 19:20:48 We're way over time 19:20:55 Anyone have ACTION ITEMS for this week they want to share? 19:21:08 (I find action items useful for me, to help prioritize and share those priorities) 19:21:30 I will continue working with Surae. Hopefully I can share more next week. 19:21:53 I have several... some additional work writing up comparisons of linkability definitions between a few papers, to get some timelock numbers (if it's seen as useful), and some data analysis relating to sublinear protocols 19:22:05 Oh, and one additional note... the IEEE S&B conference is coming up later this year 19:22:11 https://ieeesb.org/ 19:22:22 Both suraeNoether and I are on the program committee 19:22:29 It's a great event, and is seeking papers 19:22:40 If you have some work that could be worth sharing, consider writing it up formally and submitting 19:22:50 Ok cool 19:22:54 (you should note any conflicts of interest with the program committee if you feel they apply to you) 19:23:24 I went to this event a while back, and it had great presentations (but was not streamed) 19:23:32 Any other comments, questions, or final remarks before we adjourn? 19:23:45 Normally there isn't so much to cover in one meeting; it's a great problem to have :D 19:24:02 Going once... 19:24:21 going twice... 19:24:29 I will be focusing on ZtM2 multisig, which may be done by next meeting in which case Ill start in on bulletproofs; and anything else that comes up, perhaps work on updating the fee priority multipliers for surge situations (emails with ArticMine) 19:24:40 Last thing, I didn't realize IEE had Security and Privacy on Blockchain. That's pretty cool. 19:24:49 I'm happy to help with bulletproofs koe; I have a branch for it in my ZtM repo 19:24:59 atoc: it's a great event 19:25:00 all in good time :) 19:25:08 I'm very happy to be asked to be on the committee :) 19:25:26 OK, thanks to everyone for attending, even though we went over the usual time 19:25:27 Yeah that's awesome! 19:25:32 Logs will be posted shortly to the GitHub issue 19:25:38 It was good. There was a lot of material. 19:25:38 Discussion can of course continue 19:25:52 (I just need a stopping point for the posted logs!) 19:26:13 Ah yes ofcourse 19:26:36 See a source like monerologs.net for all your logging needs =p 19:26:41 (I don't even recall who runs that) 19:27:44 sarang how do you stay logged in all the time for the IRC? 19:27:50 do you leave it open on your computer 19:27:52 who ever it is praise them \o/ great service 19:27:58 Yes I agree 19:28:00 I use IRCCloud, which is a paid service (5 USD per month) 19:28:05 Ah I see 19:28:12 It has a really nice interface on web and mobile 19:28:18 (I'm not paid to say that =p) 19:28:38 I would consider doing it if I there were no Monero backup logs lol 19:28:49 The logs really are great 19:28:59 It's nice if you have a need for ongoing connectivity and don't want to resort to external logs 19:29:30 yeah i'm sure it's especially nice if you get PM's 19:29:32 There's also bridges to this channel, but I don't know much about the details on that 19:29:38 for sure 19:29:40 Yeah I am on mattermost too 19:30:01 I have been checking those logs, but I will now just go to monerologs.net :) 19:30:06 That bridge seems to disconnect a lot 19:30:15 Yeah, the interface on monerologs.net is really good 19:30:19 Oh I didn't realize that 19:30:23 and it seems to update very quickly 19:30:33 that's cool 19:30:37 I should perhaps link to the log site in the topic 19:30:42 Yes indeed 19:30:46 so it's easier for people who want logs 19:30:58 I think I heard about it last week but forgot it until you just reminded me the url again 19:31:17 (y) yeah I'm sure people are interested 19:32:06 It even has a dark colour theme, which is my preference 19:32:14 ah I see what sgp_ was suggesting: pools consume coinbase and spit out miner payments + change payment back to pool; it's apparently obvious when pool consumes the change payment, since it's in a clearly fingerprinted pool tx (bunch of rings with different block coinbase references); so, the pool selects ring members from all the outputs that pool 19:32:14 has ever made, thereby hiding the pool's change output amongst other pool outputs 19:33:15 Meeting logs are now also posted to GitHub: https://github.com/monero-project/meta/issues/430 19:33:21 (I find it convenient to have them available there) 19:33:33 yes looks good sarang 19:33:45 oh nice 19:34:27 It was great to have a meeting with so many interesting topics to discuss 19:35:56 Yes indeed, what is CSLAG btw? I know it is something you and Surae have been working on 19:35:57 what would be a good way to decide if segregating ring member types is good to pursue? 19:36:33 atoc their research papers here https://web.getmonero.org/resources/research-lab/ MRL-0011 is CLSAG 19:36:50 CLSAG is a modification to our MLSAG ring signature construction with much better size and time efficiency 19:36:50 intended to substitute MLSAG 19:37:06 Note that the paper is being extensively updated for clarity and a better security model 19:37:17 Ah I see 19:37:28 An average 2-in-2-out transaction would drop in size from 2.5 kB to 1.9 kB 19:37:35 and be around 15% or so faster to verify and generate 19:37:50 If hidden timelocks were included, these numbers change 19:38:17 koe: we'd need a more formal risk/threat model IMO 19:38:25 (regarding ring separation) 19:38:30 Oh nice. Yes I do remember hearing about the transaction size 19:38:54 yup koe :) 19:39:00 lmk if you have questions 19:39:04 atoc: there seems to be general support for including CLSAG in a future network upgrade, but the preprint has not undergone third-party formal review 19:39:32 pool are certainly troublesome 19:39:36 sarang: which is the MLSLAG paper? 19:40:02 MLSAG = RingCT basically 19:40:06 One version of MLSAG is described in MRL-0005 19:40:22 cool I see that, just making sure it's that one 19:40:26 ZtM explanation is more thorough (imho) 19:40:27 But you should read koe's excellent Zero to Monero to see how it's used more safely in multi-input txns 19:40:32 ^ heh yup 19:40:50 The cross-input method described in -0005 is not a good idea 19:40:50 Yes koe I have not gotten to that section yet, but I thought I would look at the paper just to get an idea rn lol 19:41:13 CLSAG would operate as essentially a drop-in replacement to either transaction protocol approach 19:41:15 Ok I will just read it in ZtM then 19:41:22 Yeah, please use that atoc 19:41:25 cross-input was used in RCTTypeFull, which ZtM 1st edition includes 19:41:33 now deprecated 19:41:35 Right, but we don't use it anymore 19:41:49 The CLSAG PR doesn't even support it AFAIK 19:41:52 AH I see I see 19:44:03 If we end up moving to something like Omniring or multi-Triptych, cross-input is no longer an issue :D 19:44:17 since the proof applies to multiple signer indices! 19:44:42 Unfortunately we still don't have a great soundness argument for one portion of multi-Triptych (only its single-input variant) 19:45:27 I see. Yeah I really need to read up on these different technologies lol. Unfortunately, I am not familiar with Omniring or multi-Triptych 19:45:30 I suspect the multi-variant is sound in practice, but that's not a proof :) 19:45:39 atoc: they get annoyingly technical very quickly 19:45:53 and the security proofs get pretty far into the weeds 19:46:10 Triptych is described in a recent preprint and was developed by MRL 19:46:18 Oh nice 19:46:20 Omniring was developed by another team of researchers 19:46:31 There are other clever approaches as well from different teams 19:46:44 I see many ring signatures topics in ZtM but not Triptych 19:46:58 Triptych is new and is neither reviewed nor deployed 19:47:02 (nor should it be at this point) 19:47:19 Here's a good question, in a semi-nutshell how does Zcash and Dash differ from Monero? 19:47:29 Triptych (single-input only): https://eprint.iacr.org/2020/018 19:47:33 I am only familiar with Monero and not those other privacy coins. 19:47:36 Omniring: https://eprint.iacr.org/2019/580 19:47:46 RingCT 3.0 (one variant): https://eprint.iacr.org/2019/508 19:47:49 thanks for the links 19:47:58 Those are the ones that most interest me at the moment 19:48:57 So of course Zcash is really two asset types 19:49:18 "Zcash" (shielded) and what I jokingly consider "Tcash" (transparent, basically equivalent to bitcoin) 19:49:20 Nice, I'm reading these abstracts and seems intresting 19:49:39 Spend authorizations for Zcash (not Tcash) are a generalized proof that shows the spent inputs are from a large accumulator set 19:50:00 Like in Monero, this does not remove all transaction metadata, but does assert high anonymity (absent other information!) 19:50:01 Hmm I see 19:50:15 But why is Zcash a privacy coin? 19:50:22 Note that most popular services do _not_ support Zcash, but only Tcash 19:50:25 or considered a privacy coin, it must hide something right? 19:50:33 This requires a "de-shielding" operation that carries risk 19:50:45 Oh I see 19:50:46 I don't like the term "privacy coin" FWIW 19:51:14 Not sure what to call it then, since this seems a popular term. What do you prefer to cal it? 19:51:17 One way to view Zcash (not "Tcash") is similar to Monero but with a "full anonymity set" 19:51:31 I prefer to switch it up... assets like Bitcoin are transparency coins :) 19:51:35 lol 19:51:39 Nice 19:51:39 Panopticoins. 19:51:44 nice term 19:52:29 It would be great to use a protocol similar to Zcash, but this requires a structured and trusted setup process 19:52:39 If that process were sufficiently compromised, you could forge spend proofs 19:52:47 Such a flaw occurred in the original version of Zcash 19:53:04 It is not possible to definitively prove that the flaw was not exploited, but there is no obvious evidence of it (this is a subtle and tricky point) 19:53:21 (note: it wasn't a compromise, but a flaw in the math surrounding the process) 19:53:34 I suspect there would be _very_ little support for doing this in Monero 19:53:52 Doing that kind of generalized proof efficiently is currently not possible with known techniques, unless you have a trusted setup 19:53:55 What is the protocol of Zcash though? shielding 19:53:59 There's a lot of ongoing research to remove that limitation 19:54:06 The protocol is complex and very custom 19:54:24 This is the current specification: https://github.com/zcash/zips/blob/master/protocol/protocol.pdf 19:54:35 You'll see both the older and newer spec: Sprout (old) and Sapling (new) 19:54:49 There's a newer one (Blossom) that really didn't change anything of cryptographic substance 19:55:17 Are Zcash transaction less costly than Monero? 19:55:23 I imagine it could be 19:56:28 They are about the same size typically 19:57:09 but are fast to verify 19:57:09 Tcash transactions, of course, are more similar to Bitcoin (they include no privacy features) 19:57:16 this is a nice high level view of differences between bitcoin/dash/zcash/monero https://medium.com/@exantech/methods-of-anonymous-blockchain-analysis-an-overview-d700e27ea98c 19:57:22 (BTW this "Tcash" terminology is non-standard; I made it up to better clarify the two pools of funds in my head) 19:57:24 I see, but you like parts of Zcash? (it seems, don't know for sure) 19:57:27 thanks koe 19:57:43 I like the privacy protocol in Zcash, but don't particularly like its trust implications 19:57:53 Yes I know Tcash doesn't exist lol 19:57:56 I don't like that it's optional, which carries risk 19:58:02 I see 19:59:36 Ugh, I hate the use of the term "mixing" to describe Monero 19:59:40 that is not what is done 19:59:49 Mixing is an opt-in method that actually spends mixed funds 19:59:54 Monero does not do this 20:00:18 Also, the wallet does not "create random outputs on the blockchain" to hide among 20:00:24 That is a poor description 20:00:26 why do people use mixing to describe then? was that what they did before introducing ringCT? 20:00:57 No 20:01:09 Because the non-interactive nature is hard to distinguish from mixing without some technical thought 20:01:23 FWIW some of the concerns in the listed papers from that article _have_ been addressed to some extent 20:01:42 (I can't speak to the accuracy of that article's discussion of Dash, since I know next to nothing about it) 20:01:58 it's mixing because you have a bunch of decoys, and your real one, and you 'mix them up', and insert to a ring signature 20:02:03 sigh 20:02:39 youll never escape it sarang! 20:02:55 If your output is mixed, you actually participated in the transaction; absent other information, it should not be possible to know if a Monero output participated in any transaction 20:03:12 it's a subtle but very important difference atoc 20:03:19 agree that mixing is the wrong term 20:03:25 I will keep this in mind sarang as I am reading 20:03:29 ah that makes more sense. 20:04:34 that complaint only makes sense if you know something about mixing services, otherwise the word is uncontroversial imo 20:05:40 Eh, maybe uncontroversial, but makes it sounds like "all approaches are basically the same thing" 20:05:44 Which is absolutely not true 20:05:58 I don't like simplifying things to the point where important meaning is lost 20:06:04 well its the nuance. especially as you delve deep 20:06:12 The approach with CoinJoin is not the approach of Monero is not the approach of Zcash etc. 20:06:23 ^ basically that 20:06:24 sarang, thanks for your willingness to share btw. I am excited now. I am going to do more reading today and tomorrow and I would love to ask you questions and your thoughts on these topics. 20:06:39 fair enough ^^ 20:06:53 Sure. I might suggest joining #monero-research-lounge for not-directly-research topics (it's an off-topic channel) 20:07:21 atoc: any particular interest? For development, the math, just general knowledge? 20:08:00 Oh cool, yeah well basically when I just run into questions. I am going to go through the ring signature stuff today MSLAG and CSLAG) 20:08:16 I'm happy to join the lounge 20:08:29 What's your background? Is it math or CS? 20:08:37 (might help guide the level of discussion) 20:08:53 Currently I am working with Surae and I need to get him some stuff, but I want a good general knowledge of Monero 20:09:00 CS 20:09:11 neat 20:09:28 Mastering Monero is a good starter resource; and ZtM is a good deeper technical resource 20:09:41 Yes I have read Mastering Monero already 20:09:44 I can't think of a good initial Zcash resource 20:10:02 Most seem either way too "glossy" to give real meaning, or too in-the-weeds (like the protocol spec) 20:10:03 It was good. I hope to finish ZtM within the next week 20:10:32 Ah I see. I don't mind reading the protocol spec, but I probably won't read the whole thing 20:10:43 Just enough to get an idea about how it compares to Monero 20:10:55 how the technology compares 20:11:09 That protocol spec is fantastic, but you really need to read it carefully to understand the subtle points of what's happening 20:11:23 Have you read it all? 20:11:29 Nope 20:11:34 Just the parts I needed more information about 20:12:06 Makes sense 20:12:08 It's quite long 20:12:17 At some point I would still like to see how Dash works 20:12:23 but perhaps that will be for later 20:12:28 Can't help you there 20:12:43 There is chat.zcashcommunity.com where there are Zcash dev channels 20:12:54 I'm sure the experts there could answer questions much better than I can 20:13:07 Sure if I want to go deep I will look at that 20:13:40 Zcash is a strange currency, and I am personally not too big of a fan. I know I can like Monero and Zcash both, but I prefer Monero's way of doing things 20:13:44 hence why I am here 20:14:26 Zcash is very interesting as an approach to fungibility, but it seems to get messy because of its optional features, its corporate structure, etc. 20:14:42 It makes tradeoffs. Monero makes tradeoffs. Bitcoin makes tradeoffs. And so on 20:14:54 Nobody's "solved this" yet 20:15:08 Yesh the corporate structure rubs me the wrong way and is it there some sort of founder's fee 20:15:12 or founder allocation 20:15:30 There's a protocol-enforced development fee. There's ongoing discussion about what to do with it in the future 20:15:40 Yes indeed, I agree with you. I think CSLAG will be cool if it rolls out 20:15:56 reducing the transaction size would be nice 20:15:58 Yeah, CLSAG is not a major shift in thinking when it comes to signatures, but it's an improvement 20:16:08 wow that protocol doc is intimidating; monero pure protocol would be half that or less, assuming dense formating like that 20:16:23 It's very complete 20:16:32 Of course, it handles both Sprout and Sapling 20:16:37 Yeah koe lol 20:16:38 and Blossom, I suppose (but that's trivial) 20:17:10 Gotta give them credit for fantastic naming 20:17:24 I personally also like Monero's tail end supply increase. I.e there is no hard cap 20:17:25 (let's head to -lounge to continue this discussion; it's off-topic) 20:17:32 sure 20:17:32 #monero-research-lounge 20:34:17 sarang, a paper just came across my desk that reminds me of our DLSAG woes with basepoints and key images. https://eprint.iacr.org/2019/202.pdf 20:34:39 Oh yeah, I remember when this came out! 20:35:05 I hadn't considered it in the context of e.g. DLSAG 20:35:23 BTW suraeNoether, have you seen babySNARK? 20:35:50 A fun toy construction for playing around with succinct proofs: https://github.com/initc3/babySNARK/ 20:36:03 nerp have not 20:37:04 good documentation 21:17:31 nice busy day here in chat, it's nice :) 21:25:17 does anyone think the separate public pool decoy selection algo has downsides I'm not considering? 21:25:29 the most obvious to me is if someone uses it even if they're not a public pool 21:26:02 maybe it's best described as a "public wallet mode," since it's not limited to just pools theoretically 21:46:32 Has that method been directly compared to the coinbase-only approach? 21:46:44 I don't think Isthmus made a direct comparison (checking logs) 21:48:46 sarang: this is independent of the coinjoin approach 21:48:51 sorry, coinbase approach 21:49:03 lol 21:49:21 in short, mining pools have 2 categories of outputs: coinbase and change 21:49:34 this better protects the latter 21:49:40 does nothing for the former 21:50:18 meanwhile, a coinbase consensus change like I described in my blog post helps the former but not the latter. but they are compatible with each other (not mutually exclusive to implement) 21:50:20 this = which approach 21:50:39 Ah, got it 21:50:43 Your last message clarifies 21:51:34 here's that master deck I made a while back now https://usercontent.irccloud-cdn.com/file/yogUlQ6W/Mining%20Pool%20Strategies 21:53:02 it's likely that with restricted ring member types, the change output from multiple coinbase-spending tx will be merged in future tx. sgp_ solution in combo with split member types would probably have the best effect to reasonably hope for 21:53:20 merged, and thereby revealed quite clearly ^ 21:54:31 1311 is the most similar solution to (special decoy selection) and (coinbase-only rings) 21:55:46 I think that, independently and together, these two changes have more pros than cons 21:56:23 I hope Isthmus can shed some light on the details, alongside surae's matching endeavor 21:58:07 since pool mining seems here to stay, bar any new innovations, it feels reasonable to tailor the protocol to that reality 21:59:13 yeah, there are definitely some cons to the method I describe for input selection. it benefits the network if pools are not malicious only 21:59:35 but if they are malicious, really the only good recourse is to increase the ringsize for everyone 22:00:40 there's no incremental harm with this selection algorithm if pools are malicious, and an incremental good if they are non-malicious as far as I can tell 22:00:40 if they are malicious the change will be neutral to that faction, and honest pools would (plausibly) benefit 22:01:05 lol 22:04:06 I don't know if stealth pool is as big a step up as it seems, since someone can collect and parse a pool's hashing blobs for each block, then compare with published blocks 22:05:54 probably not in practice, I made this well before people started looking at the blobs 22:06:00 would have the same effect as publishing mined block lists, except the attack vector would have complete lack of visibility to common users 22:10:08 fwiw some pools no longer share all the payment information. supportxmr only shows the amount (useless) and number of payees 22:10:25 but even the number of payees is relatively useful information 22:10:34 that's good 22:11:08 the fee is often unique-ish too, and that's shown on the site. people can still likely reliably find pool transactions 22:22:25 thinking about it.. the transaction graph of both miners and pools is horrible; each miner is periodically sweeping his payouts in combination with the outputs from previous sweeps! or the equivalent effect from periodic consumerism. Pools have a very similar heuristic, periodically sweeping their change outputs into tx with the output of previous 22:22:25 sweeps (or creating heuristically significant not-direct input-output loops via consumerism). 22:23:47 sgp_'s modified decoy selector would have to be recommended to serial miners as well 22:27:51 koe: I'm interested in protecting the miners more than pools 22:29:52 Well, actually in this case the selection also will help everyone else since there's another set of outputs (change outputs) that are no longer heuristically dead 22:34:49 I feel like a majority, or vast majority, of funds directly touched by pools (coinbase inputs, and outputs), and many of the outputs of miners (those which get churned in one way or another), have very weak ring protection. Moreover, even if a miner is doing sweep all periodically, by tree-ing off the pools with known roots, they are revealing many 22:34:50 of their own decoy outputs as well (heuristically) 22:35:49 it's only when funds leave miners do they really enter the indistinguishable maze of ring sigs (setting aside other problem childs like exchanges) 22:37:19 a miner's best bet might be a) sgp_ decoy selection, b) periodically segregating funds (stop mining with one address, start mining with new address, and don't let funds from addresses cross over) 22:38:33 fwiw I'm not suggesting that either of these solutions alone does much for specific users. It only matters on an aggregate network scale 22:39:25 Suppose public mining pools create 20% of outputs including coinbase. That's 20% viewable to everyone, and therefore 20% of decoys selected on average are useless 22:40:44 With segregated Coinbase rings, maybe that means only 5% of decoys in other rings (from the change) are useless 22:41:21 Standalone, the actual impact on specific users is hard to quantify even at 20%. Probably zero for most 22:41:53 But if there was a 50% chain split, then it exacerbates the issue to 70%, and then it starts having a greater impact on the network 22:42:37 That's how I view it. Best to increase network resiliency by reducing the baseline condition, so that extreme conditions are less significant 22:45:58 agh I cant wait for surae's matching simulator 22:47:16 ^ suraeNoether 22:47:18 :D 22:47:32 koe the simulator is passing tests currently 22:47:43 you can play with it and generate your own blockchains 22:47:57 and study the ground truth of the otherwise obscured monero ledger 22:48:08 yay! 22:48:15 until i break it again 22:48:17 :\ 22:49:09 actually better not get involved or ztm2 will die a lonely death 22:49:21 lol 22:50:13 Yup, that research is crucial here 22:51:35 But even really basic stuff by comparison like the Excel sheet I made and MRL-1 show that impacts are exacerbated when the network is already stressed 22:55:47 suraeNoether for multisig I'm wondering a) what are the keys stored in tx_extra for? and b) how does the implementation avoid duplicate signing (e.g. when two people share a key.. they can't both use it to sign) 22:56:52 that has me thinking. Is there technically a maximum to how many signers can be in a ring? 22:57:18 no 22:57:20 Relevant issue to my topic https://github.com/monero-project/monero/issues/5222 22:57:53 well by technically, how much the code can handle, idk 22:58:26 koe can you elaborate on the duplicate signing question? 22:59:53 What do you mean "how many signers" can be in a ring? 22:59:56 the signing key is a merged key, of all the diffie hellman shared keys, each of which (for M > N) is shared between 2+ members. To sign, they each sign with their component keys, then merge the signature with simple sum. But, since each person has keys that other people also have, the signature components would get duplicated 22:59:59 The answer is exactly 1 23:00:01 Insight: no cap technically. https://moneroblocks.info/search/5e75b4596c234ad17d34c44c3f07da508afb985748b3066bbfe2923cedb0b81a 23:00:10 How that was derived is not the verifier's business 23:00:59 I was reading "mastering monero" and they were discussing minimum amount of signers for a ring. going from 3 to now 7 23:01:04 koe our construction was originally based on the musig signature scheme, which used multisets of keys, not sets of keys; duplicates allowed. 23:01:28 and wondered the opposite (the max) 23:01:40 current is 11, and it's fixed at 11 23:01:44 Insight: technically it's now fixed at 11 23:01:58 but there's not a cap in the ring signature algorithm or anything like that 23:02:20 oh got it. 23:02:44 any reason why 11 was picked compared to like 13 or 15? 23:02:57 koe so when those shares are passed around and summed, the signers are doing it with an encrypt-then-auth scheme. so they can see the public keys used by the other multiparty computers and detect duplicates. if this is unpalatable for whatever reason, the signer can abort 23:03:04 Insight: because it goes to 11 23:04:25 ah ok; in my original multisig chapter I reduced communication steps by having only the first member of a sorted list sign with a given key; sounds like current scheme is to just pass it around 23:04:25 Insight: we are currently investigating what ring sizes are optimal or preferred, but 11 was selected in part to make sure txn verification could be kept under intolerable thresholds 23:04:59 Insight: the other part of selecting 11 was the spinal tap reference 23:07:12 whats the spinal tap reference? (is there documentation about it) 23:07:42 https://www.imdb.com/title/tt0088258/?ref_=fn_al_nm_1a 23:08:41 does that mean they only construct the response after receiving the partial signature from previous guy? 23:09:00 most blokes play on 10. 23:09:23 ohhhh haha got it 23:10:23 lol 23:10:35 > is there documentation about it 23:12:11 koe, we have a commit-and-reveal stage. 23:12:19 if i recall correctly (and it's been *months*) 23:12:37 should go watch the movie so i can understand monero on a philosophical level 23:13:10 everyone in their coalition has each other's pubkeys by sidechannel. everyone commits to some random signing data and sends it with enc-then-auth to their coalition members. if everything auths, then they send their openers to their coalition members, again with enc-then-auth. if everything auths, they check that everyone's commitments opened correctly. then a partial signature is computed and sent 23:13:10 back to the coalition with enc-then-auth. if everything auths, everyone sends back the information required to finish the signature, again by enc-then-auth. if everything auths, any one of them can sum up the info to compute the final signature. 23:13:24 but it's very very possible i'm not recalling things in the correct order, or that i inserted steps, or something 23:13:33 i would need to reference the preprint 23:13:38 that i wrote :\ 23:13:51 it should be 3 stage signing, for any value of M or N, if communication steps are consolidated using lexicographic sorting of member pub keys 23:14:43 though it requires knowing in advance which M members will sign 23:14:52 that sounds correct, because shorter rounds of communication were shown to be very unlikely to be provably secure under the DL assumption 23:17:32 by preprint do you mean mrl 0009? 23:17:59 this has given me things to think about, thanks; also, do you know what the pub keys stored in tx_extra are for? 23:18:19 (ive heard rumors multisig pub keys are stored there) 23:19:02 i forget numbering. :P i mean "thring signatures" 23:19:15 uhm i believe that moneromooo could answer that 23:19:33 ok ill probably read that tomorrow 23:20:37 It was my understanding that commit-and-reveal is not done 23:20:41 and it's single round-robin 23:20:47 Please correct me if that's not the case 23:20:59 that was the original musig approach that was proven insecure 23:21:08 Right, I'm referring to Monero 23:21:30 yeah, our proof of security relies on the commit-and-reveal 23:21:42 so i hope you are wrong 23:21:50 *i'm also not worried if you aren't* 23:22:00 but yeah 23:22:18 ^ moneromooo 23:22:42 I don't think commitment was ever added to the communication complexity 23:22:48 despite being in the security proofs 23:23:58 *due to the communication 23:24:05 (I disagree, but it's not my call) 23:26:33 iirc there were long discussions around musig in the community, the general sentiment was that reduced rounds are extremely unlikely to be exploitable, fwiw.... 23:27:15 is at least robust key aggregation? 23:27:36 Right, but key cancellation is different 23:27:46 (depending on the communication mechanism) 23:28:01 I thought robust key aggregation was part of musig 23:28:11 Yes, but we don't use MuSig 23:28:20 MuSig requires 3 rounds 23:28:38 im saying, do we at least use the robust key aggregation part, of musig 23:28:51 yes 23:29:02 afaik 23:29:14 ok good lol 23:29:38 unless the code uses a different key agg mechanism than specified in the security proofs >:( 23:30:36 I know the original version of multisig used naive key aggregation 23:30:54 The pubkeys have the same use as for non multisig txes. 23:31:27 are there extra pub keys? e.g. usually there is only 1 23:31:38 " Monero’s first iteration of multisignature, made available in April 2018, used this naive key aggregation, and required users sign their spend key components." is from my old chapter draft 23:32:24 I'm not 100% sure about the following: there are extra pubkeys where at least one or two outputs are to a subaddress. I always forget the exact rule. 23:32:42 it should be extra when at least 1 output is a subaddress 23:33:09 There's a special case to do with change IIRC, which doesn't trigger an extra pubkey. 23:33:18 unless it's a 1-out tx (pre-2out requirement) 23:33:38 oh makes sense 23:35:48 A signer does not sign with keys that already signed. The set of keys used is kept as metadata. I suppose if a signer signs with a key but does not mark it as used, it'll cause an invalid signature. 23:35:49 sarang how would that interact with janus? 23:39:02 hm multisig with advanced escrow could provide coinjoin-like service within monero! privacy your privacy bb 23:44:42 rbrunner is a good person to ask about current multisig implementations 23:44:49 They've been very active in development IIRC 23:49:59 nvm no need to test janus on a tx where all outputs are to yourself 23:52:26 The key aggregation we use predates musig I believe. So it can't be that unless amazing fortuitousness. 23:57:55 ^ suraeNoether 23:58:07 Like I said, I don't recall any changes being made as a result of the paper 23:58:20 [keybase] : our key agg is a simple sum, then? 23:58:26 well generate_multisig_N_N git blame hasn't changed in 2 years, which is my reference for naive key aggregation 23:59:35 Yes, adding.