mrcyjanek/monero_c

wallet2_api.h (but this time C compatible)

Wrapper around wallet2_api.h that can be called using C api.

Building

to "clean" everything:

$ rm -rf monero wownero release
$ git submodule update --init --recursive --force

fix ownership (if you build in docker but clone as a local user)

$ sudo chown $(whoami) . -R

patch codebase

$ ./apply_patches.sh monero
$ ./apply_patches.sh wownero

build monero_c

$ ./build_single.sh monero  x86_64-linux-gnu -j$(nproc)
                    wownero i686-linux-gnu
                            aarch64-linux-gnu
                            x86_64-linux-android
                            i686-linux-android
                            aarch64-linux-android
                            arm-linux-androideabi
                            i686-w64-mingw32
                            x86_64-w64-mingw32
                            host-apple-darwin
                            host-apple-ios

While building I aim to compile the code at oldest supported release of debian, using default toolchain to ensure that all linux distributions are able to run monero_c libraries, below I present a supported builders for given targets

x	builder	notes
x86_64-linux-gnu	debian:buster
i686-linux-gnu	debian:buster
aarch64-linux-gnu	debian:buster
x86_64-linux-android	debian:buster
i686-linux-android	debian:buster
aarch64-linux-android	debian:buster
arm-linux-androideabi	debian:buster
i686-w64-mingw32	debian:buster	hardcoded DLL paths in build_single.sh
x86_64-w64-mingw32	debian:buster	-"-
x86_64-apple-darwin11	debian:bookworm	extra build step: ${HOST_ABI}-ranlib $PWD/$repo/contrib/depends/${HOST_ABI}/lib/libpolyseed.a
aarch64-apple-darwin11	debian:bookworm	-"-
host-apple-darwin	arm64-apple-darwin23	dependencies: brew install unbound [email protected] zmq cmake ccache autoconf automake libtool && brew link [email protected]
host-apple-ios	arm64-apple-darwin23

Design

Functions are as simple as reasonably possible as few steps should be performed to get from the exposed C api to actual wallet2 (or wallet3 in future) api calls.

The only things passed in and out are:

• void
• bool
• int
• uint64_t
• void*
• const char*

All more complex structures are serialized into const char*, take look at MONERO_Wallet_createTransaction which uses splitString(std::string(preferredInputs), std::string(separator)); to convert string into a std::set, so no implementation will need to worry about that.

Is there more effective way to do that? Probably. Is there more universal way to pass that (JSON, or others?)? Most likely. That being said, I'm against doing that. You can easily join a string in any language, and I like to keep dependency count as low as possible.

As for function naming ${COIN}_namespaceOrClass_functionName is being used, currently these cryptocurrencies are supported

• monero
• wownero

both using wallet2 api, and both being patched with our secret ingredient(tm) (check patches directory).

Since monero_c aims to be one-fits-all solution for monero wallets, there are some special things inside, like functions prefixed with DEBUG_*, these are not quarenteed to stay in the code, and can be changed, the only reason they are in is because I needed some testing early in the development when bringing support for variety of platforms.

If you are a wallet developer and you really need this one function that doesn't exist, feel free to let me know I'll be happy to implement that.

Currently there are enterprise resitents in our library: ${COIN}_cw_* these functions are not guaranteed to stay stable, and are made for cake wallet to implement features that are not used in xmruw nor in stack_wallet (which I need to double-check later?).

Contributing

To contribute you can visit git.mrcyjanek.net/mrcyjanek/monero_c and open a PR, alternatively use any other code mirror or send patches directly.

monero_c's Issues

Becoming stable

monero_c started as a rewrite to be used in only one wallet, but times have changed and now monero_c is also being used in xmruw, cake and stack, and with large amount of users and widespread adoption comes great responsibility, for this reason monero_c is becoming stable. What does that mean? Mostly turning branch protections on, all changes will come in separate PRs and adding other wallets into the CI to ensure compatibility across new revisions and to speed up testing of changes

TODO

• Rebase against v0.18.3.4 tag (once released) #14
• Add cake into the CI #15
• Cleanup patches (just a little bit)
• Create upstream version of monero_c (one without custom patches)
• merge monero.dart into monero_c repo #16
• throw errors when wrong wrapper is being used (embed git hash at build time)
• Pin iOS dependencies
• Cache sources on release builds (we sha256 them anyway)
• you tell me

Generated bindings

All of the code in here (and in monero.dart) should be autogenerated (it is not).

This involves parsing the upstream c++ header, generating corresponding C header, c++ wrapper, dart ffi wrapper, dart "actual" wrapper, and possilby even dart wrapper that respects the C++ classes.. In either case it is not happening for at least some time now because of the amount of work required to make this.