Not sure how much the community will like this, but if there's any Python developers here, this may be useful. github.com/kayabaNerve/cryptonote-library

It's a CN/Monero library I wrote last year and just got permission to open source. It handles TX structure/serialization, keys, payment ID and subaddresses, commitments, finding spendable transaction outputs, encoding/decoding the extra field... only calls out to C for key image creation/RingCT signing.

Unfortunately, it was built for Monero v12, so it's been unusable for a few weeks now. May still be a good look at the crypto/potential base to build off of if anyone needs a Wallet + WatchWallet solution?

But just using the wallet2 API may be better for a long term solution. Not sure. Just wanted to post about an alternative.

kayabaNerve: Do you plan to update it to make it compatible with CLSAG?

dEBRUYNE: Not really. If it only requires updating the struct/serialization code, as in, the signing API is the same than maybe? I think it may be like that, yet I haven't touched this code in a whille and didn't feel like stting up the test environment to find out to be honest

From the looks of it, it does not include tx validation. Is that correct ?

moneromooo: It isn't a light wallet, as it needs to be paired with a trusted RPC connection. That said, it does fully verify transaction outputs.

As in, it discovers spendable transactions, rebuilds commitments, handles miner outputs and regular outputs...

THe distinction is it doesn't do any chain inclusion proofs/SPV tracking

Or were you thinking of something else?

I was thinking of rct validation and BP/Borromean validation. As in, verifying commitments sum to 0, that kind of thing.

Got it. That was something I never really considered tbh. Always would've thought as that as out of scope

Well, you get to define the scope of your own software/

I think having an independent progam to verify rct would be good, to detect whether there is a bug in the monero implementation.

Long, longstanding wish list :)

why would you trust the independent impl more?

I have a voice now?

Oh, cool.

moneromooo: Ha! I didn't, actually :P It was a contract for a third party

You would likely not.

But yes, now that it's FOSS hosted by me, I do.

hyc: The point is cross checking.

A difference tells you you need to look into it, not trust any one more,

So if one acts up, you can figure out which one it is. You can trust the independent impl is the better one, but you can debug to find out exactly.

I'll let moneromooo cover it :P Sorry for intruding.

I actually did look for any other RCT libraries. Using the internal C API was annoying to figure out

All I found was some incomplete Python code from before the v12 testnet. Pretty sure it was for MLSAG though.

(not that it'd be fast enough for anything beyond pure cross testing anyways)

Even my code scrapes the threshold of tolerable speed, and that's for small-medium sized services.

random idea. for d++ stemming, perhaps a node should prefer sending to nodes in its "--add-priority-node" first

it sort of build on the web of trust idea

presumably, you've added these peers because you trust them over the random collection provided by the network

seems that's more recognizable than a random pick

and you can leverage that reciprocal implied trust, so if A trusts B, then B can somehow.... no that won't do

well, if A trusts B, and A always sends to B, and if B is connected to all AHP, i guess it fluffs anyway

from A

v0.17.1.3 binaries are out on getmonero.org, great job good people

++

ideally all seed nodes would update to v0.17.1.3 and apply this block list gui.xmr.pm/files/block.txt with --ban-list flag

I guess it would be helpful for as many nodes as possible to update to that version so fewer one-hop-away-from-seed nodes connect to AHPs?

should it be possible to run --anonymous-inbound without --tx-proxy?