sarang meeting 50mins?

aye

Original tari Reddit post mentioned working with MRL on some ideas, has that happened? reddit.com/r/Monero/comments/8lgvw4…ari_a_decentralised_assets_protocol

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?

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?

I don’t think lightning network has been given up.

UkoeHB_: did you see rfc.tari.com ?

Meeting starts in just a few minutes

OK, let's get started

Greetings!

Hi

Hiya

Hello

Thanks selsta I'll look

I suppose we can move to roundtable discussion

Who wishes to share interesting research?

hello

Something quick from NRL

We've been looking at some results regarding the extra field in transactions. We have one thing to share today

Here is an analysis of Payment id usage since v10 when unencrypted payment ids were deprecated:

(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)

^ moneromooo etc.

It's actually not 'mandatory', just part of the core wallet's behavior

As jtgrassie liked to insist :p

Nothing stops a wallet from simply including a fixed default value either

(can't enforce "uniformly random" in that way)

Once again touches on the idea of extra parsing/enforcement

Are there other indications of what non-standard software it might be?

17% is a good amount that didn't update properly

do they save slightly on fees?

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

Thanks n3ptune

Thanks! Just sharing these numbers today

if the fees are lower, I can see someone setting it up this way if they process many transactions

Looking at long payment id usage since 1.7e6 is a bit pointless. What is it from 1.98e6 ?

I can check

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)>

moneromooo: was the dummy encrypted payment ID also since 1.98e6?

Another good question

I think before.

It was merged late january 2019.

Yes, it was included in the release for that height.

I don't think we looked at long PID

Sorry, here is the updated figure

? Long PID = Unencrypted PID, yes

Yes.

Oh, I was thinking integrated

Sorry, on 4 hours of sleep, no coffee, and in presentations at a crypto compliance company all morning

But they're cool with me being half in MRL, obviously they've been pretty supportive of my research over the past year :- )

How ominous

it might just mean more significant implementations exist than just core, which might be good news also

Well, not if the result is fingerprinting

n3ptune: also, afaik coinbase transactions do not use payment IDs (a round 200k tx over that period)

The numbers should be for non-coinbase only

Well, in the interest of time, shall we continue? Hopefully we can get more detailed data, which can help any future decisions about parsing

Thanks for the data Isthmus and n3ptune

Thx, I'll check out those questions

Other research to discuss or share?

UkoeHB _ ?

suraeNoether ?

OK, I can discuss a few short items

ok, I sketched out a light node proposal monero-project/research-lab #69 pls leave your thoughts there if interested

Ah ok, nvm

go ahead 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 pdf-archive.com/2020/02/12/zerotomo…0-25/zerotomoneromaster-v1-0-25.pdf

thats all from me

@UkoeHB_ just scoped that proposal last night, looks like great stuff

Looks to be similar to SPV structure?

possibly, idk anything about SPV

I worked out data storage inside RCT3 proofs (both single- and multi-input) as well as storage in multi-input Triptych

Finished code and tests for new transaction proofs

did some Dandelion++ review

yay triptych!

Wrote some code to demo spend/non-spend status proofs that have been discussed previously

and overhauled the Omniring/RCT3/Triptych key image multisig construction protocol

Any size indications for triptych?

Individual transactions? Sure, that's been available for some time

Now that I have I/O structure data from n3ptune, I can run some chain-wide estimates based on that

since different tx protocols imply different tradeoffs as I/O structure changes

It seems to me a move in the reference tx size from 3000 bytes to 4000 bytes would be needed

Which is very reasonable given the mixin privacy gains

why increase?

It depends on what protocol (if any) is chosen, what parameters used, etc.

ah i see, for 1024 ring size

I am saying with N = 512 or 1024

what are the hurdles for tryptich? besides me wanting to spell it wrong all the time

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

If we increase the penalty free block weight to 400000 bytes

gingeropolous: no peer review yet

I also need to know the practical drawbacks to the more complex multisig operations

especially on lower-powered devices

They'd need to support Paillier encryption/decryption for multisig with any of the sublinear protocols

We must also keep in mind this is less than a year of Nielsen's Law of Internet Bandwidth

ugh. what, for those silly hardware wallets?

Well, anything that would need to participate in multisig

The process involves doing peer-to-peer Paillier operations, some Schnorr and commitment stuff, etc.

would multi-tryptich work with any kind of join protocol?

Unclear. It's still in the early stages

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 zawy12/difficulty-algorithms #50

and suraeNoether was at one point doing research on that area

apparently Monero's algorithm is quite bad, relatively speaking

Interesting; I had seen some of their earlier work, but not this summary

The conclusion seems to be that the potential oscillations would be of much greater importance for uses with large mining variance

(which isn't really part of the design choice)

Worth a read, now that we have the link

UkoeHB_: did you want to discuss extra sorting, given its relationship to the information from n3ptune and Isthmus?

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

Fair enough. Trying to enforce better uniformity and order is a good idea, so I agree

It may come down to questions of efficiency and "someone needs to write it", but who knows

enforcing it should be less than 100 lines of code IMO

Sounds like someone is volunteering :D

Anyway, there is a Konferenco meeting starting presently, so any final comments or thoughts before adjourning?

Righto; thanks for attending, everyone

The data on payment IDs cycles back to the seemingly eternal discussion about whether or not to limit tx_extra formats and data

"Banning" certain data types would involve what, disallowing their tags?

Custom wallets could always add additional arbitrary data with different tags

Meaning that it's not clear what type of intermediate enforcement would work, aside from whitelisting tags

(this is aside from the fingerprinting that could be possible from sorting etc., for which UkoeHB_ was advocating changes)

the main thing for me is fingerprinting should be a very _purposeful_ implementation choice, not because the protocol itself is loosey goosey

Yep, for sure

Jog my memory UkoeHB_... was this discussed at a -dev meeting too?

or only here in -lab?

was not a meeting, but I brought it up in -dev on Feb 6th; monerologs.net/monero-dev/20200206 and it continued into Feb 7th monerologs.net/monero-dev/20200207

ty

I'd rather move stuff we need (tx keys, short payment id) in a separate fixed rules structure, and keep extra freeform.

If fixes your case of "I somehow fuck it up despite doing what everyone else does".

We might also gain a couple bytes from length fields if the common stuff is in a fixed structure.

Guess s/we need /we "need"/.

I wonder in practice how often extra would still be used in a fingerprinty way

I dont see it as people fucking up, just as not even realizing people are doing it differently (or prioritizing protocol correctness over precision).

But having set structures seems like a much cleaner approach, especially given that protocol upgrades (which would affect it) happen already

if there are multiple valid _basic_ constructions possible for a tx, then all those constructions will appear in the wild

obviously _nonbasic_ constructions will have variation

But at least in a more consistent way

(which seems to be precisely your point here)

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

which would be greatly encouraged by enforced sorted tlv

The idea of a separate protocol-enforced structure wouldn't preclude that

not necessarily

(but would add additional parsing complexity if not freeform)

200 lines pseudocode, my prediction was a little too ambitious monero-project/research-lab #61#issuecomment-585461642

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?

I think they're useful for comparison to new development, but not necessary for most readers

but that's just me