03:15:11 <Thomas[m]1> 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.
03:15:11 <Thomas[m]1> Are there any resources anywhere on how I am meant to choose the keyoffsets?
03:24:19 <gingeropolous> Thomas[m]1, have you discovered zero-to-monero ?
03:24:53 <gingeropolous> https://web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
03:26:58 <gingeropolous> that may help. But if I understand, choosing key offsets is indeed a tough problem.
03:27:41 <gingeropolous> 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
03:29:29 <gingeropolous> 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
03:31:57 <gingeropolous> 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
03:35:21 <Thomas[m]1> I have read zero to monero yes.
03:35:21 <Thomas[m]1> Unless I missed it, there is no mention of an algorithm though :/
03:35:58 <Thomas[m]1> Are the requirements / consideration on choosing key offsets documented somewhere?
03:51:07 <gingeropolous> i think there was a MRL report on it
03:52:24 <gingeropolous> Thomas[m]1, i think its here: https://www.getmonero.org/resources/research-lab/pubs/MRL-0004.pdf
04:04:18 <sarang> Anonymity set selection is highly nontrivial, and the current method is in no way claimed to be optimal
04:07:18 <gingeropolous> sarang, do you think it should be change for triptych, or if it aint broke ... ?
04:09:30 <sarang> Anonymity set selection for larger sets should almost certainly use binning at this point IMO
04:10:34 <gingeropolous> 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
04:10:39 <gingeropolous> and i forget what n is
04:11:42 <Thomas[m]1> thanks, those are already good pointers!
04:11:42 <Thomas[m]1> I'll dig into that and see where I end up.
04:11:56 <sarang> The current method is not a triangular distribution
04:12:06 <Thomas[m]1> <gingeropolous "and i forget what n is"> Should be possible to recover that from the implementation I presume
04:12:17 <sarang> It uses a modification from a preprint/paper by Miller et al. that approximates an expected spend pattern
04:12:26 <sarang> Weighted to account for non-uniform block densities
04:12:43 <gingeropolous> aah yes i remember that now
04:13:56 <Thomas[m]1> Is there any way in how I can leverage an existing monero daemon with that?
04:14:04 <Thomas[m]1> Possible also an instance of monero-wallet-rpc.
04:16:24 <Thomas[m]1> 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.
04:18:38 <sarang> Anonymity set selection is not (with few exceptions) consensus
04:19:11 <Thomas[m]1>  * 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.
04:21:27 <Thomas[m]1> And hence not implemented in monerod? Or what are you suggesting?
04:24:38 <gingeropolous> Thomas[m]1, i think he's suggesting its not in monerod, its in the wallet software.
04:24:57 <Thomas[m]1> okay, let me rephrase my question then :D
04:25:02 <gingeropolous> wallet2 i think is where its at
04:25:09 <Thomas[m]1> can I somehow leverage `monero-wallet-rpc` for this?
04:25:17 <gingeropolous> yeah
04:25:25 <Thomas[m]1> <gingeropolous "wallet2 i think is where its at"> Been down that rabbithole :D
04:25:37 <gingeropolous> i mean, monero-wallet-rpc can craft a transaction, so yes
04:25:57 <Thomas[m]1> I even looked into generated bindings for that thing (I am working in Rust) but failed unfortunately
04:26:11 <gingeropolous> i don't know if you can make it *just* give you a bunch of offsets ...
04:26:52 <gingeropolous> mobilecoin has rustified monero code, might have some luck in their repo
04:27:18 <gingeropolous> but they've taken different turns here and there
04:28:07 <Thomas[m]1> I had that idea as well but AFAIK they are on ristretto f.e.
04:28:07 <sarang> Wait, it this a mobilecoin question?
04:28:16 <Thomas[m]1> no, this is a monero question
04:28:32 <sarang> nods
04:28:41 <Thomas[m]1> I am working on XMR-BTC atomic swaps to give some wider context
04:29:01 <Thomas[m]1> and to have a protocol where XMR moves first, we need an adaptor-signature like construct
04:29:18 <Thomas[m]1> which implies fiddling with the signing algorithm
04:32:53 <kayabaNerve> Thomas[m]1: If you need low level wallet ops, I implemented most in Python
04:33:00 <kayabaNerve> May be easier to read than the C++
04:33:25 <kayabaNerve> It also directly binds to the gen_ringct_sig C++ function (which I didn't re-implement) instead of Wallet2
04:34:28 <Thomas[m]1> I assume you are talking about https://github.com/kayabaNerve/cryptonote-library?
04:34:57 <kayabaNerve> That'd be it
04:35:23 <kayabaNerve> As for XMR first atomic swaps, I wonder if you could generate an adaptor signature off of R...
04:35:52 <kayabaNerve> ... no, that doesn't work; never mind.
04:36:09 <kayabaNerve> Kinda spoke before I thought that through :P And to think I'm part of Farcaster
04:36:20 <Thomas[m]1> <kayabaNerve "Kinda spoke before I thought tha"> I know ;)
04:40:11 <Thomas[m]1> Am I right that here (https://github.com/kayabaNerve/cryptonote-library/blob/c39d956847e5ba2b46c2c4c90ab289ae1c04fe03/cryptonote/classes/wallet/wallet.py#L305-L355) is where you select the other outputs to be used for the key_offsets?
04:44:15 <Thomas[m]1> More specifically, you are just choosing a random output between the most recent block and the oldest one the wallet knows about?
04:44:15 <Thomas[m]1> https://github.com/kayabaNerve/cryptonote-library/blob/c39d956847e5ba2b46c2c4c90ab289ae1c04fe03/cryptonote/classes/wallet/wallet.py#L338-L341
04:44:15 <Thomas[m]1> I guess that works but might have implications for privacy?
04:59:07 <kayabaNerve> 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
04:59:37 <kayabaNerve> Because yes, its mixin distribution can be identified thanks to statistical analysis on when the mixins where created.
04:59:42 <kayabaNerve> Instead of 5 + 5, it'll just be *.
05:00:18 <kayabaNerve> I wanted to reply to his
05:00:19 <kayabaNerve> > i don't know if you can make it *just* give you a bunch of offsets ...
05:00:32 <kayabaNerve> I didn't scroll further up and realized you wanted not only offsets, yet properly chosen offsets.
05:01:24 <kayabaNerve> Just read up further; definitely not what you're looking for, sorry. Hopefully it at least helps with the bindings
05:01:56 <kayabaNerve> *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?
05:02:05 <Thomas[m]1> 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
05:02:05 <Thomas[m]1> 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.
05:02:28 <kayabaNerve> In that case, my work still should be generally applicable ;)
05:02:58 <kayabaNerve> 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.
05:03:01 <Thomas[m]1> Yes thanks for that!
05:03:01 <Thomas[m]1> It is a good confirmation that, at least technically, it is possible to choose them randomly if one accepts the privacy implications.
05:03:11 <kayabaNerve> There is still a threshold
05:03:35 <kayabaNerve> 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.
05:04:06 <Thomas[m]1> Okay, that is good now. I'll keep a look out for that.
05:04:11 <Thomas[m]1>  * Okay, that is good to know. I'll keep a look out for that.
05:50:57 <feusrtqtvgbu> 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.
08:41:27 <moneromooo> 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.
08:41:59 <moneromooo> The offsets it takes as input can be obtained from the daemon RPC.
08:42:21 <Thomas[m]1> Thanks for the pointer! I'll check out the tests.
15:09:53 <CCosta[m]> <gingeropolous "Thomas, have you discovered zero"> oooh, that's awesome! I wonder if we should have it under `CONTRIBUTING.md`
15:21:30 <gingeropolous> make a PR :)
15:41:26 <moneromooo> Daniel[m]13: https://github.com/monero-project/monero/pull/7662 probably fixes your test case. If not, let me know and give me more info about your setup.
17:08:43 <selsta> 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"
20:38:57 <selsta> .merges
20:38:57 -xmr-pr- 7349 7652 7653 7654 7655
21:04:43 <gingeropolous> aw, its not sync'd anymore?
21:05:38 <gingeropolous> selsta, done
21:37:51 <selsta> .merge+ 7002 7016 7136
21:37:51 <xmr-pr> Added
21:43:56 <selsta> .merge+ 7384 7641 7642 7648
21:43:56 <xmr-pr> Added
23:36:53 <selsta> luigi1111w: merges in the next days? ^-^