<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