Try this out dangerousfreedom: paste.debian.net/1231686

hello

good daz

*day

i want to learn more about monero 0.15.x.x , i have seen that there is a mininero repo. It does not run ! says lots of import errors and so on in python...

i have a lot of questions...

i guess if i can run mininero then i can see ringct step by step ?

what is the difference between a pseudo output commitment and a normal one? it is not explained anywhere in ztm i guess :(

Try with python 2.

python2 Test.py HPow2

import Crypto.Random.random as rand

ImportError: No module named Crypto.Random.random

Without wanting to sound paternalistic, I assume you installed all dependencies ?

dont know ...

slave_blocker2: section 5.4

hello UkoeHB ! :)

i did a sudo apt install python2

i dont know wich dependencys you are mentioning. The mininero repo does not ccontain instructions...

import foo -> dnf search foo (or similar for your distro)

import bar -> apt-cache search crypto

and now it spits import AggregateSchnorr

ImportError: No module named AggregateSchnorr

...

anyway, it works now :) . There is a bug there should be : import ASNL in the RingCT.py file .

Nice :) Not sure anyone is maintaining this, but a PR can't hurt.

are you saying a pull request ? never done that...

Another question, assuming that i finished this translation to portuguese of ztm 2.0, how can i hash the pdf and put that hash in the xmr chain? such that i could prove that it was me who owned it first?

This is even aluded to in the mininero repo :

"This written up research is hashed into the blockchain for timestamping purposes."

It was probably added in a plaintext payment id. They are now obsolete.

You could instead... sign the PDF itself with your secret key, and publish the signature alongside the PDF.

Then people can verify your monero address is the one that verifies the message.

Oh. I guess it doesn't include a height, which is what you want... So... sign height || PDF-contents.

You can also sign using a subaddress IIRC. If you have a recent enough monero tree.

hum,

updated seraphis perf results with some optimizations: monero-project/research-lab #91#issuecomment-1047191259

Thanks for working on this.

Ah, it turns out partial-batch-verifying grootle proofs led to ~30% speedup, since adding multiple proofs to one pippinger multiexponentiation is a speedup just by itself.

> The grootle proof verification optimization means Sp-Squashed at 128 ring size can be batch-verified faster than CLSAG with 16 ring size.

A bit over my head, but does this mean there is not a verification hit for jumping to 128 via Seraphis compared to verification after the next HF bumping to ring size 16?

That seems... big, as verification times were still much higher than current in previous estimates.

My main focus in learning more about the verification time implications of moves is to keep up with what to expect for IBD.

yes, 128 seraphis-squashed would be faster on average if you have a bunch of txs you can batch-verify with

what is IBD?

Initial block download, sorry

UkoeHB: Which would mainly be the case with IBD and nodes that are behind catching up with chain-tip, correct? Well, also with new blocks being verified by nodes as well, I think.

iirc the existing code doesn't batch-verify between blocks, so blocks with few txs would take a hit

Makes sense! Still huge news, wasn't aware of that being the case.

Makes me even more excited for Seraphis, as I was expecting a relatively large verification time hit :D

slave_blocker2: meme aside, it's really not necessary. Sending back to yourself is the same as sending to a different wallet, from the pov of the anonimity set

There is probably a bit more room for optimization, if you combine the BP+ and Grootle pippinger operations into one.