<d​angerousfreedom:matrix.org> I would certainly need your help kayabanerve . To understand the ideas and also the code.

<d​angerousfreedom: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.

<d​angerousfreedom:matrix.org> Three questions for you already:

<d​angerousfreedom:matrix.org> 1) How stable is the code so far? Do you still foresee changes in the verification/generation proofs?

<d​angerousfreedom:matrix.org> 2) What would be the most difficult part in your opinion?

<d​angerousfreedom: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?

<d​angerousfreedom:matrix.org> Three questions for you already:

<d​angerousfreedom:matrix.org> 1. How stable is the code so far? Do you still foresee changes in the verification/generation proofs?

<d​angerousfreedom:matrix.org> 2. What would be the most difficult part in your opinion?

<d​angerousfreedom: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?

<d​angerousfreedom: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.

<j​effro256:monero.social> You will probably need to implement Helios / Selene curve operations in Python . don't think that that has a Python impl yet

<r​brunner7:monero.social> How much of the tree reading and tree management "stuff" will probably be needed for being sure that "there is no inflation"?

<b​oog900: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

<b​oog900: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.

<k​ayabanerve:matrix.org> dangerousfreedom @dangerousfreedom:matrix.org: The GBP itself requires an update as identified by CS. The rest should be stable.

<k​ayabanerve: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

<k​ayabanerve:matrix.org> You will need Helios and Selene libraries, but that should be it.

<k​ayabanerve:matrix.org> boog900: CCS for a C++ rewrite welcome

<k​ayabanerve:matrix.org> Personally, I'd want a C++ rewrite with potential for Cuprate to use it /s

<j​pk68:matrix.org> It would be convenient for monerod to not have Rust as a build dependency

<d​angerousfreedom: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

<d​angerousfreedom:matrix.org> Thanks for the answers kayabanerve

<d​angerousfreedom: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++.

<d​angerousfreedom: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.

<k​ayabanerve: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.

<k​ayabanerve:matrix.org> FWIW, you _can_ bind Rust into the C ABI. It's fundamentally how monerod talks to the Rust libs.

<d​angerousfreedom: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.

<d​angerousfreedom: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.

<d​angerousfreedom: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.

Rbrunner there is an unreviewed python implementation of polyseed i forgot to mention, not sure if useful for you

<k​ayabanerve:matrix.org> Agreed another impl of the curves would be true to spirit and beneficial :)

<r​brunner7: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.

<r​brunner7:monero.social> MoneroSigner has somehow fizzled out, right? A bit of a pity.

<j​babb: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 github.com/mrtnetwork/monero_dart but I don't see polyseed in it

<r​brunner7:monero.social> Josh Babb: github.com/cake-tech/polyseed_dart.git

<r​brunner7:monero.social> I think I saw Cake Wallet using it, not sure, I looked at so many things ...