00:01:43 <koe> Isthmus is your big bang paper published anywhere? I would like to cite it
00:05:48 <koe> In jtgrassie's presentation he mentioned upgrading miner tx to allow multiple outputs. Are miner tx still required to have 1 output?
00:05:59 <koe> jtgrassie
00:08:28 <moneromooo> There was never such a rule.
00:08:55 <moneromooo> They curently happen to have one output, but a two or more ouput coinbase would be accepted just fine.
00:09:24 <koe> ok thanks
00:12:58 <koe> are miner tx limited to 16 outputs like RCTTypeBulletproofsV2?
00:13:04 <moneromooo> No.
00:14:27 <koe> is the miner tx size limited in the same way as normal tx? (sounds like half the penalty-free block size)
00:15:22 <moneromooo> Yes.
00:15:46 <moneromooo> Well, twice the penalty free block size.
00:16:18 <moneromooo> Oh, right, there's that new constraint now. I had forgot. It does not apply to the miner tx.
00:17:01 <koe> so plausibly someone could make a ridiculous block with just a miner tx? i.e. using a TON of outputs
00:17:10 <moneromooo> Yes.
03:52:43 <Isthmus> Hey @koe glad you enjoyed the Konferenco talk! Plenty of Easter eggs in the blockchain/protocol, recently found a whole new set of leaks of for the next monkon :- )
03:53:36 <Isthmus> I’m with family at the moment, but I’ll give the Big Bang paper a final proofread and try to push it out later this week
03:54:09 <Isthmus> (I can also point you towards a draft if it’s time sensitive.)
03:56:45 <Isthmus> Very interesting questions, I hadn’t realized the miner txn had problematic structure edge cases!
03:58:57 <Isthmus> We’ve been looking at miner payout/strategy anomalies over in #noncesense-research-lab (there’s some odd stuff)
04:00:06 <Isthmus> When people deploy software that makes suboptimally selected blocks you can see exactly which blocks they mined (and gave up money on) and how long it took them to catch the error and fix it
04:34:22 <koe> no time sensitivity at all lol, let's call it a miracle if I publish ^.^
04:36:04 <koe> oh interesting, by monitoring the tx pool?
04:39:41 <koe> moneromooo according to check_tx_semantic the max transaction size is m_current_block_cumul_weight_limit - default_blob_size, am I missing something?
05:19:36 <jtgrassie> koe: "In jtgrassie's presentation..." I was IIRC refering to the amount of destinations the code allows for a miner tx. i.e. create_block_template
05:19:46 <jtgrassie> not what consensus allows.
05:21:09 <jtgrassie> I made a patch localy while I was building a p2pool implementation to split a miner tx to multiple recipients and it worked fine.
05:24:45 <jtgrassie> Miner tx as far as consensus goes it basically the same as any other tx. Apart from obviously ensuring it is not generating more XMR than it should!
05:41:42 <koe> thanks :)
05:47:29 <koe> what's the story on CLSAG? will it ever be implemented in any way?
06:11:42 <jtgrassie> Regarding your other question w.r.t. miner tx, a miner tx is not a rct bulletproof tx, so it has no 16 output restriction.
06:18:38 <koe> nvm moneromooo, jtgrassie helped me find get_transaction_weight_limit()
06:22:58 <koe> BTW if anyone knows about random protocol rules that belong in ZtM2 let me know when I'm online. My goal is at least 500 footnotes!
10:05:49 <sarang> CLSAG is ready to go, basically
10:06:07 <sarang> Proofs were being updated
10:07:36 <koe> does that means MLSAGs will be deprecated in 2020?
10:18:01 <sarang> They could be
10:18:56 <koe> In what situation would they not be deprecated?
10:19:37 <sarang> If there are issues found with CLSAG and it isn't deployed for some reason
10:21:00 <koe> It's good to see you guys making such steady progress
10:26:18 <koe> Since v7 there have been: bulletproofs, better commitment format, big bang mitigation, RandomX, better output selection, and better protocol level indistinguishability via >=2 outputs & dummy payment ids & 10block lock.
10:27:55 <koe> and pruning
10:33:36 <koe> What's this RingCT3.0? Future implementation for Monero?
10:35:38 <sarang> It's a tx protocol
10:56:39 <koe> is there a discussion thread regarding the janus attack? very interesting exploit
11:03:02 <selsta> I think the discussion happened on IRC.
11:03:27 <koe> were any decisions made?
11:04:45 <selsta> btw https://monerologs.net might be helpful
11:05:41 <selsta> 12:03 <koe> were any decisions made? <-- did you read https://web.getmonero.org/2019/10/18/subaddress-janus.html ?
11:09:52 <koe> yeah it mentioned encrypting pub key or requiring a schnorr signature
11:10:05 <koe> and that other mitigations were being explored
11:14:36 <sarang> Schnorr proofs will do the trick
11:15:49 <koe> I think you need less than that
11:15:53 <koe> just include rG
11:16:33 <koe> then verify that r*Kv = kv*(ks + Hn(kv,i))*rG
11:21:41 <koe> the interesting decision is what to do about 'bad' outputs, since they contain real Moneroj after all
11:43:06 <koe> any transaction with subaddresses is already exposed as such; all you need to do is add a tx_extra tag for `subaddress_base_tx_public_key' (or just assume the first tx pub key is the subaddy base key), then include rG with the set of tx pub keys corresponding to each output. Subaddy pub keys all use the same r scalar instead of all different ones
11:43:06 <koe> (the way it is currently), but non-subaddy pub keys still use different r scalars.
11:43:59 <koe> my notation is section 5.2-5.3 of ZtM
11:45:39 <koe> in 5.3.1 at the end of step 3 Bob computes the check r*Kv = kv*(ks + Hn(kv,i))*rG
11:47:19 <koe> it's not a protocol level defense, but only requires 32 bytes per transaction that has 1+ subaddy outputs; hell, a wallet could implement this right now
11:56:05 <koe> I think subaddresses and integrated addresses are in a fuzzy spot atm since originally they were not enforced in any way by the protocol, but now all tx have a dummy payment ID
11:58:36 <koe> You could require at the protocol level that there be a 'base tx pub key', and then either no more pub keys or exactly #outputs additional pubkeys
11:59:45 <koe> Without protocol requirements, any solution could be haphazard between all the wallets
12:00:14 <koe> which I'm sure Isthmus would have a heyday with
12:00:43 <koe> but at the same time it means protocol scope creep
12:10:08 <koe> field day*; of course, this implies Bob can use his spend key
12:11:15 <koe> requires*
12:22:47 <koe> how would you make a Schnorr proof without leaking the recipient's address (via guess and check)?
12:33:09 <koe> yeah nvm, just sign the shared secret rKv
16:11:09 <suraeNoether> Reminder: we have a research meeting in about 49 minutes.
16:30:53 <sarang> koe: the Schnorr proof includes the expected public points in the hash challenge as usual, but does not include them as public parameters
16:32:25 <sarang> In your notation, are you assuming the recipient knows the transaction private key `r`?
16:46:58 <Isthmus> @koe "BTW if anyone knows about random protocol rules that belong in ZtM2 let me know when I'm online. My goal is at least 500 footnotes!" How about random things that should be in the protocol? In that case I've got 700 footnotes for you. 🤣
16:47:24 <Isthmus> Ah curses did we lose koe
16:47:52 <sarang> Oh Isthmus, always on about the protocol :)
16:58:05 <sarang> Ah nvm, I see what koe meant by their notation from earlier
17:00:42 <sarang> But I don't think it works if I'm reading it correctly; the recipient assumes one index for the LHS of the equation, but a different index has been used instead
17:01:31 <sarang> suraeNoether: ready to get started?
17:01:47 <suraeNoether> sure thing, buddy
17:01:56 <suraeNoether> welcome everyone, to the last MRL research meeting of the year
17:02:09 <suraeNoether> if i had thought about it, i'd have something more in-depth prepared but it just occurred to me ;P
17:02:17 <suraeNoether> let's start with 1) GREETINGS
17:02:36 <endogenic> o/
17:02:38 <sarang> hi
17:02:49 <suraeNoether> good and you, oh not so bad
17:03:10 <suraeNoether> isthmus was here mere moments ago
17:03:35 <Isthmus> Kind of. Splitting headache. Looking at screen intermittently.
17:03:41 <sarang> yikes
17:03:44 <endogenic> :(
17:04:08 <Isthmus> C'est la vie.
17:04:16 <suraeNoether> okay, well; go away isthmus and come back when you're healthy
17:04:23 <suraeNoether> you'll get us all sick with headaches left and right
17:04:32 <endogenic> i have a headache now
17:04:39 <Isthmus> See, we should just ban headaches at the protocol level
17:04:42 <Isthmus> Not just in the wallet.
17:04:45 <suraeNoether> no your headache now
17:05:10 <suraeNoether> before we move onto 2) ROUNDTABLE I would like to bring up a single administrative issue
17:05:35 <suraeNoether> i would like to propose that we consider switching meeting times; we selected 17 UTC mondays essentially at random about 2 years ago
17:05:36 <sarang> ?
17:05:47 <sarang> What's a preferred time?
17:05:51 <suraeNoether> nowadays, not all of our participants easily are able to attend that time, so often it's just sarang and i
17:06:18 <suraeNoether> so while i don't have a lot of time constraints, i wanted to hear from folks like isthmus who oftentimes have meetings at around the same time
17:06:24 <suraeNoether> and open the room up for general discussion about timing for meetings
17:06:31 <Isthmus> ty
17:06:36 <suraeNoether> i know this is boring, but it's been on my mind for more than a month now
17:06:58 <sarang> Suggestions on a better time?
17:07:09 <endogenic> an hr fro
17:07:09 <Isthmus> I'm normally on Pacific time so Monday 1700 UTC is early and right when I'm getting swamped at the office
17:07:12 <endogenic> m now?
17:07:17 <endogenic> nm
17:07:24 <Isthmus> I'm just here now cuz on holiday & EST
17:07:30 <sarang> How about 18:00 or 19:00 UTC?
17:07:32 <endogenic> Weds?
17:07:38 <Isthmus> Weds at 18 or 19 would be better
17:07:55 <Isthmus> In that case, I think I could block it on my work calendar as a recurring event
17:08:11 <sarang> We could always try a new datetime out and see how it goes
17:08:27 <suraeNoether> i second wednesdays at 18-19 UTC provisionally for the first month of the year just to see how it works out re: participation
17:08:29 <sarang> I make sure the topic bar shows the meeting datetime
17:08:32 <Isthmus> +1
17:08:39 <sarang> OK, Wednesday at 18:00 UTC it is
17:08:51 <Isthmus> Thanks! Will be very helpful for me.
17:09:10 <suraeNoether> okay, neato burrito
17:09:16 <suraeNoether> onto 2) ROUNDTABLE
17:09:52 <suraeNoether> since the holidays were last week, maybe we can make this not just a "here's what I did last week" thing but also a "here's what we did this year" thing, but that could end up being a... surprisingly long list
17:10:04 <suraeNoether> but we don't have to go in-depth
17:10:32 <suraeNoether> sarang or isthmus, do you guys want to begin? wait, no, isthmus: go away and treat your headache
17:10:38 <sarang> I finished up a draft MPC for the aggregated version of RCT3 this past week
17:10:59 <sarang> And am currently in the weeds with some Omniring stuff that has been puzzling
17:11:26 <sarang> Additionally, my funding request is open: https://ccs.getmonero.org/proposals/sarang-2020-q1.html
17:11:35 <suraeNoether> i strongly recommend that everyone donate to sarang's funding request
17:11:44 <suraeNoether> well, i mean, whatever you are comfortable with
17:11:49 <sarang> and I'm on pins and needles for any comments from suraeNoether on CLSAG or Triptych preprint updates
17:12:09 <suraeNoether> what i mean to say is: this is a valuable request, and if you have been considering donating to the CCS but don't know where your money will have a big impact, sarang's fund is a high priority ticket imho
17:12:22 <sarang> Much appreciation for all the support
17:12:51 <sarang> I'm eager to see what the next year holds in the research space, particularly relating to transaction protocols
17:14:21 <Isthmus> Yea, what's our research theme for 2020
17:14:37 <Isthmus> I'll obviously continue to be a huge PITA about information leaks
17:14:46 <sarang> yes plz
17:15:19 <sarang> "2020: zero knowledge, infinite heart"?
17:15:40 <Isthmus> Ring size 2020?
17:15:43 <Isthmus> Oh wait, it's not a prime number
17:16:24 <sarang> People are going to think there's a technical reason for having prime-number ring sizes :/
17:17:04 <sarang> Interestingly, for some protocols, you specifically _can't_ have a prime number size!
17:19:07 <suraeNoether> for any merkle-tree based approach, you have to stick with powers of 2
17:19:28 <suraeNoether> for 2020, a few things i'd like would be a formal protocol specification for a tryptich-based protocol, using ristretto, going down to the nitty gritty details of optimized arithmetic, tor integration, etc
17:22:49 <suraeNoether> thing is, i think we are eventually going to need to abandon the DL setting for efficiency and security reasons; either switching to multilinear pairings may be necessary for efficiency, but still boils down to computational security. on the other hand, switching to other hardness assumptions like RLWE, which are believed to be quantum-secure, is an area of active research. that assumption also has a
17:22:49 <suraeNoether> very different profile for use in cryptocurrencies because key sizes and signature verification speeds are very different in the new setting
17:23:45 <suraeNoether> my roundtable contribution from this past week: i got flu-like symptoms after xmas, so all I could do was sit around and be grumpy, so I ... copy-edited triptych and clsag
17:23:54 <suraeNoether> (best thing to do when grumpy is to grade papers???)
17:24:04 <sarang> Looking forward to your notes on those
17:24:14 <suraeNoether> should be before 3PM today
17:24:22 <sarang> Hooray!
17:24:31 <sarang> It's a Festivus miracle!
17:24:45 <suraeNoether> i'll be switching back to matching simulation stuff literally next year
17:25:07 <suraeNoether> festivus miracles involve being able to use the aluminum pole on your grievances
17:25:54 <endogenic> i dont get that reference but i will google
17:26:16 <sarang> I'll be continuing a deep-dive into some Omniring stuff this week, to determine if an issue I ran into presents a problem with any of the proofs
17:26:48 <Isthmus> My roundtable is still plotting, but should be rendered shortly
17:26:51 <suraeNoether> after recovering from the flu, or whatever i had, though, i have to say: i feel like a million bucks and i'm super excited to finish off triptych today
17:27:03 <suraeNoether> endo and isthmus and sarang can all attest to the number of times per year i say i feel like a million bucks
17:27:20 <Isthmus> :- )
17:27:29 <endogenic> 1/4 times per year so far
17:28:19 <suraeNoether> when the moon hits your eye like a big pizza pie, thatsa N=1
17:28:59 <Isthmus> Ah, here we go
17:29:03 <endogenic> i feel for the transcription translators who do these logs
17:29:51 * Isthmus chuckles
17:29:53 <Isthmus> https://usercontent.irccloud-cdn.com/file/ntGPLKhz/image.png
17:30:11 <Isthmus> ^ non-coinbase TXNs as of late
17:30:17 <suraeNoether> oh my fkn god
17:30:26 <Isthmus> I zoomed in on lower values there, there are some absurd outliers
17:30:27 <Isthmus> https://usercontent.irccloud-cdn.com/file/Uz5uJDlS/image.png
17:30:35 <suraeNoether> so i like the idea of having an adjustable unlock time for smart contract reasons. ...
17:30:57 <endogenic> for m'kids
17:31:01 <suraeNoether> hey, sarang: think the range proof technique for the trigger block height in DLSAG could be janked around to hide *all unlock times*?
17:31:20 <Isthmus> https://usercontent.irccloud-cdn.com/file/xS32XCWP/image.png
17:31:23 <Isthmus> ^ All from the last few months
17:31:29 <Isthmus> Excluding the giant ones
17:31:39 <sarang> I believe it could
17:32:18 <Isthmus> Apparently unlock_time supports both unix timestamps and height... There are 13 transactions that used UNIX time and the rest are height-based
17:32:41 <sarang> unix timestamps? did not know that
17:32:49 <Isthmus> There's one transaction whose outputs will unlock in the year 46000, lol
17:32:54 <suraeNoether> hmmmm
17:33:02 <suraeNoether> i can't think of a good reason to allow unix timestamps
17:33:26 <endogenic> who uses unlock time currently?
17:33:45 <suraeNoether> costs of hiding all unlock times is a new range proof, but that can be batched with bulletproofs... and variable unlock times are desirable for smart contracting...
17:33:55 <Isthmus> @endogenic apparently 8 different sets of people, and they all use it differently
17:33:57 <Isthmus> xD
17:34:05 <endogenic> lol
17:34:06 <suraeNoether> the DLSAG connection is strong with this
17:34:16 <endogenic> surae is one of them
17:34:28 <Isthmus> https://xmrchain.net/search?value=2c2762d8817ea4d1cb667752698f2ff7597a051d433043776945669043d908b5
17:34:28 <Isthmus>   "unlock_time": 1420722551128,
17:34:34 <suraeNoether> i'm *really* bad at monero
17:34:35 <sarang> Not only batched, but aggregated for logarithmic size benefits
17:35:01 <suraeNoether> can anyone think of a good reason to keep unlock time in plaintext?
17:35:17 <endogenic> auditability
17:35:24 <sarang> It's also smaller
17:35:26 <endogenic> forgive me monero gods
17:35:37 <sarang> Otherwise you have to put it into a commitment
17:35:38 <Isthmus> What is the point of unlock time?
17:35:39 <Isthmus> Serious question.
17:35:58 <Isthmus> I need to understand the intended use cases to figure out how we should handle it
17:36:07 <moneromooo> A reason to use UNIX timestamps is to not depend on block time changes.
17:36:16 <endogenic> (unreclaimable) vesting period; force-hodl
17:36:19 <sarang> that's a fair point
17:36:39 <Isthmus> If the unlock time is plaintext, then how can the hodl be forced?
17:36:58 <Isthmus> Erm
17:37:09 <Isthmus> *if is encrypted, how enforced
17:37:29 <sarang> There's a range proof included, showing that the current block height exceeds the committed lock period
17:37:52 <moneromooo> Can't you easily brute force it ?
17:37:56 <sarang> The goal is to reduce heuristics around expected spends
17:37:57 <suraeNoether> endogenic: auditability in this case would be the same security/threat model as our confidential transactions, so that wouldn't reduce our auditability... not to mention, for the folks in the audience, monero balances are guaranteed by the unforgeability property of our signatures; if anyone is capable of cheating the monero system with our confidential transactions, they can also forge signatures with
17:37:57 <suraeNoether> elliptic curves, which breaks a lot more than just monero.
17:38:11 <Isthmus> I second mooo's question
17:38:19 <sarang> moneromooo: the lock time is in a Pedersen commitment
17:38:22 <endogenic> suraeNoether: was joke :)
17:38:23 <sarang> which is perfectly hiding
17:38:24 <suraeNoether> isthmus: early cross-chain swap models require unlock times to elapse to use SPV
17:38:41 <endogenic> but how does recipient easily verify time til unlock isnt ridiculous through only range proof?
17:38:51 <suraeNoether> endogenic: it's a joke, but like a making a math joke in a math class, it's always followed up by a serious discussion of why it's funny. #mathteacherlife
17:38:58 <sarang> That needs to be communicated to the recipient endogenic
17:39:06 <endogenic> suraeNoether: one-up'd
17:39:12 <sarang> The range proof is included at spend time
17:39:15 <sarang> not at output generation time
17:39:25 <Isthmus> Ohhhh
17:39:27 <moneromooo> So a verifier gets a yes/no, and at some point a no becomes a yes.
17:39:31 <suraeNoether> moneromooo: can't brute force due to sarang's observation about perfect hiding
17:39:33 <moneromooo> Right ?
17:39:36 <sarang> not quite
17:39:40 <endogenic> sarang: out of band?
17:40:04 <sarang> When you generate the output, you specify an unlock time commitment, and transfer the plaintext version to the recipient either encrypted or out of band
17:40:06 <moneromooo> I mean, from a verifier's perpective, they will need to either reject a spend, or ok it.
17:40:21 <Isthmus> -_-
17:40:29 <sarang> When the output is spent, a range proof is generated using a particular time offset against the commitment, to show the lock time has been exceeded relative to the current block height
17:40:35 <moneromooo> When they stop getting a verification failure, there's no other reason (currently) other than that, no ?
17:40:46 <moneromooo> Oh. I see. Thanks.
17:40:46 <sarang> The method is a bit unintuitive until you write it out, TBH
17:40:55 <sarang> but it's included in the DLSAG preprint
17:40:55 <moneromooo> er.
17:40:58 <suraeNoether> moneromooo: you wouldn't be able to construct a range proof on [0, ..., N] with time offset -3
17:41:03 <suraeNoether> it wouldn't be a valid proof
17:41:23 <suraeNoether> the trickiness is in realizing how the DLSAG construction actually captures the offset
17:41:31 <moneromooo> So you include the block hash at currnet block then ?
17:41:46 <suraeNoether> let me pull it up
17:41:55 <sarang> But moneromooo, it's important to note that you can't simply brute-force the verification at each successive block until it succeeds
17:42:04 <suraeNoether> for the audience members: https://eprint.iacr.org/2019/595
17:42:06 <moneromooo> OK, that's good enough for me. Thanks.
17:42:06 <sarang> The signer generates the proof once, at spend time
17:42:56 <sarang> There's some subtlety in choosing the offsets and such, to reduce heuristics, but the method makes sense
17:43:13 <suraeNoether> bottom of page 10, left hand column
17:43:32 <sarang> Cost would be replacing plaintext lock times with commitments, and extending bulletproofs to include the lock proof
17:44:16 <suraeNoether> this would be the first step toward "private" smart contracts that depend on dev-selected unlock times
17:45:05 <suraeNoether> in a sense it's more basic than DLSAG, almost an independent component used in DLSAG. it should have occurred to me before that it was basically it's own construction...
17:45:33 <sarang> It is an independent component... you can do DLSAG with plaintext trigger heights
17:45:38 <suraeNoether> *nod*
17:45:41 <sarang> but it's probably a bad idea to do so
17:46:05 <endogenic> i have to step out y'all
17:46:08 <suraeNoether> which means it has its own stand-alone security definitions. in this case, the definitions rely on some adversarially generated blockchain, yadda yadda
17:46:10 <Isthmus> I think that would be worthwhile to switch to unlock time commitments... Right now an adversary can partition (/fingerprint) the blockchain into ~20 different anonymity puddles based on unlock time alone.
17:46:10 <Isthmus> When I first plotted it I was expecting a few Easter eggs, not heuristic info bleeding everywhere.
17:46:21 * Isthmus waves at endo
17:46:38 <endogenic> keep killin it Isthmus 🤜🤛
17:48:06 <suraeNoether> okay, anyone else want to present any research or thoughts at our roundtable?
17:49:02 <moneromooo> If you guys are looking at making unlock time a commitment, maybe this is a good time to look at a possible semantics change for unlock time to ease future things like atomic swaps etc.
17:49:14 <Isthmus> ^ ooooh
17:49:22 <sarang> How so?
17:49:45 <suraeNoether> yeah, please go on
17:49:48 <Isthmus> Ok, my head is figuratively literally splitting in half, so I'mma peace out. Thanks y'all.
17:49:49 <Isthmus> gg
17:50:04 <moneromooo> By... er... thinking of the requirements you know of for atomic swaps etc, and what semantics would best match those.
17:50:29 <sarang> See ya Isthmus; feel better
17:50:39 <sarang> also see ya endogenic
17:50:45 <moneromooo> I'm thinking in particular of the fact monero's unlock_time semantics do not match bitcoin's, and bitcoin's used for more fancy things like atomic swaps.
17:50:55 <sarang> Ah ok
17:51:26 <Isthmus> Oh but before I go, huge shoutout to @n3ptune who curated the data set
17:51:34 <Isthmus> Ok ciao!
17:52:21 <suraeNoether> moneromooo: yeah, we need to nail down specific examples of usual atomic swaps with bitcoin and how the masked unlock times in monero will play with the unmasked lock times in bitcoin...
17:52:22 <suraeNoether> for sure
17:53:07 <suraeNoether> isthm and i are having a video call about it after he feels better. i'll take notes and we'll draft an issue.
17:53:26 <suraeNoether> allrighty, we are coming up on an hour
17:53:35 <sarang> Action items, I suppose?
17:53:40 <suraeNoether> indeed
17:54:41 <suraeNoether> Mine: sending comments to sarang re: triptych and clsag, consulting with isthm about masking unlock times... which maybe we should do over IRC instead of a video call... to make a donation to sarang's funding request...
17:55:26 <sarang> I'll be continuing that Omniring issue, editing CLSAG/Triptych based on suraeNoether's reviews, and a few odds and ends relating to code libraries and MPC
17:56:23 <suraeNoether> okay, my dog is crossing her legs, I have to take her out. >.< does anyone have any last questions?
17:56:29 <sarang> Nay
17:58:10 <sarang> I suppose we can adjourn then
17:58:13 <gingeropolous> when ringsize a bajillion
17:58:19 <sarang> Soon (tm)
17:58:24 <gingeropolous> :)
17:58:40 <sarang> Or the Futurama answer: "Soon enough." "That's not soon enough!"
17:58:57 <sarang> I'll post logs to GitHub shortly
17:59:22 <moneromooo> Oh, do any of (omniring, tryptich, lelantus, rct3) have "free" randomness to hide a message into ?
17:59:22 <sarang> Remember next week's meeting will be on Wednesday (January 8) at 18:00 UTC
18:00:16 <sarang> I haven't specifically checked this, but the use of a Bulletproof-style prover means I expect you could do this with Omniring and RCT3
18:00:28 <sarang> For Lelantus and Triptych, unsure
18:00:51 <sarang> But this is all speculation
18:01:13 <moneromooo> OK. Don't go looking, I just thought about it and got curious, is all.
18:01:31 <sarang> That's a good point, though
18:01:36 <sarang> I hadn't thought about it
18:03:04 <gingeropolous> i agree with moneromooo that if timelocks are to be fiddled with, it would be beneficial to attempt to mimic bitcoins semantics and abilities
18:04:36 * sarang is done fiddling with the topic now
18:11:49 <nioc> it seems that any changes to facilitate atomic swaps should be coordinated with tari as it is my understanding that they are planning to do atomic swaps with monero
18:12:37 <sarang> I should see what they've been up to lately
18:14:50 <moneromooo> pony mentioned it recently, and it turns out they don't know how they'll do it.
18:15:17 <moneromooo> It was on this channel IIRC, if you have logs.
18:15:18 <sarang> It's nontrivial for sure
18:15:29 <sarang> I'll ask on their dev channel
18:15:42 <moneromooo> Is "monero to monero fork" easier btw ?
18:16:30 <sarang> Likely easier, but afaik has not been evaluated for security or other metadata leaks
18:17:16 <moneromooo> The best would be "monero to fiat" ^_^
18:17:54 <sarang> heh
18:18:11 <sarang> DLSAG was intended to permit swaps in a way that preserves safety and indistinguishability
18:19:26 <nioc> sarang: last activity on the tari dev irc channel was Dec 4
18:19:28 <nioc> and it's not like they haven't been communicating
18:38:28 <sarang> So the issue I noticed in Omniring (https://eprint.iacr.org/2019/580) was from the requirement on page 20 (figure 10) to invert `theta`
18:38:46 <sarang> Which, based on the constraint vector construction, contains non-invertible field elements
18:39:43 <sarang> Even if you define such an inverse to be zero as a matter of notation, it means you effectively zero out large portions of the vectors used in equation 3 on page 17, for example
18:39:53 <sarang> and it's unclear what effect this has on the resulting proofs
18:42:05 <sarang> Hopefully one of the authors can shed some light on this, in case it's simply an intended part of the vector inverse notation that carries through correctly in the proofs
19:33:13 <sarang> Hmm, wondering now if a variation of the interactive DL game from Omniring (Theorem A.6) could be useful for the multi-index Triptych soundness proof...
19:33:21 <sarang> They show i-DL is equivalent to standard DL
21:16:51 <sarang> Rats, I don't think that Triptych problem reduces to a variation of i-DL
22:16:44 <sarang> suraeNoether: I updated the multi-index Triptych soundness proof, and I think it works now
22:17:21 <sarang> (note it also means that I updated the proof relation to account for random-weighted sums)
22:17:35 <sarang> I'll take a look at some additional key aggregation for it later
22:37:05 <suraeNoether> That's fantastic; I've been delayed today so my comments will be coming tonight.
22:56:52 <koe> sarang, my bad just do r*Ks = (ks + Hn(kv,i))*rG; the LHS is the subaddy's tx pub key which is vulnerable to the Janus attack; the RHS is the subaddy spend key for index i times the base tx pub key
22:58:36 <koe> when scanning the blockchain you will see an output addressed to spend key Ks^{i} and want to make sure it's the same index key used in r*Ks^{i'}
23:01:52 <sarang> Aye
23:12:47 <koe> I feel like encrypting the private tx pub key would be cheaper than Schnorr, since Schnorr is 64 bytes and a scalar is 32.
23:13:02 <koe> What are the drawbacks?
23:23:05 <sarang> Having looked it over, I don't see any
23:23:25 <sarang> The check is only done when an output is flagged, and it's cheap
23:23:51 <sarang> If Janus has been attempted, the equality check will fail
23:25:57 <sarang> There seemed to be not a lot of support for making mitigations default or mandatory in txs
23:26:08 <sarang> I disagree personally