| layout |
title |
tags |
author |
| post |
Logs for the MRL Meeting Held on 2020-02-12 |
| dev diaries |
| crypto |
| research |
|
asymptotically / Sarang |
Logs
<sarang> Greetings!
<ArticMine> Hi
<UkoeHB_> Hiya
<n3ptune> Hello
<UkoeHB_> Thanks selsta I'll look
<sarang> I suppose we can move to roundtable discussion
<sarang> Who wishes to share interesting research?
<sgp_> hello
<n3ptune> Something quick from NRL
<n3ptune> We've been looking at some results regarding the extra field in transactions. We have one thing to share today
<n3ptune> Here is an analysis of Payment id usage since v10 when unencrypted payment ids were deprecated:
<n3ptune> https://usercontent.irccloud-cdn.com/file/Xf1uZRsZ/image.png
<n3ptune> (Sorry there is an uncorrected typo: "Unencrypted Included x Encrypted Absent" should be 232980 (not 232972) and "Unencrypted Absent x Encrypted Included" should be 1904765)
<sarang> ^ moneromooo etc.
<UkoeHB_> It's actually not 'mandatory', just part of the core wallet's behavior
<UkoeHB_> As jtgrassie liked to insist :p
<sarang> Nothing stops a wallet from simply including a fixed default value either
<sarang> (can't enforce "uniformly random" in that way)
<sarang> Once again touches on the idea of extra parsing/enforcement
<sarang> Are there other indications of what non-standard software it might be?
<sgp_> 17% is a good amount that didn't update properly
<sgp_> do they save slightly on fees?
<n3ptune> That's a good question, we didn't look into the transactions but there may be other things going on that make more of a fingerprint
<sarang> Thanks n3ptune
<n3ptune> Thanks! Just sharing these numbers today
<sgp_> if the fees are lower, I can see someone setting it up this way if they process many transactions
<moneromooo> Looking at long payment id usage since 1.7e6 is a bit pointless. What is it from 1.98e6 ?
<n3ptune> I can check
<UkoeHB_> n3ptune: the core wallet only creates encrypted payment IDs for all 2-output tx, would you mind looking into the distinction (proportion encrypted IDs with 2-output and >2 output)>
<UkoeHB_> moneromooo: was the dummy encrypted payment ID also since 1.98e6?
<n3ptune> Another good question
<moneromooo> I think before.
<moneromooo> It was merged late january 2019.
<moneromooo> Yes, it was included in the release for that height.
<Isthmus> I don't think we looked at long PID
<Isthmus> Sorry, here is the updated figure
<Isthmus> https://usercontent.irccloud-cdn.com/file/t5ozuruh/image.png
<n3ptune> ? Long PID = Unencrypted PID, yes
<moneromooo> Yes.
<Isthmus> Oh, I was thinking integrated
<Isthmus> Sorry, on 4 hours of sleep, no coffee, and in presentations at a crypto compliance company all morning
<Isthmus> But they're cool with me being half in MRL, obviously they've been pretty supportive of my research over the past year :- )
<sarang> How ominous
<UkoeHB_> it might just mean more significant implementations exist than just core, which might be good news also
<sarang> Well, not if the result is fingerprinting
<UkoeHB_> n3ptune: also, afaik coinbase transactions do not use payment IDs (a round 200k tx over that period)
<n3ptune> The numbers should be for non-coinbase only
<sarang> Well, in the interest of time, shall we continue? Hopefully we can get more detailed data, which can help any future decisions about parsing
<sarang> Thanks for the data Isthmus and n3ptune
<n3ptune> Thx, I'll check out those questions
<sarang> Other research to discuss or share?
<sarang> UkoeHB _ ?
<sarang> suraeNoether ?
<sarang> OK, I can discuss a few short items
<UkoeHB_> ok, I sketched out a light node proposal https://github.com/monero-project/research-lab/issues/69 pls leave your thoughts there if interested
<sarang> Ah ok, nvm
<sarang> go ahead UkoeHB_
<UkoeHB_> ZtM2 I got through multisig and the draft of that chapter is done, started working on escrowed marketplace chapter which will be done by next meeting https://www.pdf-archive.com/2020/02/12/zerotomoneromaster-v1-0-25/zerotomoneromaster-v1-0-25.pdf
<UkoeHB_> thats all from me
<Isthmus> @UkoeHB_ just scoped that proposal last night, looks like great stuff
<sarang> Looks to be similar to SPV structure?
<UkoeHB_> possibly, idk anything about SPV
<sarang> I worked out data storage inside RCT3 proofs (both single- and multi-input) as well as storage in multi-input Triptych
<sarang> Finished code and tests for new transaction proofs
<sarang> did some Dandelion++ review
<gingeropolous> yay triptych!
<sarang> Wrote some code to demo spend/non-spend status proofs that have been discussed previously
<sarang> and overhauled the Omniring/RCT3/Triptych key image multisig construction protocol
<ArticMine> Any size indications for triptych?
<sarang> Individual transactions? Sure, that's been available for some time
<sarang> https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
<sarang> Now that I have I/O structure data from n3ptune, I can run some chain-wide estimates based on that
<sarang> since different tx protocols imply different tradeoffs as I/O structure changes
<ArticMine> It seems to me a move in the reference tx size from 3000 bytes to 4000 bytes would be needed
<ArticMine> Which is very reasonable given the mixin privacy gains
<UkoeHB_> why increase?
<sarang> It depends on what protocol (if any) is chosen, what parameters used, etc.
<UkoeHB_> ah i see, for 1024 ring size
<ArticMine> I am saying with N = 512 or 1024
<gingeropolous> what are the hurdles for tryptich? besides me wanting to spell it wrong all the time
<ArticMine> If this goes through, by the time it makes it to the main chain the drop in block reward would easily cover the fee increase
<ArticMine> If we increase the penalty free block weight to 400000 bytes
<sarang> gingeropolous: no peer review yet
<sarang> I also need to know the practical drawbacks to the more complex multisig operations
<sarang> especially on lower-powered devices
<sarang> They'd need to support Paillier encryption/decryption for multisig with any of the sublinear protocols
<ArticMine> We must also keep in mind this is less than a year of Nielsen's Law of Internet Bandwidth
<gingeropolous> ugh. what, for those silly hardware wallets?
<sarang> Well, anything that would need to participate in multisig
<sarang> The process involves doing peer-to-peer Paillier operations, some Schnorr and commitment stuff, etc.
<UkoeHB_> would multi-tryptich work with any kind of join protocol?
<sarang> Unclear. It's still in the early stages
<UkoeHB_> before this meeting gets wrapped up, I am curious about the state of discussion around Monero's difficulty algorithm; zawy12 seems to have done a lot of research on the topic of difficulty algos https://github.com/zawy12/difficulty-algorithms/issues/50
<UkoeHB_> and suraeNoether was at one point doing research on that area
<UkoeHB_> apparently Monero's algorithm is quite bad, relatively speaking
<sarang> Interesting; I had seen some of their earlier work, but not this summary
<sarang> The conclusion seems to be that the potential oscillations would be of much greater importance for uses with large mining variance
<sarang> (which isn't really part of the design choice)
<sarang> Worth a read, now that we have the link
<sarang> UkoeHB_: did you want to discuss extra sorting, given its relationship to the information from n3ptune and Isthmus?
<UkoeHB_> I feel Ive made my case for it, although Isthmus says they are working on a big comprehensive report so at that time I may recapitulate
<sarang> Fair enough. Trying to enforce better uniformity and order is a good idea, so I agree
<sarang> It may come down to questions of efficiency and "someone needs to write it", but who knows
<UkoeHB_> enforcing it should be less than 100 lines of code IMO
<sarang> Sounds like someone is volunteering :D
<sarang> Anyway, there is a Konferenco meeting starting presently, so any final comments or thoughts before adjourning?
<sarang> Righto; thanks for attending, everyone
