00:17:38 When at least one output is to a subaddress, and all recipients aren't oneself (currently), there are multiple transaction public keys in the tx extra field. Are these keys sorted or are they associated 1:1 with their corresponding outputs (e.g. the one-time addresses)? 00:18:41 The latter IIRC. 00:18:56 Sorting would require O(N^2) ops to check. 00:20:07 Im just thinking about MoJoin, where sorting would be better for Janus mitigation 00:20:31 and normal subaddress indistinguishability, since those two kinds of transactions would be blended together 00:20:57 @koe working on getting answer for you from the blockchin data 00:21:04 not at the protocol level, just for constructing tx 00:21:11 sweet! 00:31:38 it actually doesn't need to be sorted, just randomized 01:51:52 @koe since bulletproofs activated at height 1686275, there have been 42157 transactions with 16-outputs, out of 2731126 total transactions 01:52:53 1.5% 01:53:54 Shoutout @n3ptune for the data & SQL troubleshooting help 01:56:18 1.8% of non-coinbase tx 01:56:51 this suggests higher max number of outputs would have minimal impact on overall verification times 01:57:11 thanks Isthmus :D 01:59:15 Ill be sure to bring it up again at the MRL meeting this wednesday; list of future developments is up to 16 (most need discussion or are things I made up) 02:04:40 btw it sounded like time locks would only appear in late 2020 at earliest (perhaps v14+), was there a reason they wouldn't be ready this summer (v13+)? 02:04:48 hidden timelocks* 02:09:44 Isthmus would it be possible to see the number of >=16 output tx (RingCT type only, e.g. type 2) from block 1220516 (RingCT implemented) to block 1686275 (bulletproofs added, limit of 16 outputs added)? 02:10:14 note that from 1220516 to 1400000 RingCT was not mandatory for new transactions afaik 02:11:21 fun fact, bulletproofs have been around about as many blocks as borromean range proofs were around 02:11:30 AIUI it was not mandatory but in reality all txs were RingCT 02:12:09 there's a good metric: how many tx were not ringCT during the optional period? 02:15:32 Hidden timelocks require CLSAG as a practical prerequisite 02:15:42 ah right 02:15:56 They work with MLSAG, but scale very poorly 02:16:40 is the expectation to wait one hardfork after CLSAG before adding hidden timelocks? 02:17:02 I don't think there is clear consensus to add hidden timelocks at this point 02:17:14 ok 02:17:36 It would also require playing nicely with existing bulletproofs, and therefore some additional engineering work there 02:17:39 koe> note that from 1220516 to 1400000 RingCT was not mandatory for new transactions afaik 02:18:00 ^ technically true but ringct input forced ringct output so almost all txs were quickly ringct 02:19:51 ah so the metric would be 'how many post-v4 tx took non-ringct as input, and had non-ringct as output?' 02:21:04 Mixable non ringct. If unmixable inputs, you get non rct outputs. 02:24:02 Was wondering about this, why did going unmixable -> mixable not change the transaction era version? E.g. now is RingCT == 2, but clearly there are 3 eras (unmixable v1, mixable v2-v4/6, RingCT v4/6-present) 02:24:16 Just since the actual tx format remained the same? 02:25:09 unmixable doesn't have anything to do with version (besides non-rct of course) 02:28:48 fair enough, the history is just difficult to discern 02:37:31 I'm not opposed to increasing from 16 to 32 max ouputs if it can be shown to be a useful tradeoff given expected use (and the possibility of misuse for DoS) 02:38:02 This would also leave room for hidden timelock range proofs, if they were implemented 02:38:22 (each input requires a range proof for its timelock commitment) 02:49:53 Because rct txes do not work with ring size 1. 02:50:06 Or at least the code we have. 02:50:47 We could have made the mixin 1 to 4 do this, but meh. Corner case. 03:00:04 could treat them like coinbase 03:26:30 has it been discussed (or did I miss it in this epic scrollback) whether if we can achieve the same goal as coinjoin if we, instead, create fake outputs? 03:27:12 has not been discussed 03:27:13 e.g., every transaction (even if being sent to one real user) appears on the chain as 16 outputs 03:27:22 or 32, etc 03:29:27 if the goal is "more privacy" then maybe 03:29:36 but they are not the same at all 03:30:22 i thought it was related to the distinguishabality between different txs types 03:33:41 i mean, its possible to imagine a monero dystopia where your transaction won't be accepted because its a tx by itself and not part of an aggregate tx, because all the "good" members of society use Monero Bank of America (which would obviously batch transactions) 03:34:09 or similar third parties that have identifiable tx construction 03:34:57 but then again its possible to imagine pufflefrump womboots 03:35:27 I think the point of aggregate tx is they are indistinguishable from normal tx 03:35:43 aside from their sheer uncommon size 03:55:48 the new aggregate tx scheme being talked about? 03:56:10 well aggregate schemes in general 03:58:13 oh. i thought coinjoin works such that there are multiple outputs 03:58:54 oh do you mean normal 2-output tx? 04:01:32 yeah 04:03:10 sarang says "Such a construction is useful because it breaks an important heuristic: common control. Under this heuristic, an adversary can reasonably assume that in a transaction spending multiple inputs, all such inputs are controlled by a single entity. While ring signatures obscure the identity of the spent outputs, other heuristics may provide 04:03:10 the adversary an advantage in this determination. MoJoin trades this heuristic for a particular level of trust in a dealer, who may or may not also be a player in the transaction. Specifically, the dealer learns which subsets of input rings are linked to which subsets of outputs. However, we stress that the dealer does not learn which inputs in a 04:03:11 player's rings are actually spent. Therefore, the ability to link inputs is shifted from any observer (in the current transaction model) to a single entity of the player's choice." 04:17:27 well i guess the same question applies there as well. could we use fake inputs. 1024 inputs and 1024 outputs for everyone! 04:23:49 finished MoJoin chapter first draft https://www.pdf-archive.com/2020/01/27/zerotomoneromaster-v1-0-21-mojoin/zerotomoneromaster-v1-0-21-mojoin.pdf 04:30:09 but then again its possible to imagine pufflefrump womboots <= I'm trying, but I never scored high marks in creativity 04:33:38 Oh you're describing your method, not mine 04:33:53 And stole the name! 04:34:52 eh is that a problem? not looking for credit 04:38:05 I can call it JoinMo if you want ;) 04:38:43 as in 'join mo tx yo!' 04:45:51 ok done, it's JoinMo now no takebacks! 12:47:03 Ring Sigs and Stealth Addresses mentioned in the final text for publication of ISO/TR 23244: Privacy and Personally Identifiable Information protection considerations 13:42:49 cool midipoet! thanks for letting us know! 15:31:34 midipoet: how can we get a copy of that draft? I can't seem to find it on the ISO website. 15:31:56 i don't think its public info 15:33:46 it's coming from the ISO TC 307-JWG4 15:34:00 i only got access to it recently, so am still trying to figure out what the fuck is going on 15:34:02 the joys 15:48:27 heh koe I was just joking 16:08:16 sarang: time off on linkability was a good idea 16:08:29 so here's the current state of my thoughts 16:08:43 assume our current definition of unforgeability 16:08:49 sure 16:09:12 due to our structure of the unforgeability definition, unforgeability is a property which implies Backes' linkability 16:09:22 so I started thinking about what we really want out of a linkability definition 16:09:30 (you know all this but I'm bringing the audience up to speed so to speak) 16:09:40 (well not all) 16:10:15 so, these ring signatures can be seen as ZK arguments of knowledge of discrete logarithms, and ZK proofs usually have two properties of interest, correctness and soundness 16:10:46 (and zk) 16:10:55 yeah, other than the zk part 16:11:00 soundness is the analog of unforgeability, but soundness, strictly speaking, means that if an algorithm A can produce valid proofs, then an algorithm E can extract the witness 16:12:02 so, we were struggling with linkability, in part, for a few reasons. you may recall my thinking of some condition to capture linkability like like Link(Sign(m, R, x), Sign(m', R', x)) = 1 for any messages m and m' and any rings R and R' such that the public key for x is in their intersection 16:12:17 you pointed out that we can't assume valid signatures come from Sign, which led us down the rabbit hole of unforgeability 16:12:43 and recall that the Link condition in Backes' is comparing against some signing oracle generated signature 16:12:53 Right, and in particular the original LSAG work assumed for linkability and unframeability that we're looking at valid signature from Sign 16:13:07 Not for Backes 16:13:22 Backes just assumes you output a claimed signature 16:13:42 right, my bad 16:13:54 but the earlier work assumes valid sigs from the oracle 16:14:40 now, late last week, I wrote a proof that the key image for a valid ring signature must, except with negl probability, correspond to a ring member, and since our definition of unforgeability demands it, this means that a valid signature (assuming signatures are unforgeable) will either be honestly generated or will come equipped with a key image that corresponds to a ring member known by the signer 16:15:03 right 16:16:32 now, the trouble was asking ourselves whether the key image corresponded to the "right" signer 16:17:04 but both of us sort of scratched our heads about how to deal with formalizing the signer; one thing I was concerned about was demonstrating that you can't publish a key image for one linking key but open the commitments for some other key 16:17:20 the solution is in the extractor that must exist if soundness/unforgeability holds 16:18:20 that is: since valid signatures definitely produce good key images corresponding to a ring member (assuming the signature scheme is unforgeable), the rest of linkability ensures that you can't extract a witness that is not consistent with the key image! 16:18:31 does this make sense? 16:18:54 i'm still trying to formalize both the statement and the proof 16:19:14 but this is basically what linkability in linkable ring signatures is: if link(sig1, sig2) = 1, then the witnesses extracted from each signature have to be mutually consistent 16:19:32 What does "mutually consistent" mean in this case? 16:19:44 you cant' extract two distinct witnesses if link = 1 16:19:47 i think 16:19:55 but it's delicate, and that's the remainder of the work i have on this definition 16:19:56 :P 16:20:46 bonus points, though: our definition of unforgeability demonstrates that basically every definition of linkability so far is useless * although i really want to caveat this to say it'd be impossible for me, a single person, to read every linkable ring signature paper that's ever been published and check 16:21:49 but we knew that last week 16:21:56 Well, the definitions that assume honest signatures are not very practical 16:22:13 Backes is interesting but also covers only the case where you can produce "too many" valid non-linking signatures 16:22:23 However, it does away with the honest-signature requirement 16:22:29 It's a really tricky thing to manage 16:22:49 backes' is actually fine for cryptocurrency if each key = 1 atomic unit of money and to send 100,000 units, you need to construct a batch signature from 100,000 signatuers. 16:22:51 However, what's useful is that our current construction is _at least_ as good as that used for LSAG/MLSAG, and I argue a bit better because of Backes 16:23:20 but if keys are not equivalently valued, then backes' definition allows someone to pull a switcheroo that is unacceptable for double spend protectin 16:24:47 (note: this means the proof would not catch this, not that it's practically possible with the construction) 16:26:55 So it sounds like what you want to do is assert that two claimed signatures with identical key images must yield the same extracted secret key 16:32:19 well, we can only claim they have the same extracted aggregate secret key 16:32:22 i... made a diagram 16:32:25 * suraeNoether looks around 16:32:26 hey kid 16:32:27 wanna... 16:32:31 wanna see a diagram? 16:32:39 Sure, but claiming the same extracted aggregate secret key is fine 16:35:36 since that implies knowledge of the underlying constituent keys with high probability 16:37:23 https://usercontent.irccloud-cdn.com/file/XhGLZEMY/diag.jpg 16:37:55 the proof isn't completed yet, but this is the basic idea, yeah 16:38:13 SK = secret key space, PK = public key space, KI = key image space, A*K = aggregated * key space 16:38:44 ya 16:38:46 I think we'll be able to use the fact that mu depends on I 16:42:58 We can force mu to depend on the individual round indices (we don't right now) 16:43:09 it's a computation cost, but not too bad given the ring sizes 16:43:25 It's a trivial change in the code 16:44:32 But that may not be necessary, since the unforge proof rewinds already use the round indexing 16:44:55 (it'd be nice to avoid it, to speed up the operations) 16:47:42 what do you mean round indices? 16:49:40 I mean that for each public key set input into the hash to obtain challenges, the aggregation coefficient `mu` can be indexed 16:49:50 We originally looked into this as an option 16:58:15 ohhhh i see what you mean 16:58:40 Yeah, very early on, we looked at two constructions: one with fixed mu, and one with indexed mu 16:58:58 Current proofs work with a fixed mu, which is good for efficiency 16:59:19 I couldn't find the timing differences in the C++ implementation, so I'm running them again now for fun 17:00:07 but if indexed mu is helpful for this extraction (versus using only the indices you get from the rewinding process), we could use it 17:12:30 Is koe here? 17:31:23 yo 17:33:11 The part of your MoJoin construction surrounding range proofs is a bit unclear 17:33:32 Yes since idk about bulletproofs yet 17:33:42 based on your doc it will take extra rounds 17:33:50 The way it works is that each output to be aggregated into the range proof is indexed 17:34:08 Each player generates the first round partial proof and send the partial proof elements to other players (or to a dealer) 17:34:17 They all generate an aggregate challenge and send it to each other 17:34:30 Then they use the challenge to generate the second round partial proofs and distribute those 17:34:41 Generate another set of aggregate challenges, distribute those 17:35:02 and finally perform the last part of the proof (which can then be compressed using the logarithmic inner product technique by any player) 17:35:24 It's a necessarily multi-round interactive process that isn't as simple as generating individual range proofs and then smushing them together 17:35:54 You don't strictly need a dealer, but do need a way to index the outputs and get partial proofs and challenges back and forth 17:36:02 Ok ill put together the most efficient way to do that 17:36:45 In my writeup, you could remove the dealer but still need the bulletproof stages to be present 17:36:46 thanks :) 17:37:39 I wonder if the BP rounds could be done simultaneously with other rounds safely 17:38:09 The challenges include the output commitments themselves, so those need to be communicated along with the first partial proof elements 17:38:16 since you can generate a new transaction public key for each attempted MoJoin, there is no risk to sending output commitments early on, so it should be able to do range proofs with only 1 or 2 extra rounds 17:39:21 And only player needs to do the final inner product compression (there's no secret data at that point) 17:39:25 *only one player 17:39:58 It's possible, but more complex, to have players do it themselves individually 17:40:16 if you already have a communication channel and want to minimize complexity, having a designated player do it is far easier 17:41:42 "It's possible, but more complex, to have players do it themselves individually" is it not deterministic? 17:43:19 It is, but means there's way more communication 17:43:47 And for this use case there's really no need to do it that way 17:43:56 yeah pretty low risk 17:44:01 No, zero risk 17:44:17 The designated player can't extract any information from the non-compressed data 17:44:25 since all players must be actively communicating anyway, if the designated player disconnects then the whole thing is borked anyway 17:44:42 The "downside" is the players communicate more data, but since that isn't stored on chain, it's not really relevant 17:45:33 the designated player would probably act as the indexer anyway 17:46:08 The indices determine where in the aggregated proof each output "lives" (in terms of particular exponent choices when computing the partial proofs) 17:46:12 nah just index based on lexicographic sorting of public keys (interpret as integers), and lowest index is automagically the designated player 17:46:24 Sure, it can be done however you want 17:47:03 There's no way to do it maliciously (the resulting proof simply wouldn't verify, and players would catch this) 17:47:09 how does the normal implementation choose indices? is there a risk of leaking the prover's nature via index selection? 17:47:41 You mean with the current single-player aggregation? 17:47:47 yeah 17:48:14 I'm not sure if it's lexicographical or based on some other on-chain appearance ordering 17:48:24 the proving system doesn't care, FWIW 17:48:41 are verifiers aware of the indices? 17:49:07 They're aware of the ordering of commitments into the verification routine, yes 17:49:11 which corresponds to indexing 17:49:39 ok so that needs to match between all implementations to avoid fingerprinting 17:49:45 Yes, it should 17:50:46 Aside from sorting, there isn't a good reason not to use lexicographic 17:51:07 It might already be done this way; I don't recall 17:52:20 sorted or random are both good 17:53:23 Sorted is nice because it's globally deterministic 17:53:46 Here's a simple example of the partial proof and aggregation methods: https://github.com/SarangNoether/skunkworks/tree/pybullet-mpc/pybullet 17:54:08 It shows how the final inner product compression works with the partial proof rounds 17:54:37 and how the aggregate challenges are formed (it's via simple addition, necessarily) 17:55:06 but this particular test doesn't assume any particular ordering (it'd be offloaded to the tx protocol) 17:56:17 ok I see these test cases 17:57:02 Hopefully it's clear how the dealer could be replaced by many-to-many communication 17:57:15 (in this example, the test suite is the dealer, who is not necessarily a player) 17:57:58 But notably, the trust in the dealer also arises because unless all players receive all partial proof shares, they can't independently verify the F-S challenges provided by the dealer 17:58:20 This technically breaks SHVZK, but still retains witness indistinguishability even if the dealer attempts to generate a malicious challenge 17:59:39 Or rather, it doesn't break SHVZK, but means it can't strictly apply anymore 18:00:21 so long as the dealer can't extract the committed amounts 18:02:38 they can't 18:02:51 but it's an irritating technicality 18:03:18 And again, this doesn't come up at all if every partial proof element is many-to-many communicated and each player builds the challenges themselves 18:05:03 Having read the original MoJoin idea from that markdown, did you come across any particular issues with it, aside from the dealer learning the input-output mapping? 18:05:21 (that mapping leak is obviously not ideal) 18:05:38 ^ koe 18:06:14 iirc there are some transaction details missing 18:09:56 for example fees 18:10:13 cant make output commitments without knowing fees 18:13:24 Yes, that wasn't addressed 18:13:32 but is easy to include 18:13:39 also your construction seems to assume output commitment masks will be encoded and put in tx-extra like they used to be; now they are a hash of the shared secret 18:15:05 thats why I was using the pseudo output commitment 18:15:21 Yeah, I specifically assumed separate tx keys per output 18:15:41 Since there had been discussion about whether that would be worth it (beyond MoJoin specifically) 18:17:03 oh maybe I misunderstood; the output index is just for the hash like normally 18:19:18 I think one particular meta-issue to address (which in part is why MoJoin never really took off after the first informal write-up) was what should be considered the maximum communication complexity that should be reasonably considered 18:19:44 At some point, a particular join protocol could be so complex as to be almost unusable unless fully automated in near-real-time 18:20:18 MLSAG can only be signed after bulletproof is complete, since the message includes the bulletproof 18:21:23 well all join protocols should be automated, since what kind of UX is manual joining? 18:21:33 goes for multisig as well 18:22:04 For sure, but it's a design consideration 18:22:32 rather than verifying the masks are zero, dave just needs to verify amounts balance 18:22:37 If some tool requires you to paste in stuff from other channels for every round, it's unworkable :) 18:22:50 yes for sure 18:24:01 If you can work on the assumption that communication is fully automated and interactive in near-real-time, then design choices like removing the BP dealer go away 18:24:12 Dave needs to send each player all the MLSAG ring offset lists, and the key images, since MLSAG signs those as well 18:24:23 Replace it by global ordering and per-player challenge computation, and bam, you get full SHVZK etc. 18:26:26 basically everything in a tx except the MLSAG itself is signed by the MLSAG, so each player must learn everything 18:27:49 I see what you mean about complexity, since the dealer reduces how much work it is to implement 18:28:12 Let's play around with this for a second... suppose the bulletproofs themselves are removed entirely from the signature; what happens then 18:28:28 you get what I sent you 18:28:34 or the draft* 18:28:51 No, I mean from a security perspective, considering two versions of MLSAG signing 18:28:58 one that includes the proofs, and the other that doesn't 18:29:16 They aren't part of the MLSAG public statement 18:29:26 oh ok 18:29:34 This is just a thought experiment 18:30:25 can you tamper with a bulletproof such that it still verifies? that's the real question I think 18:30:26 It does mean that pruning them removes the ability to verify signatures, of course 18:30:45 No 18:31:06 Not without knowledge of the commitment data, and even then not in a way that breaks soundness 18:31:11 and correctness 18:32:16 if they are not signed, then pruning them will not affect signature verification ^ 18:32:31 exactly, that's what I meant 18:33:04 The only things that _must_ be included in MLSAG hash messages are those elements that are part of the MLSAG public statement 18:33:23 of which the range proof is obviously not 18:33:39 you can prune bulletproofs anyway, since the message is m = H(H(tx pref ix), H(ss), H(range proofs)) 18:36:16 what do you mean by public statement? 18:37:24 A minor misuse of language... in the language of protocols using challenges, proof statements (for which you want to prove knowledge of a corresponding secret witness) must be included as inputs to challenge generation 18:37:45 to avoid the prover substituting a new part of the statement without affecting the challenge 18:38:14 Roughly speaking, if it's not a secret and it goes into the proof, it should go into the challenge hash 18:38:43 ah ok, we do use key prefixing 18:39:15 If you're picky, you also should include public parameters like fixed generators... but if those are already globally fixed and unchangeable, you can in practice get away with not including them 18:39:25 (e.g. generator G, BP generators, etc.) 18:41:07 Yeah, and auxiliary non-proof data (like a range proof) can be safely excluded (but maybe you need it for some higher-level protocol) 18:41:35 btw I have a citation and note that says 'recent research suggests key prefixing isn't necessary'; should I remove this? "Optimal security proofs for signatures from identification schemes" is the paper cited 18:41:56 Let me find the source on that 18:46:25 I think it's safe to note "isn't necessary when considering standard Schnorr signatures" 18:46:51 I would not be comfortable removing prefixing 18:46:56 and it would be tough to justify 18:47:35 would be even safer to say "may not be necessary" since the context is important there 18:48:25 FWIW the standards all still require prefixing 18:49:18 This issue in fact arose with another project that was working on large anon sets and was concerned about the efficiency of large prefixes 18:49:53 A way around that (if you use fixed sets) is to cache a hash of them in some global ordering and then prefix the single hash 18:50:37 I assume that Monero would do this if switching protocols someday 18:51:23 ok :) 18:53:17 anyway, sidetrack lol 18:53:21 I suppose that's a bit of a sidetrack 18:53:22 heh yep 18:53:34 It just popped into my head since it's a practical concern 18:55:12 from what Im aware, most of the MLSAG message is there to prevent tampering; my guess is it's 'all the data' since that is most straightforward, and there is no obvious reason to exclude some 18:56:38 Any public data used by the verifier 18:57:14 and any identifying data from another higher-level protocol if there's a need to tie the signature to something else 18:57:23 also the tx_extra 18:57:39 Right, that's what I mean 18:57:50 ah 18:58:11 The whole public-parameter F-S thing assumes the protocol is used on its own 18:58:22 You typically pass in other data if you embed it elsewhere 19:00:50 right 19:01:02 Anyway, I'm glad you've taken up the MoJoin stuff since it didn't go anywhere 19:01:48 It was certainly deprioritized for other research (and hence very incomplete) 19:02:56 it's pretty interesting, especially since it can leverage LSAG and SAG 19:03:32 and there aren't many other options for the horrible heuristics around miners, pools, exchanges, and so on 19:04:10 I could see any implementation leading to misunderstanding about the nature of "mixing" in Monero (which already exists) 19:04:27 I wonder if SAG is used in the wild anywhere else 19:04:33 (the misunderstanding exists, not mixing...) 19:05:02 i put on my list to deprecate the word 'mixing' :p 19:05:17 There are some 1-of-many proofs used elsewhere 19:05:29 Groth built a Zerocoin implementation out of it that Zcoin uses 19:05:41 it's not the Liu style construction, though 19:05:52 but rather the one used by Lelantus and Triptych 19:07:25 One meta-issue that came to mind was to consider the case that any join construction simply isn't used in practice due to incentives around ease of use 19:08:17 since it's opt-in and necessarily has some level of interaction (several rounds of it...) 19:09:04 An incentive could be fees. Smaller tx, good batching, so fees could be made to be cheaper for those. 19:09:26 Or dearer for others :) 19:11:55 You mean by their construction, right? Not because the network could identify them, of course 19:11:59 (that would ruin the purpose) 19:12:17 They have loads of inputs and outputs. 19:12:27 yes 19:12:35 I expect initial versions wouldn't have much use since it takes a while to build up fully automated versions 19:13:00 Right, but I think it's an important design consideration not to base system-wide privacy on an assumption about an opt-in solution 19:13:04 First the basic capability, then semi-automated, then fully automated 19:13:05 (plenty of examples where that's a bad idea) 19:15:01 I see what you mean, and agree that join solution should only supplement, and research should continue into improving the situation at a protocol level 19:16:07 Yeah 19:16:51 If there are better ways to address pools, exchanges, etc. than currently exist, and can be handled at the protocol level, that's probably a better place to devote attention initially 19:17:39 But I'm glad there's still interest in the other stuff (like MoJoin) too 19:18:06 and improvements to it (the dealer requirement was always considered suboptimal) 19:18:54 it would really help to know just how bad the heuristics are as a function of ring size, so it's great suraeNoether is working on this 19:19:00 for sure 19:19:31 At least to address the types of heuristics we can conceive of 19:20:34 What's the Schneier line? Attacks never get worse; they only get better 19:20:38 (from the adversarial perspective!) 19:29:00 based on what you told me regarding aggregate proofs, players need to send 5 messages (with one additional message from the compressing member): partial proof A, aggregate challenge component A, partial proof B, aggregate challenge component B, proof completion C. Is that accurate, or are the aggregate challenges things they may compute privately? 19:31:01 If all players receive each others' partial proofs, they can use the collection to compute the challenges 19:31:22 Otherwise this is done by the dealer if there is one 19:31:45 There would also need to be an initial message step to determine the indices each player will use 19:32:14 right, so then just 3 messages prior to compression in the n-way channel protocol 19:32:40 Yep, A-proofs, B-proofs, C-proofs 19:32:49 and then the designated player can do the compression 19:32:56 (as can any player who has the same information) 19:33:23 There's no particular reason other players need to do the compression to test anything, once the challenge phases are done 19:33:32 Either the compressed final proof will verify, or it won't 19:34:01 Any successful attempt to game the compression would be either a failed verification or a break in the security model 19:37:03 ok to reiterate one last time, is the compression something that MUST be communicated to other players? i.e. it's not something they may compute privately and never send a message about? 19:37:46 or if it is something that can be computed privately, is it with prerequisite of more additional prior information (random scalars?) 19:38:35 I don't follow 19:39:16 The final proof consists of aggregated versions of the A-, B-, C-proofs, some of which are compressed via the inner product method 19:39:38 Im trying to minimize how much information gets sent to the channel, so if things can be done privately then they should be 19:39:54 Once the compression happens, that produces the final proof 19:40:07 If players need to use that proof in some kind of signature, they'd need to have it 19:40:17 But it's a valid proof on its own 19:40:32 No secret data is used to compress 19:41:24 What it does mean is that the C-proofs could be sent only to the compressing player 19:41:32 Is that what you meant? 19:41:53 Because the only reason all players need partial proofs is to compute aggregate challenges 19:42:06 Im a bit confused on the necessity for a compressing player, which seems to imply they are doing something the other players cant do without additional communication 19:42:36 I'll give some background on the compression that might help 19:42:48 It's possible to do a non-compressed Bulletproof with the same security properties 19:43:03 the size scaling is linear and therefore poor 19:43:39 But you can take some of the proof and apply a particular kind of inner product compression... what's clever about it is that the compression doesn't use secret data 19:44:25 Since we require the compressed bulletproofs (for the size scaling), some entity with access to the uncompressed version must do this before using the proof in a transaction 19:44:55 If you already have a single player putting the transaction together (in an untrusted way) for submission to the chain, this player might as well do the bulletproof compression 19:45:38 This turns a many-to-many round (of the C-proofs) into a many-to-one round (to the desig. player) 19:46:35 ah ok, in my version all players are constructing the transaction in parallel, which is even less trust than assuming some individual will properly submit it; since the channel is n-way it's always a many-to-one communication for each round (all n players can decrypt the same data using the n-way shared secret) 19:47:00 OK, in that case they can do many-to-many C-proof communication, and each do the compression 19:47:09 it's deterministic 19:48:09 great! means only 5 total rounds are necessary once the channel is set up 19:49:48 This doesn't assume any challenge communication, right? Just to be clear 19:49:59 Players locally compute challenges once they get all partial proofs for a round 19:50:23 and those are of course deterministic since they're F-S hashes 19:50:39 right 19:52:20 roger 19:52:59 and the commitments themselves need to be communicated at some point before or with the A-proof, of course 19:53:12 as part of the public statement, they're included in the first challenge computation 19:56:41 yeah the messages all seem random but it fits together sort of nicely 19:59:25 Heh, as long as all the data get to the right place in the right order... 19:59:50 It's kinda fun to build efficient round communication like that, trying to piece things together 19:59:54 a cool problem 20:02:01 whew n-channel is done, on to dealer section! 20:02:42 neat 20:02:53 Let me know when done; I'm excited to read it 20:10:20 suraeNoether: FWIW the difference in CLSAG 11-ring verification between a fixed `mu` and indexed `mu` (median timings) is 463 us 20:10:42 that's about a 5% increase overall 20:10:57 (2.1 GHz Opteron test machine) 20:11:28 I don't think we will need it 20:12:39 Good; I didn't either! 20:12:45 But was curious nonetheless :D 21:34:10 koe: on page 29 you say "addresses are sent money", which I'm not a fan of 21:34:17 You do clarify about addresses vs outputs 21:34:36 But I wonder if a better way is to say addresses are used to derive one-time addresses associated to outputs 21:34:46 it's a concept progression 21:34:58 since readers start out with a more physical understanding 21:35:08 fair enough 21:35:29 As long as they don't think that addresses are the things that appear on-chain (it's a key difference from other assets as you know) 21:39:10 Also, the whole document could have a single "except with negligible probability" footnote =p 21:39:32 not sure putting it on page 29 is particularly useful compared to elsewhere 21:44:36 true lol, suraeNoether made some comments on the first version about making sure everything was negligible probability 8) 21:44:53 Not a fan of the line talking about notes are like saying "Address C now owns 5.3 XMR" 21:45:19 I think that introduction muddies the waters about the relationship between addresses and outputs 21:45:24 even for beginners 21:46:13 The one-way relationship between addresses and outputs is a key (pun intended) component of recipient ambiguity 21:49:40 I think it's important to frame cryptocurrency in the language of ownership, since that directly parallels how physical money works 21:49:57 the technological aspect merely underpins that narrative 21:50:10 rather than takes the center stage 21:50:37 Right, and I like you mention the idea of spend authority 21:50:46 I think that's the way to look at Monero's address-output relationship 21:51:13 Knowledge of private address information yields spend authority for the outputs generated from those addresses 21:52:06 Perhaps a diagram showing the relationship between public address info, private address info, output one-time address, and spend authority 21:52:07 ? 21:52:35 the problem is you have to start the story without knowledge of what addresses literally are 21:52:46 or at least that's how I went about it 21:53:00 hmm 21:53:05 by the end of section 4.2 the meaning is fully developed 21:53:10 Is there a good real-world analogy? 21:53:18 (to the address-output idea, I mean) 21:53:39 sure, like a safe deposit box 21:53:43 whoever has the key can open it 21:55:37 I could just say the 'address-holder' owns the output, rather than the address itself owning them 21:56:11 and 'the holder of address C may now spend 5.3 XMR' 21:56:11 FWIW I don't know a great way to explain this using simple analogies... and you can of course explain however you like 21:57:47 but I like thinking that the address itself owns outputs, and whoever has the key is just accessing that spend-right 21:57:52 Or maybe even finding some way to state that the intent of the note is to say "address C controls 5.3 XMR" while not publicly listing C or 5.3 21:58:09 and then explaining, as you do, how the hiding works 21:59:07 well the essential message of a transaction is explicitly address C and 5.3 XMR, while the cryptographic techniques hide this information from certain kinds of observers 21:59:12 Yeah, you can link from the original idea of note to saying that the goal of the protocol is to obscure the address and the amount... that's building from the existing Bitcoin-like structure to the Monero-like structure 21:59:39 Right, so perhaps being clear at the start that the Monero protocol goal is specifically to hide these things, making notes more indistinguishable 21:59:55 Otherwise the wording sort of makes it sound like plaintext notes is how Monero works 22:00:02 and I think it's best to dispel that notion right away 22:00:49 well that concept is introduced in the abstract and first chapter, so readers will already know what they are aiming at 22:01:25 the final paragraph of pg29 ties in with that previous concept 22:02:30 it's fine if readers go 'wait a minute, what about amount hiding' and then 'ah here we go'