01:38:22 <UkoeHB_> https://github.com/monero-project/research-lab/issues/69
17:08:17 <UkoeHB_> sarang meeting 50mins?
17:08:43 <sarang> aye
17:44:36 <UkoeHB_> Original tari Reddit post mentioned working with MRL on some ideas, has that happened? https://www.reddit.com/r/Monero/comments/8lgvw4/introducing_tari_a_decentralised_assets_protocol/
17:48:03 <UkoeHB_> It also mentions atomic swaps, but I think atoc is working on those (or was) which implies Tari isn't making any progress there. Is that the case?
17:49:35 <UkoeHB_> And finally, it sounds like research has shown various flaws in the lightning network (and its original designers may have largely given up on it), is it still worth pursuing and is Tari pursuing it?
17:51:56 <selsta> I don’t think lightning network has been given up.
17:52:21 <selsta> UkoeHB_: did you see https://rfc.tari.com ?
17:57:35 <sarang> Meeting starts in just a few minutes
18:00:38 <sarang> OK, let's get started
18:00:41 <sarang> Greetings!
18:00:51 <ArticMine> Hi
18:01:45 <UkoeHB_> Hiya
18:01:55 <n3ptune> Hello
18:01:59 <UkoeHB_> Thanks selsta I'll look
18:03:08 <sarang> I suppose we can move to roundtable discussion
18:03:15 <sarang> Who wishes to share interesting research?
18:03:20 <sgp_> hello
18:03:43 <n3ptune> Something quick from NRL
18:03:51 <n3ptune> We've been looking at some results regarding the extra field in transactions.  We have one thing to share today
18:04:10 <n3ptune> Here is an analysis of Payment id usage since v10 when unencrypted payment ids were deprecated:
18:04:10 <n3ptune> https://usercontent.irccloud-cdn.com/file/Xf1uZRsZ/image.png
18:04:32 <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)
18:05:09 <sarang> ^ moneromooo etc.
18:05:23 <UkoeHB_> It's actually not 'mandatory', just part of the core wallet's behavior
18:05:39 <UkoeHB_> As jtgrassie liked to insist :p
18:05:48 <sarang> Nothing stops a wallet from simply including a fixed default value either
18:05:59 <sarang> (can't enforce "uniformly random" in that way)
18:07:36 <sarang> Once again touches on the idea of extra parsing/enforcement
18:08:33 <sarang> Are there other indications of what non-standard software it might be?
18:09:22 <sgp_> 17% is a good amount that didn't update properly
18:09:32 <sgp_> do they save slightly on fees?
18:09:35 <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
18:10:02 * n3ptune notes this to look into
18:10:37 <sarang> Thanks n3ptune
18:11:02 <n3ptune> Thanks! Just sharing these numbers today
18:11:15 <sgp_> if the fees are lower, I can see someone setting it up this way if they process many transactions
18:12:02 <moneromooo> Looking at long payment id usage since 1.7e6 is a bit pointless. What is it from 1.98e6 ?
18:12:41 <n3ptune> I can check
18:12:45 <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)>
18:13:27 <UkoeHB_> moneromooo: was the dummy encrypted payment ID also since 1.98e6?
18:13:34 <n3ptune> Another good question
18:14:36 <moneromooo> I think before.
18:15:01 <moneromooo> It was merged late january 2019.
18:16:03 <moneromooo> Yes, it was included in the release for that height.
18:16:06 <Isthmus> I don't think we looked at long PID
18:16:09 <Isthmus> Sorry, here is the updated figure
18:16:11 <Isthmus> https://usercontent.irccloud-cdn.com/file/t5ozuruh/image.png
18:17:11 <n3ptune> ?  Long PID = Unencrypted PID, yes
18:17:24 <moneromooo> Yes.
18:17:26 <Isthmus> Oh, I was thinking integrated
18:17:43 <Isthmus> Sorry, on 4 hours of sleep, no coffee, and in presentations at a crypto compliance company all morning
18:17:57 <Isthmus> But they're cool with me being half in MRL, obviously they've been pretty supportive of my research over the past year :- )
18:19:00 <sarang> How ominous
18:19:52 <UkoeHB_> it might just mean more significant implementations exist than just core, which might be good news also
18:20:39 <sarang> Well, not if the result is fingerprinting
18:20:53 <UkoeHB_> n3ptune: also, afaik coinbase transactions do not use payment IDs (a round 200k tx over that period)
18:22:20 <n3ptune> The numbers should be for non-coinbase only
18:23:43 <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
18:24:28 <sarang> Thanks for the data Isthmus and n3ptune
18:24:49 <n3ptune> Thx, I'll check out those questions
18:25:49 <sarang> Other research to discuss or share?
18:26:50 <sarang> UkoeHB _ ?
18:26:52 <sarang> suraeNoether ?
18:27:57 <sarang> OK, I can discuss a few short items
18:28:01 <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
18:28:05 <sarang> Ah ok, nvm
18:28:07 <sarang> go ahead UkoeHB_
18:28:53 <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
18:29:06 <UkoeHB_> thats all from me
18:29:13 <Isthmus> @UkoeHB_ just scoped that proposal last night, looks like great stuff
18:29:27 <sarang> Looks to be similar to SPV structure?
18:29:54 <UkoeHB_> possibly, idk anything about SPV
18:32:44 <sarang> I worked out data storage inside RCT3 proofs (both single- and multi-input) as well as storage in multi-input Triptych
18:32:57 <sarang> Finished code and tests for new transaction proofs
18:33:08 <sarang> did some Dandelion++ review
18:33:16 <gingeropolous> yay triptych!
18:33:32 <sarang> Wrote some code to demo spend/non-spend status proofs that have been discussed previously
18:33:47 <sarang> and overhauled the Omniring/RCT3/Triptych key image multisig construction protocol
18:34:04 <ArticMine> Any size indications for triptych?
18:35:02 <sarang> Individual transactions? Sure, that's been available for some time
18:35:40 <sarang> https://github.com/SarangNoether/skunkworks/blob/sublinear/triptych.md
18:36:02 <sarang> Now that I have I/O structure data from n3ptune, I can run some chain-wide estimates based on that
18:36:15 <sarang> since different tx protocols imply different tradeoffs as I/O structure changes
18:39:02 <ArticMine> It seems to me a move in the reference tx size from 3000 bytes to 4000 bytes would be needed
18:39:30 <ArticMine> Which is very reasonable given the mixin privacy gains
18:39:44 <UkoeHB_> why increase?
18:39:53 <sarang> It depends on what protocol (if any) is chosen, what parameters used, etc.
18:40:21 <UkoeHB_> ah i see, for 1024 ring size
18:40:40 <ArticMine> I am saying with N = 512 or 1024
18:42:08 <gingeropolous> what are the hurdles for tryptich? besides me wanting to spell it wrong all the time
18:42:09 <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
18:42:50 <ArticMine> If we increase the penalty free block weight to 400000 bytes
18:43:29 <sarang> gingeropolous: no peer review yet
18:43:47 <sarang> I also need to know the practical drawbacks to the more complex multisig operations
18:43:59 <sarang> especially on lower-powered devices
18:44:17 <sarang> They'd need to support Paillier encryption/decryption for multisig with any of the sublinear protocols
18:44:19 <ArticMine> We must also keep in mind this is less than a year of Nielsen's Law of Internet Bandwidth
18:44:45 <gingeropolous> ugh. what, for those silly hardware wallets?
18:45:00 <sarang> Well, anything that would need to participate in multisig
18:45:29 <sarang> The process involves doing peer-to-peer Paillier operations, some Schnorr and commitment stuff, etc.
18:45:29 <UkoeHB_> would multi-tryptich work with any kind of join protocol?
18:45:50 <sarang> Unclear. It's still in the early stages
18:47:36 <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
18:47:50 <UkoeHB_> and suraeNoether was at one point doing research on that area
18:48:25 <UkoeHB_> apparently Monero's algorithm is quite bad, relatively speaking
18:48:34 <sarang> Interesting; I had seen some of their earlier work, but not this summary
18:51:35 <sarang> The conclusion seems to be that the potential oscillations would be of much greater importance for uses with large mining variance
18:52:00 <sarang> (which isn't really part of the design choice)
18:54:09 <sarang> Worth a read, now that we have the link
18:54:33 <sarang> UkoeHB_: did you want to discuss extra sorting, given its relationship to the information from n3ptune and Isthmus?
18:55:23 <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
18:56:35 <sarang> Fair enough. Trying to enforce better uniformity and order is a good idea, so I agree
18:57:03 <sarang> It may come down to questions of efficiency and "someone needs to write it", but who knows
18:57:44 <UkoeHB_> enforcing it should be less than 100 lines of code IMO
18:57:57 <sarang> Sounds like someone is volunteering :D
18:58:18 <sarang> Anyway, there is a Konferenco meeting starting presently, so any final comments or thoughts before adjourning?
19:00:13 <sarang> Righto; thanks for attending, everyone
20:06:48 <sarang> The data on payment IDs cycles back to the seemingly eternal discussion about whether or not to limit tx_extra formats and data
20:07:11 <sarang> "Banning" certain data types would involve what, disallowing their tags?
20:07:29 <sarang> Custom wallets could always add additional arbitrary data with different tags
20:08:04 <sarang> Meaning that it's not clear what type of intermediate enforcement would work, aside from whitelisting tags
20:10:09 <sarang> (this is aside from the fingerprinting that could be possible from sorting etc., for which UkoeHB_ was advocating changes)
20:30:02 <UkoeHB_> the main thing for me is fingerprinting should be a very _purposeful_ implementation choice, not because the protocol itself is loosey goosey
20:31:55 <sarang> Yep, for sure
20:32:42 <sarang> Jog my memory UkoeHB_... was this discussed at a -dev meeting too?
20:32:48 <sarang> or only here in -lab?
20:36:55 <UkoeHB_> was not a meeting, but I brought it up in -dev on Feb 6th; https://monerologs.net/monero-dev/20200206 and it continued into Feb 7th https://monerologs.net/monero-dev/20200207
20:42:21 <sarang> ty
20:44:36 <moneromooo> I'd rather move stuff we need (tx keys, short payment id) in a separate fixed rules structure, and keep extra freeform.
20:45:26 <moneromooo> If fixes your case of "I somehow fuck it up despite doing what everyone else does".
20:46:24 <moneromooo> We might also gain a couple bytes from length fields if the common stuff is in a fixed structure.
20:46:54 <moneromooo> Guess s/we need /we "need"/.
20:48:16 <sarang> I wonder in practice how often extra would still be used in a fingerprinty way
20:48:17 <UkoeHB_> I dont see it as people fucking up, just as not even realizing people are doing it differently (or prioritizing protocol correctness over precision).
20:48:48 <sarang> But having set structures seems like a much cleaner approach, especially given that protocol upgrades (which would affect it) happen already
20:49:38 <UkoeHB_> if there are multiple valid _basic_ constructions possible for a tx, then all those constructions will appear in the wild
20:50:00 <UkoeHB_> obviously _nonbasic_ constructions will have variation
20:50:13 <sarang> But at least in a more consistent way
20:50:22 <sarang> (which seems to be precisely your point here)
20:51:28 <UkoeHB_> there is also the situation where some niche feature appears in the wild, and our hope should be that all implementations of that niche feature are identical
20:51:51 <UkoeHB_> which would be greatly encouraged by enforced sorted tlv
20:53:51 <sarang> The idea of a separate protocol-enforced structure wouldn't preclude that
20:54:00 <sarang> not necessarily
20:54:11 <sarang> (but would add additional parsing complexity if not freeform)
23:04:05 <UkoeHB_> 200 lines pseudocode, my prediction was a little too ambitious https://github.com/monero-project/research-lab/issues/61#issuecomment-585461642
23:52:07 <UkoeHB_> Ive been considering removing the verification requirements from all signature schemes in ZtM2 (just leaving storage requirements). Is there anyone who finds them useful and/or thinks they should remain?
23:58:15 <sarang> I think they're useful for comparison to new development, but not necessary for most readers
23:58:21 <sarang> but that's just me