I have added encrypted (to the recipient) payload in extra. I expect there will be discussion about things like sizes, and maybe padding system.

sarang: you'll probably be interested in this ^ (6410).

Very interested

So this is akin to the Zcash memo field?

Having variable length poses issues for uniformity, of course

but extra is already variable...

FWIW the Zcash approach is that the memo field is required and of a fixed length

512 bytes IIRC

yea that is correct I believe sarang

One "intermediate" option could be that the field is optional, but if present must be of a fixed length

Which produces (ideally) only two "anonymity pools": present or not present

As opposed to having quantization be available as a fingerprinting tool

if it is made mandatory and of fixed size, isn't that data that could be trivially pruned by full nodes later?

This does seemt to have significant functional overlap with encrypted payment IDs

s/seemt/seem

<sarang> Having variable length poses issues for uniformity, of course <= Can we not pad it with dummy data up till a certain length that is then fixed protocol wise?

yes

sarang: Should I leave a comment on Github for visibility purposes?

sure

OK, will add

IMO ideally the field would be required and of a fixed length

but at that point you've basically just built a bigger encrypted payment ID

So uniformity both with respect to field size and transactions right?

Yeah, but of course that has consequences for chain size and overall usability (you couldn't include longer data)

Can you elaborate on the latter?

does encrypted payment ID work with subaddress?

sure it does

cannot trivially prune unless you move it to the prunable portion

which might make sense to do

dEBRUYNE: if the size is mandated and fixed, it's limited

Ah, right

while the extra field is obviously open ended, Im a bit skeptical about supporting a feature that lets people easily put random things in there

which they surely will if it's easy

not to mention all the bloat

oh, the extra field is not exposed in wallet-rpc

sneaky :p

I don't know what zcash does. Padding is what this patches does. Mandatory with fixed size spams a lot if you want to allow substantially sized data. Technically, encrypted payment ids work with subaddresses, but integrated subaddresses aren't implemented. You can set a recipient private data via rpc.

good to know

The other size quantization I was pondering is a table one, something like 32, 64, 128, 256, 512...

Or just 32, 256, 4 kB, 64 kB, nothing larger.

64 seems like a lot

Moving to prunable's totally fine.

memo field in sig yeah

max tx size is 150kB irrc

though would be forking

I guess it could be mandatory, and have 32/256/4kB. So only 3 puddles, and people not using any don't spam much (32).

(32 is nice because it can fit a key)

moneromooo: can you move the chunk key and IV domain separators to the common config location, to avoid any future overlap with other functionality?

There is no common location yet I think.

I had that PR that moved as many of the separators as I could reasonably find into common config

6338

It is not merged.

nope

not sure why

Because pony went away and it's been slow ever since.

Well, once that gets merged, I think it makes sense to put the new chacha domain stuff there as well

moneromooo: can you also send the current merge list to luigi?

he usually helps out with merges

Sure.

I have one from dEBRUYNE that will get done today

It's simply a formatted version of the list mooo send me :p

oic

sarang 6338 needs rebased

Will do

luigi1111w: done

that's not a proper rebase

sigh

thanks, github web interface

luigi1111w: "Merge branch 'wallet-api-estimate-fee' of github.com/xiphon/m…"

did this merge correctly?

guess it is too late now without force pushing

dad blast it

oh well

probably shouldn't do that, but whatever

?

I fixed it

oh you force pushed :D

don't tell anyone

luigi1111w: will fix mine via CLI, one sec

I foolishly assumed the web interface would do the Right Thing by default

github web interface is useless

for using git

for editing stuff :P displaying is ok

moneromooo: you have to rebase this again: monero-project/monero #6269/commits

due to force push

No, still applies fine.

hmm it looks broken on github

OK, I'll push -f, might help.

Did it ?

looks good now

luigi1111w: how does 6338 look now?

I think that I caught the force push in time

this is where gitlab shines, there's no need for forced push, maintainers can squash all during merge

core does not use github for merges

or the maintainers

oh ok

AFAIK they have their own script to create merge commits

nvm, didn't know that

sarang looks good

branches don't need to be even with master, they just need not to conflict

Eh, there was only one conflict with the full rebase

Might as well, to ensure it passes CI

(which seems to be building just fine)

If anyone has ideas for things we can add to the CI, I’m open... Might as well use the free computing power lol

luigi1111w: if you are still around, a few PRs have been rebased now and are ready to merge

list them

I don’t know what is on your merge list, but #6286 #6269 #6338

if they are not on your list forget it :)

selsta: how much of it ? There are fuzz tests ^_^

but fuzz tests don’t stop, right?

so it isn’t something that can run per commit

You could rig them to stop. But it was mostly a joke, that'd get us kicked when they find out :)

Might already have CPU limits anyway.

Is there a README on running fuzz tests?

ok found contrib/fuzz_testing/fuzz.sh

No, but it's just: make fuzz; contrib/fuzz_testing/fuzz.sh $NAME

The list for NAME is in contrib/fuzz_testing/fuzz.sh

And it prints it when run without args. I did not suck this time.

so these run until the program crashes?

Yes. Also after.

Doesn't it require afl ?

It does require afl.