Logs for the Monero Research Lab Meeting Held on 2019-10-14
October 14, 2019
Logs
<sarang> GREETINGS
<suraeNoether> howdy!
<sgp_> Hello
<sarang> Small crowd today, apparently
<sarang> Even so, we carry on
<sarang> Let's move to ROUNDTABLE
<sarang> I've been working on a few things this past week
<sarang> First is getting caught up with the usual literature review
<sarang> Second was finalizing things for World Crypto Conference and some background research associated to that
<sarang> Third was getting balance proofs working in Triptych, which is now successful
<xmrmatterbridge> <serhack> hello
<sarang> This means that Triptych now supports a single proof showing all spends, correct key image construction, and balance
<suraeNoether> nice!
<sarang> How about you, suraeNoether?
<suraeNoether> i've been furiously debugging my matching code as my primary task. there are some persistent problems. i wanted to finish this weekend but it didn't happen
<sarang> Earlier you had indicated some known bugs… are these the same?
<suraeNoether> no… every problem i solve reveals like… a small handful of new bugs, but the newer and newer bugs are becoming less frequent and less severe
<suraeNoether> it *feels* like there's a single problem lurking that will cause the house of cards to stop falling down
<suraeNoether> i'm very close.
<suraeNoether> i really wanted it to be today
<suraeNoether> i'm taking a break later today to read sarang's WCC talk (sorry for the delay on that) and I am taking a break later today to work on *literally anything else*
<suraeNoether> i'm very frustrated with this project
<sarang> Are the known bugs documented anywhere, so others might assist you?
<suraeNoether> i'm sure a lot of community members are also frustrated, but i this is nearing completion
<suraeNoether> no
<suraeNoether> "test X not working for unknown reason" is not a helpful document to write
<sarang> Hmm ok
<sarang> Well, I selfishly hope you will take time off that project today and review my talk :D
<sarang> Perhaps it will also help you clear your head
<sarang> Does anyone else have interesting research to share as well?
<sarang> In that case, let's go ahead and discuss ACTION ITEMS first, and then any lingering questions
<sarang> First, I have an efficient verifier for the inner-product argument in IACR/944 that I've been meaning to implement in kenshamir[m]'s Rust code, which will be useful for benchmarking… that's in progress but with some algebra problems that I'm working out
<sarang> Second, Triptych needs plenty more work: key aggregation, better Fiat-Shamir challenges, and some questions on proof elements and efficiency
<sarang> Third, I want to see if it's possible to backport some of the new RCT3 changes to the older version without using spend aggregation, to check the resulting efficiency
<sarang> and that's about it for now
<sarang> suraeNoether: ?
<suraeNoether> pushing this commit once my code is flowing. reading your WCC talk. catching up on tryptychychch
<sarang> It definitely remains to be seen how efficient we can make Triptych… but as I mentioned last week, the underlying changes to the Groth proving system are very interesting regardless
<sarang> and, as before, there is no security model for it yet
<sarang> All righty, are there other questions on research?
<sarang> This meeting has gone quite quickly
<sarang> Oh, one note about what Isthmus brought up last week regarding transaction keys and subaddresses
<sarang> It is apparently still the case that transactions to only standard addresses retain a single transaction key
<sarang> Mandating separate transaction keys for all outputs would add 32 bytes to each additional output
<sgp_> Standard = 4?
<sarang> but we're already saving > 32 bytes per output after the last change to the Pedersen mask format anyway
<moneromooo> Could there be a way to deterministically generate keypairs in such a way that the sender generates the secret keys from a seed, the recipients generate the pubkeys ? I think Bitcoin has such a scheme for generating addresses.
<moneromooo> And hopefully the seed is <= 32 bytes :)
<sarang> Well, a big selling point of subaddresses is the efficient scanning across all addresses at once
<sarang> Isthmus: only need to read up a few lines
<moneromooo> Would such a scheme invalidate the efficient scanning ? It seems doubtful since the tx keys are currently arbitrary.
<sgp_> How much effort is it to scan and see what proportion of transactions are only to standard addresses?
<sarang> sgp_: to get a distribution of how common subaddresses are?
<Isthmus> @sgp_ I think that @n3ptune accidentally did that recently
<Isthmus> Lemme see if the plots are on GitHub anywhere
<sgp_> sarang: essentially yes
<sarang> Presumably this would be affected by which large players (like exchanges) support them
<sgp_> Thanks Isthmus
<Isthmus> https://github.com/noncesense-research-lab/tx_extra_analysis/blob/master/tx_extra_viz.ipynb
<sarang> 404
<Isthmus> Oh, private repo. Lemme grab the juicy parts
<Isthmus> This might be the relevant one
<Isthmus> https://usercontent.irccloud-cdn.com/file/LgrrzOIS/image.png
<Isthmus> I suspect the diagonal is transactions that include a subaddress, while the horizontal bands are primary-only
<Isthmus> Though I'm open to alternate interpretations
<moneromooo> Oh I get it. The fast lookup would still exist, but verifiers would have to generate pubkeys, and *that* might be slow.
<sgp_> Thanks
<Isthmus> If that is the case, then I can slide a window over time and calculate fraction of transactions that appear to include no subaddresses
<sgp_> I'm not the one who can say yes or no to that :/
<sarang> Probably worth bringing up at the next dev meeting to see what others think of it
<moneromooo> It is trivial to know whether >= 1 subaddress was used as an output in a tx.
<moneromooo> If that was the question…
<moneromooo> Oh wait. Maybe not, there's some funky going on with change being treated differently…
<sgp_> A more meta question: how did this happen? What could have been done differently to help prevent this from happening?
<sarang> That's probably a question for someone like stoffu who was more directly involved in the code
<sarang> I suspect space saving was one consideration
<sgp_> knaccc too?
<sarang> but it's quite minor for the most part
<Isthmus> @sgp_ meta answer: we rolled out a new feature that:
<Isthmus> 1) you could tell use from blockchain as external observer
<Isthmus> 2) was optional
<Isthmus> Either one of those alone is ok, but together we end up in this situation.
<sgp_> I always assumed 1 wasnt the case. I was very misinformed and thus misinformed others
<Isthmus> Yeah, I think we're all just putting 2+2 together on that now
<sarang> OK, something to discuss at next dev meeting, then
<sarang> Are there any other topics to discuss for this meeting?
<Isthmus> Oh yea, lemme grab a link
<Isthmus> The CryptoEconSec paper by hasu and all is very interesting, and parts are relevant to both Monero and our lock time conversation
<Isthmus> *et al
<Isthmus> I definitely recommend reading it. Very approachable.
<Isthmus> Here's the writeup: https://uncommoncore.co/research-paper-a-model-for-bitcoins-security-and-the-declining-block-subsidy/
<Isthmus> And here is my analysis: https://twitter.com/Mitchellpkt0/status/1183581226357014528
<Isthmus> I won't rehash it all here. Just take a pass through on your next commute. :- )
<sarang> Thanks Isthmus
<sarang> Any last questions before we adjourn and continue discussions?
<sarang> Righto, thanks to everyone for attending!
Post tags : Dev Diaries, Cryptography, Monero Research Lab