15:35:23 <moneromooo> I have added encrypted (to the recipient) payload in extra. I expect there will be discussion about things like sizes, and maybe padding system.
15:35:38 <moneromooo> sarang: you'll probably be interested in this ^ (6410).
15:57:10 <sarang> Very interested
15:57:44 <sarang> So this is akin to the Zcash memo field?
16:02:26 <sarang> Having variable length poses issues for uniformity, of course
16:02:32 <sarang> but extra is already variable...
16:02:53 <sarang> FWIW the Zcash approach is that the memo field is required and of a fixed length
16:03:16 <sarang> 512 bytes IIRC
16:03:33 <jwinterm> yea that is correct I believe sarang
16:04:37 <sarang> One "intermediate" option could be that the field is optional, but if present must be of a fixed length
16:04:53 <sarang> Which produces (ideally) only two "anonymity pools": present or not present
16:05:07 <sarang> As opposed to having quantization be available as a fingerprinting tool
16:05:49 <jwinterm> if it is made mandatory and of fixed size, isn't that data that could be trivially pruned by full nodes later?
16:27:50 <sarang> This does seemt to have significant functional overlap with encrypted payment IDs
16:29:31 <sarang> s/seemt/seem
16:37:28 <dEBRUYNE> <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?
16:37:59 <sarang> yes
16:40:16 <dEBRUYNE> sarang: Should I leave a comment on Github for visibility purposes?
16:40:33 <sarang> sure
16:40:39 <dEBRUYNE> OK, will add
16:40:49 <sarang> IMO ideally the field would be required and of a fixed length
16:41:06 <sarang> but at that point you've basically just built a bigger encrypted payment ID
16:41:09 <dEBRUYNE> So uniformity both with respect to field size and transactions right?
16:41:42 <sarang> Yeah, but of course that has consequences for chain size and overall usability (you couldn't include longer data)
16:45:27 <dEBRUYNE> Can you elaborate on the latter?
16:49:59 <fuwa-prpr> does encrypted payment ID work with subaddress?
16:50:16 <UkoeHB_> sure it does
16:51:20 <luigi1111w> cannot trivially prune unless you move it to the prunable portion
16:51:27 <luigi1111w> which might make sense to do
16:51:53 <sarang> dEBRUYNE: if the size is mandated and fixed, it's limited
16:53:43 <dEBRUYNE> Ah, right
16:53:45 <UkoeHB_> 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
16:53:55 <UkoeHB_> which they surely will if it's easy
16:56:56 <UkoeHB_> not to mention all the bloat
16:58:48 <fuwa-prpr> oh, the extra field is not exposed in wallet-rpc
16:59:37 <fuwa-prpr> sneaky :p
17:05:29 <moneromooo> 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.
17:08:16 <fuwa-prpr> good to know
17:08:31 <moneromooo> The other size quantization I was pondering is a table one, something like 32, 64, 128, 256, 512...
17:09:13 <moneromooo> Or just 32, 256, 4 kB, 64 kB, nothing larger.
17:09:39 <luigi1111w> 64 seems like a lot
17:09:42 <moneromooo> Moving to prunable's totally fine.
17:09:55 <luigi1111w> memo field in sig yeah
17:10:04 <UkoeHB_> max tx size is 150kB irrc
17:10:05 <luigi1111w> though would be forking
17:14:52 <moneromooo> 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).
17:15:11 <moneromooo> (32 is nice because it can fit a key)
17:16:57 <sarang> moneromooo: can you move the chunk key and IV domain separators to the common config location, to avoid any future overlap with other functionality?
17:18:44 <moneromooo> There is no common location yet I think.
17:19:14 <sarang> I had that PR that moved as many of the separators as I could reasonably find into common config
17:20:02 <sarang> 6338
17:25:19 <moneromooo> It is not merged.
17:29:08 <sarang> nope
17:29:13 <sarang> not sure why
17:29:49 <moneromooo> Because pony went away and it's been slow ever since.
17:54:08 <sarang> Well, once that gets merged, I think it makes sense to put the new chacha domain stuff there as well
18:25:04 <selsta> moneromooo: can you also send the current merge list to luigi?
18:25:31 <selsta> he usually helps out with merges
18:26:11 <moneromooo> Sure.
18:29:20 <luigi1111w> I have one from dEBRUYNE that will get done today
18:29:38 <dEBRUYNE> It's simply a formatted version of the list mooo send me :p
18:29:46 <luigi1111w> oic
19:10:48 <luigi1111w> sarang 6338 needs rebased
19:19:13 <sarang> Will do
19:54:50 <sarang> luigi1111w: done
19:55:51 <luigi1111w> that's not a proper rebase
19:58:31 <sarang> sigh
19:58:34 <sarang> thanks, github web interface
20:05:30 <selsta> luigi1111w: "Merge branch 'wallet-api-estimate-fee' of https://github.com/xiphon/m…"
20:05:34 <selsta> did this merge correctly?
20:05:50 <selsta> guess it is too late now without force pushing
20:07:08 <luigi1111w> dad blast it
20:09:35 <luigi1111w> oh well
20:15:31 <luigi1111w> probably shouldn't do that, but whatever
20:15:54 <selsta> ?
20:16:09 <luigi1111w> I fixed it
20:16:10 <selsta> oh you force pushed :D
20:16:24 <luigi1111w> don't tell anyone
20:16:32 <sarang> luigi1111w: will fix mine via CLI, one sec
20:16:43 <sarang> I foolishly assumed the web interface would do the Right Thing by default
20:16:45 <selsta> github web interface is useless
20:16:57 <selsta> for using git
20:17:22 <selsta> for editing stuff :P displaying is ok
20:27:26 <selsta> moneromooo: you have to rebase this again: https://github.com/monero-project/monero/pull/6269/commits
20:27:37 <selsta> due to force push
20:29:51 <moneromooo> No, still applies fine.
20:30:40 <selsta> hmm it looks broken on github
20:32:15 <moneromooo> OK, I'll push -f, might help.
20:32:40 <moneromooo> Did it ?
20:32:49 <selsta> looks good now
20:34:18 <sarang> luigi1111w: how does 6338 look now?
20:35:41 <sarang> I think that I caught the force push in time
20:36:16 <fuwa> this is where gitlab shines, there's no need for forced push, maintainers can squash all during merge
20:36:44 <selsta> core does not use github for merges
20:36:53 <selsta> or the maintainers
20:37:12 <fuwa> oh ok
20:37:28 <selsta> AFAIK they have their own script to create merge commits
20:38:18 <fuwa> nvm, didn't know that
21:07:30 <luigi1111w> sarang looks good
21:07:49 <luigi1111w> branches don't need to be even with master, they just need not to conflict
21:08:34 <sarang> Eh, there was only one conflict with the full rebase
21:08:53 <sarang> Might as well, to ensure it passes CI
21:09:03 <sarang> (which seems to be building just fine)
21:11:45 <selsta> If anyone has ideas for things we can add to the CI, I’m open... Might as well use the free computing power lol
22:02:02 <selsta> luigi1111w: if you are still around, a few PRs have been rebased now and are ready to merge
22:10:41 <luigi1111w> list them
22:11:24 <selsta> I don’t know what is on your merge list, but #6286 #6269 #6338
22:11:37 <selsta> if they are not on your list forget it :)
22:32:35 <moneromooo> selsta: how much of it ? There are fuzz tests ^_^
22:33:08 <selsta> but fuzz tests don’t stop, right?
22:33:17 <selsta> so it isn’t something that can run per commit
22:33:46 <moneromooo> You could rig them to stop. But it was mostly a joke, that'd get us kicked when they find out :)
22:33:54 <moneromooo> Might already have CPU limits anyway.
22:37:54 <selsta> Is there a README on running fuzz tests?
22:38:14 * moneromooo checks
22:38:35 <selsta> ok found contrib/fuzz_testing/fuzz.sh
22:39:39 <moneromooo> No, but it's just: make fuzz; contrib/fuzz_testing/fuzz.sh $NAME
22:40:04 <moneromooo> The list for NAME is in contrib/fuzz_testing/fuzz.sh
22:40:33 <moneromooo> And it prints it when run without args. I did not suck this time.
22:41:00 <selsta> so these run until the program crashes?
22:41:09 <moneromooo> Yes. Also after.
22:41:18 <iDunk> Doesn't it require afl ?
22:41:27 <moneromooo> It does require afl.