08:44:03
dangerousfreedom:matrix.org:
I would certainly need your help kayabanerve . To understand the ideas and also the code.
08:45:10
dangerousfreedom:matrix.org:
I still dont know how big the task is but my approach would be starting from a high level of functionalities until the crypto operations. I might not get until the bottom but that is my goal now.
08:50:30
dangerousfreedom:matrix.org:
Three questions for you already:
08:50:31
dangerousfreedom:matrix.org:
1) How stable is the code so far? Do you still foresee changes in the verification/generation proofs?
08:50:33
dangerousfreedom:matrix.org:
2) What would be the most difficult part in your opinion?
08:50:36
dangerousfreedom:matrix.org:
3) Do you think that the crypto operations could be done with standard crypto libraries or there are some really new crypto operations and curves that are defined anywhere?
08:51:24
dangerousfreedom:matrix.org:
Three questions for you already:
08:51:25
dangerousfreedom:matrix.org:
1. How stable is the code so far? Do you still foresee changes in the verification/generation proofs?
08:51:28
dangerousfreedom:matrix.org:
2. What would be the most difficult part in your opinion?
08:51:29
dangerousfreedom:matrix.org:
3. Do you think that the crypto operations could be done with standard crypto libraries or there are some really new crypto operations and curves that are not defined anywhere?
08:52:31
dangerousfreedom:matrix.org:
I'm sorry. I'm still catching up with the latest developments and I have many questions that are already answered somewhere I think.
16:42:53
jeffro256:monero.social:
You will probably need to implement Helios / Selene curve operations in Python . don't think that that has a Python impl yet
16:52:05
rbrunner7:monero.social:
How much of the tree reading and tree management "stuff" will probably be needed for being sure that "there is no inflation"?
17:04:29
boog900:monero.social:
Cuprate will be reimplementing some tree management stuff, pretty much everything not done by Rust in monerod will have to be re'impld in Rust for Cuprate
17:05:36
boog900:monero.social:
I do wonder if instead of python a C/C++ rewrite would be better, with potential to modify to monerod to use that impl.
17:07:19
kayabanerve:matrix.org:
dangerousfreedom @dangerousfreedom:matrix.org: The GBP itself requires an update as identified by CS. The rest should be stable.
17:07:55
kayabanerve:matrix.org:
The most difficult part will be representing the same ordering of the matrii without simply copying the designed which effected that order in my code line-by-line
17:08:10
kayabanerve:matrix.org:
You will need Helios and Selene libraries, but that should be it.
17:08:38
kayabanerve:matrix.org:
boog900: CCS for a C++ rewrite welcome
17:08:55
kayabanerve:matrix.org:
Personally, I'd want a C++ rewrite with potential for Cuprate to use it /s
17:10:39
jpk68:matrix.org:
It would be convenient for monerod to not have Rust as a build dependency
17:29:40
dangerousfreedom:matrix.org:
To be sure that there is no inflation, the membership proofs should be verified. I'm willing to implement the minimum required to verify that. I dont know how much functionality the "tree stuff" has so far :p
17:29:53
dangerousfreedom:matrix.org:
Thanks for the answers kayabanerve
17:33:04
dangerousfreedom:matrix.org:
I dont have the intention with my proposal to change anything or to have it used anywhere in the main code. It is just for educational/prototype purposes. It might be that I find something interesting on the way that could bring discussions and fruits too. I dont know. But I'm definitely for implementations in all other languages, specially C++.
17:34:45
dangerousfreedom:matrix.org:
So maybe something that would be useful to me as well would be the basic crypto implementation in C++ with some bindings exposed. Like the Helios/Selene classes.
17:35:35
kayabanerve:matrix.org:
If you don't have to handle reorgs, as you don't, it is comparable to building a standard Merkle tree and shouldn't be too bad, just slow compared to building a standard Merkle tree due to the choice of hash fn.
17:36:25
kayabanerve:matrix.org:
FWIW, you _can_ bind Rust into the C ABI. It's fundamentally how monerod talks to the Rust libs.
17:37:41
dangerousfreedom:matrix.org:
Yes, thanks. I'm pretty sure I could do it but the idea would be to use a different crypto library for the basic operations.
17:39:35
dangerousfreedom:matrix.org:
Of course the results should be the same and that might sound a stupid idea but after thousands of crazy operations something weird might happen. Most likely errors in my code. So at least some discussions would appear from that.
17:41:21
dangerousfreedom:matrix.org:
But yeah, my plan was to initially use your bindings and have a top-down approach. As it makes more sense to me.
18:06:17
plowsof:
Rbrunner there is an unreviewed python implementation of polyseed i forgot to mention, not sure if useful for you
18:23:03
kayabanerve:matrix.org:
Agreed another impl of the curves would be true to spirit and beneficial :)
18:43:49
plowsof:
https://github.com/DiosDelRayo/polyseed-python
19:30:32
rbrunner7:monero.social:
plowsof: Thanks, didn't know that one, interesting. I only found one in Dart beside tevador's original. But this does not touch what I currently investigate and may implement for the core Monero software, because that will use the C++ code.
19:31:09
rbrunner7:monero.social:
MoneroSigner has somehow fizzled out, right? A bit of a pity.
19:35:05
jbabb:cypherstack.com:
I'm interested: what's that Dart example if you remember? I'm aware of the dart re-impl of a lot of monero math in https://github.com/mrtnetwork/monero_dart but I don't see polyseed in it
19:42:17
rbrunner7:monero.social:
Josh Babb: https://github.com/cake-tech/polyseed_dart.git
19:42:37
rbrunner7:monero.social:
I think I saw Cake Wallet using it, not sure, I looked at so many things ...