00:25:36 <Isthmus> What was the characteristic of transactions that revealed whether (a) all outputs were sent to primary addresses or (b) one or more outputs was to a sub address?
00:25:48 <Isthmus> Was it some field in tx_extra?
00:26:21 <moneromooo> Yes. Whether the extra tx keys field is present.
00:26:58 <moneromooo> BUT if it's just one subaddress, it's not present and the main tx key is used.
00:27:32 <moneromooo> So the distinguishability only occurs for txes with > 2 outputs.
00:27:48 * Isthmus updates notes
00:27:51 <moneromooo> And there's some slight space wastage for these.
00:28:06 <Isthmus> What do you mean?
00:28:58 <moneromooo> Either more data than needed, or being thrown out the airlock. You get too choose the one you prefer :)
00:31:49 <Isthmus> Oh do you mean we could theoretically use the main key for one of them, and include N-1 extra keys?
00:34:13 <moneromooo> Yes, or remove the main key.
15:58:55 <sarang> Research meeting here at 17:00 UTC (about one hour from now)
16:08:53 <suraeNoether> good morning everyone
16:10:30 <sarang> hey
16:12:35 <sarang> Happy Festivus to everyone
16:34:04 * suraeNoether puts up aluminum pole
16:34:06 <suraeNoether> who has grievances
16:34:22 <moneromooo> Who doesn't.
16:36:37 <sarang> Until you pin me, suraeNoether, Festivus is not over
16:37:35 <suraeNoether> sarang instead of calling CLSAG concise or compact or any of the other great suggestions folks have mentioned, i think we should avoid giving it a name in the paper and rename the paper "Ring signature size reduction by key aggregation" or something boring
16:37:59 <suraeNoether> we can call it clsag in our code, who cares
16:38:06 <suraeNoether> but the reviewers are going to be annoying i can tell
16:40:22 <sarang> We could do that
16:40:36 <sarang> Just say we're giving a construction of a d-LRS
16:40:55 <sarang> since really the idea of d-LRS is what we're producing
16:41:31 <sarang> Key-aggregated linkable ring signatures and applications
16:42:46 <sarang> It'll make the narrative more verbose: s/CLSAG/our new signature construction/
16:43:39 <suraeNoether> ehmmmm maybe. don't make any changes yet
16:43:45 <suraeNoether> i'm going to be reading
16:43:53 <sarang> I won't make any changes
16:44:15 <sarang> IMO the name is not that big of a deal
16:44:24 <sarang> If anything, maybe just change the title
16:45:08 <sarang> and/or remove the CLSAG naming from the abstract in favor of simply saying that we produce such a construction that gives better size efficiency and (for some ring sizes) better verification times
16:45:41 <sarang> I'll make a review comment in Overleaf for this, so we keep it in mind
16:45:48 <suraeNoether> better over naive methods that also haven't ever really been proposed before :\ heh
16:46:09 <suraeNoether> except in ringct
16:46:16 <sarang> Better than methods currently in production that don't use trusted setup
16:48:56 <moneromooo> "Thanks to the helpful comments from our esteemed reviewers, we rename our construction to Cranky LSAG"
16:50:18 <sarang> Cool LSAG
16:50:54 <sarang> Or recursively define the "C" in CLSAG to stand for "CLSAG"
16:58:25 <suraeNoether> Research meeting beginning in here in 2 minutes
16:58:57 <suraeNoether> although we'll stretch the intro greetings to catch stragglers
17:00:51 <suraeNoether> allright, everyone, welcome to the MRL weekly research meeting
17:00:57 <sarang> Hello
17:01:00 <sarang> Happy Festivus!
17:01:01 <sgp_> hello
17:01:03 <suraeNoether> agenda is here: https://github.com/monero-project/meta/issues/422
17:01:10 <suraeNoether> we'll start with GREETINGS. hiya!
17:01:41 <suraeNoether> mele kalikimaka, etc
17:02:34 <suraeNoether> let's move along to the ROUNTABLE
17:02:54 <suraeNoether> i know isthmus has been up to some interesting stuff with block sizes and fees, but he doesn't appear to be here. sarang, as usual, has been busy. you want to start, sarang?
17:03:24 <sarang> Sure
17:03:45 <sarang> I redid the CLSAG linkability and non-frameability definitions, theorems, and proofs
17:04:07 <sarang> and then did a major reorganization of the preprint for clarity and style/format
17:04:21 <sarang> It's ready for suraeNoether's review, and then posting
17:05:10 <sarang> Additionally, the Triptych preprint draft is ready for suraeNoether to review as well
17:05:15 <sarang> and then it can be posted
17:05:31 <sarang> good times
17:05:39 <suraeNoether> word, word
17:05:44 <suraeNoether> does anyone have any questions for sarang?
17:06:55 <sarang> Apparently not!
17:06:58 <mikerah[m]> I have a question for the MRL team regarding L2 scaling for Monero: Are there any scalability solutions currently deployed on Monero? If not, why not?
17:07:14 <sarang> I assume you mean off-chain?
17:07:24 <mikerah[m]> I do mean off-chain
17:07:30 <suraeNoether> not currently deployed. DLSAG and thring signatures are two fundamental pieces of off-chain scaling
17:07:45 <suraeNoether> DLSAG is currently... uhm... accepted for publication? did iirc?
17:07:52 <sarang> Accepted to FC2020
17:08:00 <suraeNoether> that's a spicy meatball, yes
17:08:02 <sarang> Awaiting some likely rewrites for definitions
17:08:31 <sarang> Downside is that indistinguishable refund-compatible transactions don't play nicely with key image requirements
17:08:36 <suraeNoether> mikerah[m]: requires some more research into how to ensure consistency in key image use
17:08:42 <suraeNoether> ^
17:09:29 <mikerah[m]> So, the current state of the art for monero is DLSAG, thring signatures and the Tari sidechain?
17:09:42 <suraeNoether> tari sidechain is independent
17:09:45 <sarang> Tari is a separate project
17:09:54 <suraeNoether> but built on top of monero, from my understanding
17:10:00 <sarang> No
17:10:06 <suraeNoether> er... sidechain
17:10:15 <suraeNoether> not *on top of*
17:10:16 <sarang> IIRC they're doing a MW-based implementation
17:10:19 <suraeNoether> oh
17:10:24 <suraeNoether> news to me *shrug*
17:10:32 <sarang> Hoping to do merge mining
17:10:46 <sarang> But I have not been following their recent work
17:10:49 <suraeNoether> ah
17:10:54 <mikerah[m]> <suraeNoether "news to me *shrug*"> Me too. I guess the association to fluffypony made me assume that it was Monero related
17:11:25 <suraeNoether> well, for my part of the roundtable, my work this week was to start copy-editing triptych and clsag, and to work on my matching simulations. I just made a push this morning... https://github.com/b-g-goodell/mrl-skunkworks/tree/matching-buttercup/Matching
17:11:47 <suraeNoether> anyone can run tracing.py and it will create a data folder, stash human-readable simulated monero transcripts inside...
17:11:54 <sarang> mikerah[m]: to be clear, DLSAG is not deployed anywhere
17:12:35 <mikerah[m]> <sarang "mikerah: to be clear, DLSAG is n"> Thanks for the clarification.
17:12:48 <suraeNoether> these transcripts say things like "Alice sends key NODE_ID with ring members RING_MEMBERS, authorizing the creation of outputs NEW_NODE_ID owned by Bob." It's a "ground truth" ledger.
17:13:22 <suraeNoether> these transcripts also contain the accusations that Eve makes. "Eve thinks ring signature NODE_ID belongs to Bob. In actuality, it belongs to Alice." sort of thing
17:13:41 <suraeNoether> in theory, anyone can fire up tracing.py, tweak the parameters inside, and see the simulated ledger
17:13:44 <suraeNoether> the ledger is working just fine
17:13:49 <sarang> nice
17:14:10 <suraeNoether> unfortunately, but also fortunately, once i put these transcripts into human readable format it became immediately obvious there was a problem with my Eve
17:14:27 <suraeNoether> she is allegedly granted knowledge of her part of the graph, but she doesn't incorporate that knowledge into her matching solution appropriately.
17:14:55 <suraeNoether> so the previous numbers i shared in here, which i took care to explain where provisional, are lower than what we can expect from a realistic eve.
17:15:02 <suraeNoether> these problems were not being caught by my unit tests
17:15:05 <sarang> What needs to be done to properly account for that?
17:16:08 <suraeNoether> the run_experiment function in tracing.py builds a dictionary called eve_ownership, which is not utilized correctly, and allegedly deletes spurious ring members, but i have some evidence that this isn't being done correctly either
17:16:32 <suraeNoether> what really needs to happen is that eve builds a sub-ledger by deleting all her known information, so that it's purely "uknown" data to Eve, before playing the matching game
17:16:47 <suraeNoether> that, together with reporting her known information, would fix the problem
17:17:04 <suraeNoether> since i have CLSAG and triptych to take care of, and since so much of this code is human readable at this point, i'm putting this project down until the new year
17:17:41 <suraeNoether> especially since "the problem" is easily explainable and I can point to where it's occuring
17:18:19 <suraeNoether> but, for example, if anyone wants to just simulate a ledger using different stochastic matrices or spendtime distributions, they can tweak the parameters inside of tracing.py and generate as many ledgers as they like
17:18:49 <suraeNoether> and now you can read them like a story. the world's least interesting procedurally generated story.
17:19:28 <suraeNoether> i'll be unavailable for the next 72 hours or so (family is coming into town) but i have CLSAG and triptych printed; i'm about 1/3 of the way marking up my copy of triptych
17:19:49 <suraeNoether> that's all i have today. does anyone have any questions for me about that, or other questions on anything research-y?
17:20:22 <sarang> When you're done with Triptych, will suggestions be added as Overleaf review comments?
17:22:00 <suraeNoether> i was going to add some as comments and send the rest as an email to you
17:22:10 <sarang> Great, thanks
17:22:20 <sarang> You have the line-numbered version?
17:22:59 <suraeNoether> yep
17:23:20 <suraeNoether> okay, let's move onto ACTION ITEMS
17:23:24 <suraeNoether> sarang?
17:23:57 <sarang> I'll be addressing some multisig-related MPC stuff for RCT3 and Omniring
17:24:20 <sarang> Then working on any necessary updates for CLSAG and/or Triptych based on review
17:24:32 <sarang> and then getting both papers posted to IACR
17:25:45 <suraeNoether> Helping sarang finish triptych and clsag; if i finish this before end-of-year, i'll go back to matching
17:28:05 <sarang> Oh, a longer-term action item is to backport the CLSAG security model changes to DLSAG, but that's likely not this week
17:28:31 <sarang> I don't recall the DLSAG reviewers mentioning it, but it should be done anyway
17:28:48 <suraeNoether> allrighty
17:28:53 <suraeNoether> unless anyone has any final quesitons
17:28:59 <suraeNoether> i think we can adjourn
17:29:11 <sarang> Happy Festivus!
17:30:52 <Isthmus> Hai
17:31:01 <sarang> Just in time =p
17:31:38 <Isthmus> I’ll still be working on block sizes and fees
17:32:03 <sarang> Anything in particular of interest?
17:32:55 <Isthmus> I had a lightbulb moment last night for a retrospectively obvious way to subtract txn fees from block payouts. So lll deconvolute the two and report here. Otherwise I’ve been digging a lot into Zcash and finding out that they have a lot of the same problems Monero encounters/Ed
17:33:40 <sarang> Zcash uses a fixed wallet default fee, right?
17:34:03 <sarang> and no particular consensus rules around fees?
17:34:05 <Isthmus> Kinda, it’s implemented in the wallet but not protocol
17:34:09 * Isthmus grumbles
17:34:09 <sarang> right
17:34:36 <Isthmus> Might write a general book about designing private decentralized ledgers from a statistician’s perspective, now that I see the common issues
17:34:37 <sarang> Meaning there's no size/weight dependence, which was pointed out a while back by someone as a possible DoS vector
17:34:44 <sarang> (this was publicly stated already)
17:34:55 <Isthmus> DoS or bloat
17:35:02 <Isthmus> Former has been publicly noted and discussed
17:35:43 <sarang> Yeah, IIRC the idea was to include a bunch of shielded outputs that required nontrivial scanning or something?
17:35:58 <Isthmus> For the DoS, yes
17:36:08 <Isthmus> The miners also accept 0 fee txns
17:36:11 <sarang> roger
17:36:23 <Isthmus> So you can stuff blocks for free up to 2MB/75sec
17:36:59 <sarang> Is that the current block time, or the post-upgrade expected time?
17:37:06 <sarang> Er wait, they already upgraded
17:37:08 <sarang> nvm
17:37:14 <sarang> -_-
17:37:43 <Isthmus> I posted some Zcash plots in #noncesense-research-lab and will probably update them today
17:38:02 <sarang> Are there plans to address this via defaults or consensus rules?
17:39:43 <sarang> Anyway, sorry, I derailed your earlier mention of deconvoluting fees
17:39:47 <Isthmus> I brought it up during a meeting with the ECC and it was on their radar and to do list, but there is not consensus on how to move forward
17:40:20 <Isthmus> Ah fees stuff will be more interesting in a few hours when I generate payout-only plots
17:40:41 <Isthmus> *coinbase-only
17:41:59 <sarang> Nice!
17:42:31 <Isthmus> I think Zcash <> bloat is like early Monero <> Big Bang conversations in that they’re thinking of it as a future scaling problem but it’s literally something I could induce today
17:42:45 <Isthmus> :- /
17:43:05 <Isthmus> This principle will be a chapter in my design book, lol
17:44:23 <sarang> I'm surprised they don't have plans to address, given that the fee structure has DoS capabilities as well
17:44:59 <Isthmus> I think you can’t have fixed fees and a fixed block size
17:45:06 <Isthmus> One or the other (or neither)
17:52:10 <sarang> It's certainly true that given a large enough transaction volume, you couldn't have a fee market anymore
17:52:48 <sarang> How many Zcash blocks have approached the size limit?
17:53:34 <Isthmus> Let’s close out the MRL meeting and reconvene in about an hour? I have a few meetings coming up but will loop back with plots ^_^
17:53:53 <Isthmus> Lots of interesting features and anonymity puddles
17:55:19 <sarang> Oh, the meeting was already closed
17:55:24 <sarang> not that it really matters
18:01:39 <Isthmus> Oh good, I didn't really want to go on the record rambling about preliminary Zcash results anyways.
18:01:53 <sarang> got it
18:02:13 <sarang> Certainly interesting, given all the past discussions about block sizes and fee models
18:12:26 <riceandbeans> What would be an example of something that would be discussed in a meeting?
18:13:52 <sarang> It's just a short time set aside for anyone to share interesting research they've been working on
18:14:00 <sarang> Quite informal
18:14:25 <riceandbeans> I can't really imagine what it would be like though
18:15:12 <sarang> See meeting notes: https://github.com/monero-project/meta/issues/422
18:16:53 <riceandbeans> I didn't understand a single thing reading that :)
18:17:17 <sarang> Happy to answer any particular questions
18:17:24 <riceandbeans> But thank you for giving me an example of what it's like
18:17:33 <riceandbeans> I mean, I would question the whole thing and it would take forever
18:17:47 <riceandbeans> Like what is Triptych
18:18:25 <sarang> A linkable ring signature construction that has good scaling properties
18:18:30 <sarang> still work in progress
18:18:50 <riceandbeans> And what is a linkble ring signture construction :)
18:19:18 <sarang> permits signing on behalf of a non-interactive group, and lets verifiers know whether or not the (unknown) key has signed before
18:22:31 <riceandbeans> The keys in this being tied to hosts running monerod?
18:23:55 <sarang> Keys used in such a signature are previous transaction outputs
18:32:26 <riceandbeans> :\ How often does matrix do that?
18:33:38 <sarang> Reasonably often, it seems
18:44:20 <fluffypony> sarang: you're correct, Tari is MW "on top of" or "on the side of" Monero
18:44:32 <fluffypony> dependent on how you want to view merge-mining + atomic swaps
18:45:22 <sarang> They using ristretto?
18:46:25 <fluffypony> yes
18:46:33 <fluffypony> we had it audited
18:46:48 <fluffypony> https://blog.quarkslab.com/security-audit-of-dalek-libraries.html
18:46:51 <moneromooo> How are you doing atomic swaps ?
18:47:45 <fluffypony> moneromooo: nothing set in stone, as yet
18:47:47 <fluffypony> https://rfc.tari.com/RFC-0151_TransactionProtocol.html
18:47:58 <fluffypony> nothing spectacularly new in the RFC, but there it is
19:03:33 <Inge-> moneromooo: did you see Fireice is working on atomic swaps for Ryo? i.e. cryptonote base layer. But I saw no discussion re privacy implications.
19:06:51 <riceandbeans> What is MW?
19:07:33 <moneromooo> I saw a mention. I'm trying to keep my life fireice free though. Every time I did not, I ended up regretting it.
19:07:45 <moneromooo> MW is mimblewimble.
19:09:01 <riceandbeans> <3 dalek is Rust
19:09:49 <sarang> Yes it is, and well designed
19:10:46 <riceandbeans> I was just reading the link and surfing from there and discovered it.
20:03:42 * Isthmus is back momentarily
20:03:43 <Isthmus> Ok, sorry I got pulled away from the meeting for another meeting
20:04:03 <Isthmus> What was it somebody asked?
20:04:04 * Isthmus scrolls
20:04:39 <Isthmus> Ah yea "@sarang: How many Zcash blocks have approached the size limit?"
20:04:52 <Isthmus> https://usercontent.irccloud-cdn.com/file/283nC7yK/image.png
20:05:38 <Isthmus> There's a stretch from 200000 to 350000 where a bunch of blocks were around the 2 MB limit
20:07:25 <Isthmus> (At the same time of many 2 MB blocks, there signal is weakly echoed at the 1 MB mark, which makes me suspect a pool with something like 10% of the hashrate mining via software that still had the old BTC 1 MB limit hardcoded in.
20:07:29 <Isthmus> )
20:07:41 <Isthmus> *their
20:07:50 <Isthmus> Argh, I need coffee
20:08:05 * Isthmus is afk
20:09:04 <sarang> thanks Isthmus