11:01:09 <selsta> I assume this BP verification speedup also applies to existing transactions? :)
12:32:11 <TheCharlatan> I took a further look at the input timelock rangeproof this morning, and am a bit confused now at the construction. The prover has the original timelock t, his chosen auxiliary time t' and blind y as committed in (t,y) and does a range proof on (t'-t,y). The verifier as the commitment (t,y) and auxiliary time t' and verifies the proof (t'-t,-y). How do the signs between y and -y balance out?
12:35:07 <UkoeHB_> "and verifies the proof (t'-t,-y)" where did -y come from?
12:35:47 <UkoeHB_> Verifier has t' and C(t,y), computes C(t') = t'*H, and verifies range commitment on C(t') - C(t,y)
12:36:28 <TheCharlatan> And isn't that t'*H-t*H-y*G?
12:37:26 <UkoeHB_> sure, P = C(t') - C(t,y) = (t' - t)*H + (-y)*G; the range proof says that the component (t'-t) <= 2^64-1
12:39:20 <UkoeHB_> If we talk about Monero range proofs, the verifier gets C(b,y) = b*H + y*G, sticks it into the bulletproof verifier alongside the bulletproof proof, and it outputs true/false depending on b?<2^64
12:41:37 <UkoeHB_> The prover also uses P = C(t'-t, -y) when they make the bulletproof in the first place
12:45:19 <UkoeHB_> "does a range proof on (t'-t,y)" this looks like your error
13:00:35 <TheCharlatan> I think I got confused because the DLSAG papaer is using k' there in its proof, so RProve(t'-t,k')
13:00:54 <TheCharlatan> but thanks, I think I understand now why it still works out.
13:14:44 <TheCharlatan> mmh, so should that be -k' in the DLSAG paper?
13:15:58 <TheCharlatan> I guess it depends on the commitment you want to do the range proof against.
13:16:21 <UkoeHB_> not sure, haven't looked at the paper
13:27:09 <UkoeHB_> oh I see on page 21 they are making a new commitment for some reason
13:27:24 <UkoeHB_> there are multiple range proofs? why exactly idk
13:31:09 <UkoeHB_> Yeah, I don't see a reason to range proof the original timelock commitment for each output. Only to spend an input do you need a range proof.
13:33:10 <TheCharlatan> I think so too.
13:37:47 <UkoeHB_> Looks like an algebra mistake at the top of pg21, COM(t,k)−COM(t′−t,k′)−t′·H = (k−k′)·G should be C(t,k) + C(t'-k,k') - t'*H = (k + k')*G
13:39:12 <UkoeHB_> which aligns with the sign difference we were talking about
13:40:07 <UkoeHB_> C(t,k) + C(t'-t,k') - t'*H = (k + k')*G where C(t,-k') is the pseudo output commitment
13:42:53 <TheCharlatan> yes, that makes more sense.
13:46:54 <sarang> selsta: yes, it applies retroactively
14:42:45 <sarang> Reminder: meeting today at 17:00 UTC
14:42:48 <sarang> .time
14:42:48 <monerobux> 2020-04-15 - 14:42:48
14:42:53 <sarang> good bot
16:59:18 <sarang> OK, let's get started with the meeting
16:59:28 <sarang> The usual agenda: https://github.com/monero-project/meta/issues/454
16:59:33 <sarang> Logs posted there after the meeting
16:59:39 <sarang> First, GREETINGS
16:59:43 <sarang> Hello
16:59:52 <ArticMine> Hi
16:59:55 <Isthmus> Heya
16:59:57 <UkoeHB_> hi
17:00:42 <binaryFate> hi!
17:01:01 <sarang> I'll wait a couple of minutes for anyone else to arrive
17:03:04 <sgp_> hello
17:03:21 <sarang> All right, on to ROUNDTABLE
17:03:31 <sarang> Who would like to share any research of interest?
17:03:50 <xmrmatterbridge> <cankerwort> Howdy
17:04:11 <UkoeHB_> https://github.com/monero-project/research-lab/issues/73
17:04:28 <UkoeHB_> Research is a big word, but there's an idea
17:06:11 <sarang> It'd be possible for a recipient to miss spendable funds if this value weren't included properly
17:06:34 <binaryFate> is there any potential issue if the sender does not play "nicely" (purposefully fail the scheme) but can nonetheless prove having sent some outputs to the recipient?
17:06:34 <UkoeHB_> same is true for tx pub keys
17:07:05 <Isthmus> If the sender doesn't follow the rules, recipient won't see a message showing receipt of funds.
17:07:14 <Isthmus> So they'd just ask the sender to make a valid transaction
17:07:28 <sarang> Yep
17:07:41 <Isthmus> Really, the sender hurt themselves
17:08:00 <sarang> It's similar to if a sender sent a bad commitment,e tc.
17:08:06 <sarang> (except for the spendability property)
17:08:24 <UkoeHB_> if there is a wallet that doesnt make view tags correctly, it will be a worthless wallet
17:08:28 <Isthmus> Bingo
17:08:29 <UkoeHB_> and quickly get patched
17:08:30 <xmrmatterbridge> <cankerwort> Surely this would be a kind of "fast scan" and if the sender messed it up somehow it would still show up in a normal scan?
17:08:42 <sarang> yes
17:08:42 <binaryFate> They can "DoS" an exchange support easily
17:09:31 <binaryFate> Probably hurt them more than the exchange
17:09:53 <UkoeHB_> yeah cankerwort it would be trivial to have fast/normal scan differentiation; the technique is very simple
17:10:26 <sarang> And wallets don't have to use the method to scan at all if they don't want to
17:11:38 <selsta> how would fast scan work together with supercop EC ASM? would ASM still bring a scanning speedup?
17:12:00 <binaryFate> would there be interesting tradeoff too with a bit more or a bit less than a byte? (changing the 1/256 chance)
17:13:04 <Isthmus> The speedup is huge if you're looking for 1-2 addresses, but marginal if you're scanning for 20,000 transactions, right?
17:13:11 <UkoeHB_> my thought is 1 byte is a very standard size, and going lower gets kinda hacky; more than that I can't imagine meaningful improvement
17:13:11 <Isthmus> *1-2 transactions
17:13:44 <UkoeHB_> which speedup?
17:14:52 <UkoeHB_> if somehow you own 80% of all tx, then yeah the view tag only helps you for (255/256)*.2 of the rest
17:15:03 <xmrmatterbridge> <cankerwort> So a scan under this system would scan (1/256 of all transactions) + (actually relevant transactions) - overlap
17:16:03 <UkoeHB_> right
17:16:17 <UkoeHB_> and 'scan' just means perform a few more ec operations
17:16:22 <UkoeHB_> per output
17:16:33 <UkoeHB_> it's actually 1/256 of all outputs, not tx
17:17:01 <Isthmus> ah yea, ty
17:17:12 <TheCharlatan> why only one byte? Are two bytes too revealing?
17:17:21 <UkoeHB_> diminishing returns
17:17:46 <UkoeHB_> the marginal scan change from 1 byte to 2 byte view tags is tiny
17:18:58 <sarang> OK, noted
17:19:07 <sarang> Any additional questions on this idea at this point?
17:19:34 <UkoeHB_> any objections also?
17:19:48 <Isthmus> I like it
17:19:58 <TheCharlatan> yes :)
17:20:15 <Isthmus> Hopefully this will reduce the "Y MONERO SO SLO TO SYNC" posts on reddit by 1/256 too
17:20:28 <UkoeHB_> one can only dream
17:20:38 <xmrmatterbridge> <cankerwort> I suppose generally speaking the fork when transactions get smaller anyway is a good time to introduce these QoL improvements
17:20:46 <binaryFate> this looks great
17:21:07 <sarang> Well, there doesn't seem to be a plan for whether or not to include Janus mitigations, which have been brought up repeatedly before
17:21:19 <xmrmatterbridge> <cankerwort> or is any reduction in transaction sizes already earmarked for bigger ringsizes?
17:21:34 <sarang> There is currently no concrete plan to increase the ring size with CLSAG
17:22:17 <sarang> Note that the move from MLSAG to CLSAG will reduce the typical 2-2 transaction from 2.5 kB to 1.9 kB in size
17:22:25 <sarang> (absent any other changes)
17:22:58 <UkoeHB_> I think the discussion about Janus and tx extra has made some small progress
17:23:13 <sarang> Sure, but small progress != PR
17:23:14 <sarang> :D
17:24:55 <sarang> Anything else you'd like to discuss UkoeHB_?
17:25:20 <UkoeHB_> dont think so thanks sarang
17:25:26 <sarang> OK thanks UkoeHB_
17:25:40 <sarang> Does anyone else wish to share research of interest?
17:25:56 <sarang> If not, I have a couple of things to share
17:26:03 <Isthmus> Hmm, I’m still working on creating a graph formalism for fungibility defects. Made a little bit of progress since last week, but it’s still not quite coherent. Being rigorous is hard. Hopefully will have something to share in a week or two.
17:26:08 <Isthmus> I’m cooking up some stuff with Insight too. One of the Fellows put together a patch to prevent coinbase underclaiming now that we’ve moved away from discretized outputs. I just looked at the code, will clean it up and submit for consideration/review.
17:26:12 <Isthmus> I want to get more of Insight’s engineers working in our ecosystem! Insigght has been pouring a ton of R & D resources into Polkadot, ICON, Zcash, etc. I really want to leverage my team to contribute to the Monero community at this scale too.
17:26:15 <Isthmus> Having a few internal syncs to match Fellows onto open challenges, based on their skills/passions/interests.  Hopefully in the next week or two, I’ll be introducing new contributors. :- )
17:26:36 <sarang> Nice
17:26:37 <Isthmus> More details coming soon as those conversation proceed
17:26:41 <sarang> What kinds of projects?
17:27:11 <Isthmus> Meeting with the candidates this week to nail that down based on their skillsets
17:27:18 <sarang> got it
17:27:25 * Isthmus hands the mic to sarang for other updates
17:27:27 <xmrmatterbridge> <cankerwort> And now I need to go find out wtf is Polkadot and ICON all evening
17:27:32 <sarang> Thanks Isthmus
17:27:42 <sarang> This PR to speed up Bulletproofs is ready to go: https://github.com/monero-project/monero/pull/6451
17:28:02 <sarang> Applies retroactively, and has some pretty nice improvements
17:28:23 <sarang> Saves 25% on a 64-batch of 2-output proofs
17:28:35 <sarang> Feel free to review if you like
17:28:55 <ArticMine> Excellent
17:28:57 <xmrmatterbridge> <cankerwort> Fantastic news
17:29:03 * binaryFate applause
17:29:22 <sarang> Second, I've been working hard on a Triptych implementation in the codebase, for more accurate real-world testing
17:29:44 <sarang> This is the branch: https://github.com/SarangNoether/monero/tree/triptych
17:29:55 <sarang> (note that this code is not production-ready, and should not be used in anything important)
17:30:21 <sarang> Size data comparison: https://usercontent.irccloud-cdn.com/file/KvolrThG/size.png
17:30:36 <xmrmatterbridge> <cankerwort> Triptych = Tryptych 2? As in did one version supersede the other?
17:30:37 <sarang> Verification timing comparison: https://usercontent.irccloud-cdn.com/file/4CATnXf6/timing.png
17:30:54 <sarang> This is for Triptych, which requires separate proofs per input (much like MLSAG and CLSAG require)
17:31:10 <sarang> The timing plot uses performance test data from this branch
17:31:25 <sarang> The gray lines are centered at the 11-MLSAG point for visual reference
17:31:50 <sarang> The timing data does _not_ include some unfinished optimizations, or batching, or common input sets within the same transactions
17:32:39 <sarang> However, it provides an idea of how MLSAG, CLSAG, and Triptych compare generally
17:33:24 <Isthmus> Noice
17:33:38 <TheCharlatan> what's the gray line intersection with the Triptych line x axis value?
17:34:01 <sarang> The vertical gray line is for ring size 11 across all constructions
17:34:12 <sarang> The horizontal line is the size/time value for MLSAG at ring size 11
17:34:16 <sarang> (again, just for visual reference)
17:34:24 <sarang> To help you compare to what we have in place right now
17:34:28 <ArticMine> What is the impact on tx size
17:35:02 <sarang> Each transaction input (not ring element, spent input) requires a single signature, of whatever construction you prefer
17:36:14 <sarang> Moving from 11-MLSAG to ~32-Triptych would result in no change to signature size
17:36:22 <sarang> and would result in slightly faster verification
17:36:31 <binaryFate> really impressive
17:36:46 <xmrmatterbridge> <cankerwort> These are awesome improvements! But the plan is not to go straight for Triptych right?
17:36:48 <sarang> The size data are final; but again, the verification data is still WIP
17:37:14 <sarang> Triptych (and all other WIP next-gen constructions) require a modification to key images that requires new engineering work for multisig
17:37:20 <sarang> It's very nontrivial
17:37:37 <derpy_bridge> <[keybase] seddd>: sorry 4 late. just finishing review of CLSAG, will send draft report to sarang when done. no big findings :)
17:38:12 <sarang> Thanks seddd, much appreciated
17:39:42 <xmrmatterbridge> <cankerwort> seddd = surae?
17:39:51 <derpy_bridge> <[keybase] seddd>: +1
17:40:14 <derpy_bridge> <[keybase] seddd>: not by a long shot cankerwort
17:40:24 <sarang> Finally, ledger/trezor support for CLSAG is getting finished
17:40:33 <derpy_bridge> <[keybase] seddd>: (surae wayyyy smarter)
17:40:36 <sarang> cslashm made a PR that'll be included in the test branch
17:40:46 <sarang> and ledger has a PR on their side for firmware support that's been completed
17:41:55 <xmrmatterbridge> <cankerwort> Nice that hw wallets are so proactive compared to how exchanges were with subaddresses
17:42:34 <derpy_bridge> <[keybase] seddd>: ah, that's my next step. still haven't reviewed the ledger-side stuffs. looked at cslashm's PR tho
17:42:41 <sarang> It's been very nice to see such quick work for ledger/trezor, that's for sure
17:43:02 <sarang> The goal is to have support ready to go at network upgrade time
17:43:12 <sgp_> really cool numbers
17:43:33 <sarang> Anyway, that's my report: BP speedup, Triptych WIP data, CLSAG device-specific support
17:43:46 <sarang> Any other questions for me about those topics?
17:44:14 <sgp_> Are these numbers *likely* similar to Arcturus?
17:44:25 <sgp_> for non-bath
17:44:28 <sgp_> *batch
17:45:15 <xmrmatterbridge> <cankerwort> what is Arcturus?
17:45:41 <sarang> Ah, I renamed Triptych-2, both to reduce name confusion and because it operates differently
17:45:49 <sarang> I never liked the name Triptych-2; it was more of a placeholder
17:45:53 <xmrmatterbridge> <cankerwort> Noted and appreciated
17:46:04 <sarang> I am not good at clever naming :/
17:46:09 <sarang> Anyway, to answer sgp_'s question
17:46:17 <sarang> Arcturus gives better size scaling
17:46:23 <sarang> Verification timing will be very similar to Triptych
17:46:43 <sgp_> size already looks pretty good
17:47:58 <ArticMine> Still if it can be made smaller then it is an improvement
17:48:06 <sarang> With Arcturus, you only need one proof/signature per _transaction_ instead of per _input_
17:48:17 <Isthmus> Ooooh
17:48:30 <sarang> The magic of generator reuse means the verification would be similar (if you use common anon sets for Triptych for comparison)
17:48:40 <sarang> (this difference is why I renamed it)
17:48:59 <sarang> However, keep in mind that Arcturus relies on a nonstandard hardness assumption
17:48:59 <ArticMine> What if any are the disadvantages?
17:49:06 <sarang> ^^
17:49:15 <xmrmatterbridge> <cankerwort> Is the plan still to get CLSAG audited in time for the next fork? Which are now annually apparently?
17:49:26 <sarang> This is my understanding
17:49:31 <sarang> (but it's not my decision)
17:49:41 <binaryFate> sarang what's your feeling about whether the multisig issue can be solved without foreign primitives?
17:50:08 <sarang> As far as I know, we'd need support for general RSA groups for proper multisig with the next-gen constructions
17:50:21 <sarang> This is for signing only, not verification
17:50:45 <sarang> (even though it's RSA groups, there are no trusted setup problems, FWIW)
17:51:00 <binaryFate> And you're confident about this being a requirement, or it's just that nobody found how to do without yet?
17:51:18 <UkoeHB_> I did a writeup on the multisig question here https://github.com/monero-project/research-lab/issues/72
17:51:35 <sarang> If you can point out a homomorphic public-key scheme that can use arbitrary prime-order groups, I'm all ears
17:51:58 <sarang> Yes, it links to code and a description that I worked out
17:52:04 <UkoeHB_> right ^
17:52:19 <sarang> Paillier encryption is not specifically required
17:52:28 <sarang> but you need an additively homomorphic scheme
17:53:44 <sarang> Anyway, I've taken a lot of time in this meeting
17:53:50 <sarang> Was there anything else of interest to share here?
17:54:50 <TheCharlatan> I made a Rust PoC for including timelock blinding and commitments in transactions. The PoC builds transactions and verifies them with CLSAG signing and the locktime blinding mechanism as described in DLSAG. It looks like the additional size requirements are: input and output commitments, auxiliary (dummy) plaintext locktime, locktime image and a range proof. Thanks to CLSAG, there is no further
17:54:52 <TheCharlatan> increase in the signature size. Contrary to the locktime blinding desription in DLSAG, I think we can spare the range proof on the transaction's output locktime. The main size component therefore is the additional range proof. I also had a discussion about aggregating the locktime range proof in a transaction input with the amount range proof in the output with sarang yesterday (admittedly more
17:54:54 <TheCharlatan> of a lesson from sarang, than a discussion). The gist of it is that in transactions with many outputs and inputs, aggregated range proof verification would become prohibitively slow.
17:55:13 <derpy_bridge> <[keybase] seddd>: oh, awesome! please disregard then, sometimes I derp
17:55:59 <sarang> TheCharlatan: there should be an additional 32 bytes to the signature
17:56:07 <sarang> because of the use of an additional auxiliary linking tag
17:56:59 <TheCharlatan> Ah, right I did not include tags in the description :P
17:57:24 <sarang> However, adding 32 bytes per input is still pretty darn good
17:57:32 <sarang> Note that verification will take a hit
17:57:43 <sarang> I have a CLSAG test branch that shows the difference
17:57:52 <sarang> (but I don't recall the numbers)
17:58:10 <sarang> TheCharlatan: is your code public?
17:58:34 <TheCharlatan> yes: https://github.com/TheCharlatan/rs-xmr-cryp/tree/master/timelock
17:58:48 <sarang> Also: note that Triptych can be easily extended to support this as well, since it's also a d-LRS construction like CLSAG is
17:58:51 <sarang> nice thanks
17:59:02 <derpy_bridge> <[keybase] seddd>: TheCharlatan: that's awesome! was going to live-code CLSAG in Rust this Saturday. glad to have another reference impl :)
17:59:44 <sarang> There's also another CLSAG rust implementation available too
17:59:59 <sarang> https://github.com/crate-crypto
18:00:25 <derpy_bridge> <[keybase] seddd>: so nice! thanks sarang :)
18:00:36 <sarang> (I didn't write that, FWIW)
18:00:58 <derpy_bridge> <[keybase] seddd>: for sure, thanks for the link then :)
18:01:07 <TheCharlatan> The crate-crypto implementation is much nicer, mine is more of a quick script.
18:01:30 <sarang> TheCharlatan: what would be helpful from this group at this point?
18:03:36 <TheCharlatan> so I don't have a good feel on the boundaries of bulletproof scaling yet. So I think some more data there would be helpful.
18:03:55 <sarang> OK, I'm glad to help with that if you like
18:04:08 <sarang> (probably best to save those questions for after the meeting)
18:04:14 <TheCharlatan> yes :)
18:04:31 <sarang> Thanks TheCharlatan
18:04:35 <sarang> OK, we're just past the hour mark
18:04:40 <sarang> Let's move on to ACTION ITEMS
18:04:49 <sarang> What do folks plan to work on this week (that they wish to share)?
18:05:02 <sarang> I plan to finish the last Triptych code optimizations, to finalize that timing data
18:05:32 <sarang> as well as the CLSAG device-specific code integration
18:05:39 <sarang> Others?
18:06:04 <UkoeHB_> I think Ill write a brief proposal for Janus + view tag + extra field, a package update
18:06:15 <UkoeHB_> The concept seems to be coalescing
18:07:05 <derpy_bridge> <[keybase] seddd>: just working on finishing up testing/manual review of CLSAG, writing the draft report, etc
18:07:06 <sarang> Yeah, and there are several related ideas there that could happen concurrently
18:08:12 <derpy_bridge> <[keybase] seddd>: _cedes to UkoeHB__
18:09:59 <sarang> Any last questions or comments before we adjourn?
18:10:17 <UkoeHB_> ArticMine: how is the fee proposal coming along?
18:10:45 <binaryFate> just wants to say that was a lot of impressive developments, feels like christmas
18:10:51 <asdc_ccc> ^
18:11:38 <ArticMine> Still working on the fee part.
18:12:31 <sarang> All right; we are adjourned! Thanks to everyone for participating
18:12:34 <sarang> Lots will be posted shortly
18:12:43 <sarang> Discussions can of course continue :)
18:12:58 <ArticMine> I have the rest figured out namely how the LT medium and variable penalty free one will work
18:13:03 <derpy_bridge> <[keybase] seddd>: thanks for the meeting <3
18:16:34 <sarang> logs posted
18:31:50 <UkoeHB_> https://medium.com/@j_10523/mobilecoin-code-release-2854ee2f9310 they are implementing a version of RCTTypeBulletproof2
18:47:28 <derpy_bridge> <[keybase] seddd>: mobilecoin w/ new stuff + open-sourcing?! so much goodness, it really is like christmas binaryFate :)
18:58:07 <TheCharlatan> I'm not particularly excited about mobilecoin - sgx powered consensus algorithm and all.
18:59:20 <derpy_bridge> <[keybase] seddd>: yeah, secure enclave is a little meh. riscv also has secure enclave modules, open-hardware style (much better)
18:59:51 <derpy_bridge> <[keybase] seddd>: mb with the PoC on SGX, future gens could be on open-hardware platforms
19:04:35 <derpy_bridge> <[keybase] seddd>: I understand their SGX decision tho (wide deployment, proven tech)
19:04:52 <UkoeHB_> it seems they have moved away from relying on SGX too much, Im not actually sure how critical it is
19:06:32 <derpy_bridge> <[keybase] seddd>: me either UkoeHB_, they aren't using it like ShadowETH (for pseudo-FHE). Plus they do ringct inside the SGX
19:11:03 <derpy_bridge> <[keybase] seddd>: consensus docs: https://github.com/mobilecoinofficial/mobilecoin/blob/master/consensus/enclave/README.md
19:20:56 <derpy_bridge> <[keybase] seddd>: federated SCP consensus seems more central/hard-to-change. be nice if there was a fast PoW(-like) consensus algo that met their design reqs
20:32:39 <sarang> The preprint on hierarchical Groth-style one-of-many proofs has been publicly released: https://eprint.iacr.org/2020/430
21:06:07 <derpy_bridge> <[keybase] seddd>: (*.*) *soexcite*