<t​ritonn:matrix.org> Basically just adding notes now, and sorting out whether there's anything I need to attribute. It's tough to tell because with some of this math, the end code looks basically the same if it comes from anyone who understands the concepts.

<t​ritonn:matrix.org> Just gonna refactor

<t​ritonn:matrix.org> PR created. Slixe may help me with more cleanup between now and the deadline, but no major changes left unless I fucked up bad somewhere

<o​murovch:matrix.org> Hey everyone! 👋

<o​murovch:matrix.org> I'm working on an Android app and looking to integrate a full Monero wallet directly into it — meaning no Wallet RPC or remote calls, just a fully local wallet on the device.

<o​murovch:matrix.org> What’s currently the best-supported or recommended approach for this?

<o​murovch:matrix.org> Any advice on libraries, tools, or wrappers that work well on Android? Ideally, I’m looking for something actively maintained and with good support for creating/syncing/restoring wallets locally.

<o​murovch:matrix.org> Appreciate any guidance or pointers. Thanks!

You would have to run a full (or pruned) Monero node to not make RPC calls to remote nodes, but then this node would have to run all the time and use even more traffic and battery than a regular wallet app. Running Monero node on a phone is not for everyone.

<o​murovch:matrix.org> Thanks for the input, @<sech1> — totally agree, running a full Monero node on a phone isn’t practical for most users due to resource constraints (battery, storage, bandwidth, etc.).

<o​murovch:matrix.org> To clarify: my goal is not to avoid all RPC calls, just to avoid relying on a remote wallet RPC server. I’m okay with using a local daemon (even pruned), as long as the wallet logic (keys, tx building, etc.) is fully local and under the app’s control — not delegated to an external monero-wallet-rpc process.

<o​murovch:matrix.org> Curious if anyone has experience embedding this kind of setup directly in an Android app — maybe using monero-java, JNI bindings, or anything similar?

<o​murovch:matrix.org> Appreciate all insights!

<r​brunner7:monero.social> There is a quite ambitious, Monero-community-funded project that in my understanding tries to implement *the* standard wallet SDK for Android, but I don't know where it currently stands: github.com/mollyim/monero-wallet-sdk

<s​yntheticbird:monero.social> 2 more weeks

<s​yntheticbird:monero.social> wow the ban was instant

<3​21bob321:monero.social> N + 2

.merge+ 9978 9977 9954 9953 9947 9946 9940 9838 9927 9925

Added

done, 9947 needs fix

9960 is easy, in case anyone wants to review

<b​inarybaron:matrix.org> Is it possible to construct a proof that does the following?

<b​inarybaron:matrix.org> a wallet with a given view key (can be shared publicly) did NOT receive any funds (or < than some amount) within a given block range WITHOUT having to scan all blocks in that block range to verify the proof.

<b​inarybaron:matrix.org> Probably a silly idea and I’d think it’s impossible but can’t hurt to ask and sometimes Monero tech can be quite magical so who knows

<b​inarybaron:matrix.org> What if the proof is narrowed down from „a wallet with a given view key“ -> „a specific stealth address of that wallet did not receive any funds“

.merge+ 9968

Added

tobtoht_: fixed 9947

ok all done

<o​frnxmr:xmr.mx> @tobtoht 9661 bump?

<r​ucknium:monero.social> binarybaron: I'm not sure, but maybe you could use this to show the absence of funds: Thakore, V., & Vijayakumaran, S. (2025). MProve-Nova: A Privacy-Preserving Proof of Reserves Protocol for Monero, Proceedings on Privacy Enhancing Technologies, 2025(2), 582–606. moneroresearch.info/266

<r​ucknium:monero.social> Or maybe check Vijayakumaran's earlier work in this area: moneroresearch.info/256 , moneroresearch.info/35

<r​ucknium:monero.social> because you might need something _less_ privacy-preserving than MProve-Nova.

<r​ucknium:monero.social> If you were to use MProve-Nova, maybe you could construct the auxiliary Merkle tree between two block heights instead of the whole blockchain history.

.merge+ 9960 9661 9958 9957

Added

done

<t​ritonn:matrix.org> Saw the Cargo.lock thing on the submission, Rust devops still finding ways to mess with me 😆

<t​ritonn:matrix.org> Tested with deleted Cargo.lock and commented on the PR about it, but ultimately, waking up after the deadline is waking up after the deadline.

<t​ritonn:matrix.org> Looking forward to hearing about the speed results of the submissions that came in either way

<s​yntheticbird:monero.social> Still thanks to your efforts and determination. Seeing you trimming over the contest and sharing your concerns and progress was insightful and stimulating.

<t​ritonn:matrix.org> I'll feel OK-ish about something this stupid if my submission benchmarks place well, even if something technical like this claws away the prize money lol

<k​ayabanerve:matrix.org> Silxe participated tritonn ? Interesting to hear.

<t​ritonn:matrix.org> I've been working with him on Xelis, he was going to do a runover of my stuff since he has more Rust-specific experience than I, but our schedules never lined up

<t​ritonn:matrix.org> I've been working with him on Xelis, he was going to do a runover of my stuff since he has more Rust-specific experience than I, but our schedules never lined up in time