Hi, I am looking at writing code to sign a monero transaction myself but I am stuck at _choosing_ key offsets. I had a look at the code of monerod and it looks quite complicated. Too complicated to understand the actual algorithm that is in place.

Are there any resources anywhere on how I am meant to choose the keyoffsets?

Thomas[m]1, have you discovered zero-to-monero ?

that may help. But if I understand, choosing key offsets is indeed a tough problem.

because basically you have to choose from all the available outputs in the blockchain which set of 10 will make it look like the real output is in a group of 11 random outputs

so if you choose 10 recent outputs, and your real output is a year ago, then, meh. Ring member selection is an area that warrants more attention, especially with the advent of triptych sigs

but if these offsets are indeed what you're talking about, its important to use the existing selection algorithm. because otherwise your group of ringmembers may look different than others

I have read zero to monero yes.

Unless I missed it, there is no mention of an algorithm though :/

Are the requirements / consideration on choosing key offsets documented somewhere?

i think there was a MRL report on it

Thomas[m]1, i think its here: getmonero.org/resources/research-lab/pubs/MRL-0004.pdf

Anonymity set selection is highly nontrivial, and the current method is in no way claimed to be optimal

sarang, do you think it should be change for triptych, or if it aint broke ... ?

Anonymity set selection for larger sets should almost certainly use binning at this point IMO

and Thomas[m]1 , i don't think an algorithm is described in that MRL report actually. but if i recall correctly, its a triangular distribution thats heavily weighted to the most recent n blocks

and i forget what n is

thanks, those are already good pointers!

I'll dig into that and see where I end up.

The current method is not a triangular distribution

<gingeropolous "and i forget what n is"> Should be possible to recover that from the implementation I presume

It uses a modification from a preprint/paper by Miller et al. that approximates an expected spend pattern

Weighted to account for non-uniform block densities

aah yes i remember that now

Is there any way in how I can leverage an existing monero daemon with that?

Possible also an instance of monero-wallet-rpc.

My usecase is a PoC where I am having some fun with the actual ring signature algorithm, hence I can't delegate the signing to the actual node. However, given the complexity of this, it would be very useful if I could somehow have monerod chose those keyoffsets for me.

Anonymity set selection is not (with few exceptions) consensus

* My usecase is a PoC where I am having some fun with the actual ring signature algorithm, hence I can't delegate the signing to the actual node. However, given the complexity of this, it would be very useful if I could somehow have monerod choose those keyoffsets for me.

And hence not implemented in monerod? Or what are you suggesting?

Thomas[m]1, i think he's suggesting its not in monerod, its in the wallet software.

okay, let me rephrase my question then :D

wallet2 i think is where its at

can I somehow leverage `monero-wallet-rpc` for this?

yeah

<gingeropolous "wallet2 i think is where its at"> Been down that rabbithole :D

i mean, monero-wallet-rpc can craft a transaction, so yes

I even looked into generated bindings for that thing (I am working in Rust) but failed unfortunately

i don't know if you can make it *just* give you a bunch of offsets ...

mobilecoin has rustified monero code, might have some luck in their repo

but they've taken different turns here and there

I had that idea as well but AFAIK they are on ristretto f.e.

Wait, it this a mobilecoin question?

no, this is a monero question

nods

I am working on XMR-BTC atomic swaps to give some wider context

and to have a protocol where XMR moves first, we need an adaptor-signature like construct

which implies fiddling with the signing algorithm

Thomas[m]1: If you need low level wallet ops, I implemented most in Python

May be easier to read than the C++

It also directly binds to the gen_ringct_sig C++ function (which I didn't re-implement) instead of Wallet2

I assume you are talking about github.com/kayabaNerve/cryptonote-library?

That'd be it

As for XMR first atomic swaps, I wonder if you could generate an adaptor signature off of R...

... no, that doesn't work; never mind.

Kinda spoke before I thought that through :P And to think I'm part of Farcaster

<kayabaNerve "Kinda spoke before I thought tha"> I know ;)

Am I right that here (github.com/kayabaNerve/cryptonote-l…/classes/wallet/wallet.py#L305-L355) is where you select the other outputs to be used for the key_offsets?

More specifically, you are just choosing a random output between the most recent block and the oldest one the wallet knows about?

I guess that works but might have implications for privacy?

Thomas[m]1: The README states how it's not optimal and should be improved; it only 'technically' works. I more wanted to refer to how it grabs mixins, not how it uses them

Because yes, its mixin distribution can be identified thanks to statistical analysis on when the mixins where created.

Instead of 5 + 5, it'll just be *.

I wanted to reply to his

> i don't know if you can make it *just* give you a bunch of offsets ...

I didn't scroll further up and realized you wanted not only offsets, yet properly chosen offsets.

Just read up further; definitely not what you're looking for, sorry. Hopefully it at least helps with the bindings

*I brought up 5 5 because I thought Monero used 5 outputs from 0 .. X, where X is two weeks ago, and then 5 from the last two weeks. Did Monero ever use an algorithm like that?

Well, ultimately, I just want to sign a transaction locally. Having to choose offsets is - for my particular usecase - more of an annoying necessity :D

Hence my question whether or not I can offload to some other software. But I guess the answer for now is no because that is the job of a wallet and what I am building is essentially a wallet.

In that case, my work still should be generally applicable ;)

But yes, it's vulnerable to identification of what wallet it uses and does have concerns for mixin identification depending on how quickly you use inputs.

Yes thanks for that!

It is a good confirmation that, at least technically, it is possible to choose them randomly if one accepts the privacy implications.

There is still a threshold

They have to be within X window. I have a MIN MIXIN constant defined *somewhere* with a comment. I think they have to be, om average, within the last 40% of mixins.

Okay, that is good now. I'll keep a look out for that.

* Okay, that is good to know. I'll keep a look out for that.

Howard, you know why all the 'Titanic intelligence Saviour of NASA' posts stopped last year? They know you are an embarrassment. Your arse didn't learn anything new in 25 years, and that includes C++. They just can't say it to your face.

There is no wallet RPC for this, but it sounds like a good one to add. There is code you can use though, see tests/unit_tests/output_selection.cpp, which uses tools::gamma_picker.

The offsets it takes as input can be obtained from the daemon RPC.

Thanks for the pointer! I'll check out the tests.

<gingeropolous "Thomas, have you discovered zero"> oooh, that's awesome! I wonder if we should have it under `CONTRIBUTING.md`

make a PR :)

Daniel[m]13: monero-project/monero #7662 probably fixes your test case. If not, let me know and give me more info about your setup.

gingeropolous: please update xmrchain.net to " most up to date software for Monero are version: CLI v0.17.2.0, GUI v0.17.2.1"

.merges

aw, its not sync'd anymore?

selsta, done

.merge+ 7002 7016 7136

Added

.merge+ 7384 7641 7642 7648

Added

luigi1111w: merges in the next days? ^-^