If anyone cares, I now have a working input selection solver: github.com/UkoeHB/monero/blob/serap…_tests/seraphis_input_selection.cpp . Unless I am missing some test case, this solver can find a solution in all but one edge case (when the only solution is a zero-change solution, but a non-zero-change solution is nominally found that then fails when taking into account the fee from adding a

change output; extremely rare).

Hello guys, it has been a bit hard to get started implementing Bulletproofs in Python as I don't have a nice material like ZtM to get started. Can someone tell me the best resources (other than the C++ code itself) to understand how Monero implemented Bulletproofs? Are there any general guide or scheme that people were following to implement it? The same question goes for BP+ too... Thanks in advance!

Ironically, IIRC I wrote the monero BP code by dumbly translating python code from sarang :)

And sarang went from the math, of course.

"the math" being here the Buenz paper IIRC.

dangerousfreedom: check the references in ztm2 section 5.5

there is some educational material linked

> If anyone cares, I now have a working input selection solver: github.com/UkoeHB/monero/blob/serap…_tests/seraphis_input_selection.cpp . Unless I am missing some test case, this solver can find a solution in all but one edge case (when the only solution is a zero-change solution, but a non-zero-change solution is nominally found that then fails when taking into account the fee from adding a

How does the input selecttion solver choose its inputs?

<moneromooo> "Ironically, IIRC I wrote the..." <- Hahaha nice to know :p

I saw multiexp function which I tested and is working exactly as in the C++ code but I didnt find a verification that works exactly as the Python one that I am looking at. Maybe I am using the wrong repo from Sarang from his skunkworks. Could you tell me which code did you use?

jeffro256[m]: github.com/UkoeHB/monero/blob/serap…src/seraphis/tx_input_selection.cpp starting with `try_get_input_set_v1()`at the bottom

It first tries to find a solution assuming zero change (this gives it a chance to find a zero-change solution), then if that fails (and the inputs selected in the first try aren't enough to cover the additional fee from adding a change output) it tries again assuming non-zero change.

<UkoeHB> "dangerousfreedom: check the..." <- Thanks UkoeHB . I have checked and I think that I understand the general idea but I am not trying to understand how Monero implemented it. :)

now*

I can't. If it's not in the commit message, it's lost to the ages. But most likely what's on his github repo, I doubt it's been rewritten.

Honestly I could probably simplify the solver so it doesn't even try to find zero-change solutions (since it is unreliable anyway), and only use custom input selection for sweep-type txs.

I don't think a zero change solution is wanted. A second output will be added (I think) in that case, and it'd be zero, which makes it statistically less likely to be spent.

So it doesn't gain anything, and possibly makes one thing worse.

moneromooo: Ok. Thank you for letting me know.

I will squeeze his repo a bit more ;)

moneromooo: very rarely, a zero-change solution might be the ONLY solution available

Would it not find it if it doesn't try to find it specifically ?

ie, zero chnge is a special case of any change.

you will only find it if you assume there is zero change, since sometimes non-zero change means increasing the output count (which increases the fee)

Only when sending more than one payment, right ? Because you'll always have at least 2 outs (assuming your scheme works the same as ringct).

right, or if sending yourself a 'self-spend', because in Jamtis you can't have a 2out tx where both outputs are self-send types (normal outs and self-send outs use different math)

posted this yesterday

if there is 1 self-spend and nonzero change, then you'll add a 0 amount dummy plus the change output

23:08atoc

Hey UkoeHB and sethforpivacy, I'd def like to work on Seraphis dev when the research is done. If you have any specific tasks, you need on the research side of Seraphis, lmk.

23:08atoc

sethforprivacy this seems cool: monero-project/research-lab #100 where is this at?

23:09atoc

it caught my eye in the list of open problems you shared earlier this week

UkoeHB Are you treating self-spends where the whole input (minus the fee) goes to yourself as a "zero-change"?

atoc: kayabaNerve has said he intends to work on a proof of concept

To rephrase, this means that if you send to yourself, you end up with a 3 out tx ? That seems fairly bad.

for Seraphis?

jeffro256[m]: correct, the self-send-type category has 'self-spends', 'change', and 'dummy self-send'

atoc: right

oh nice

where is this one at? monero-project/research-lab #100

it seemed interesting to me

would still like to do some dev work on Seraphis if needed

atoc: kayabaNerve has said he intends to work on a proof of concept

for Seraphis or monero-project/research-lab #100

both? seraphis as it relates to #100

ah I see

can I help out?

#100 seemed more about zk-snarks

moneromooo: yeah you get a 3-out tx, it's a cost of the self-send math that hides information from the find-received scanning key (which would be used by a third party scanner)

Right. It hasn't been my total focus for a few reasons, but it is something I'm working on :)

atoc: the simplest way we can use zk circuits is for a seraphis membership proof, so that's a good starting point to understanding how they would fit in monero

OK, then the wallet should warn hard about it, and people who really want to do that will be told to use two wallets. That'd work.

nice

alright, I'll keep looking then

moneromooo: ok yeah, this rule is because self-sends could have the same onetime address in a 2-out tx if they use the same destination address; if the 3-out rule is too much of a cost, you don't need to make a 'self-spend' type output, you can just make a normal output sending to yourself

UkoeHB: How would the self-spend structure affect the identifiability of churn transactions?

Rucknium[m]: If churn txs use 'sweep'-type commands, they would look the same as normal txs (with 2 outputs, since there would be 0 change). With non-zero change, you'd end up with 3-out txs (unless you are splitting amounts, in which case there could be more outputs).

The cost I see is that self spends become obvious, and people trying to improve their privacy would fail to do so (whether or not self spends help nowadays).

What is the advantage of a 'self-spend' type output, if you can make a normal output sending to yourself instead ?

(that's moot my concern)

All self-send type enotes (self-spends, change, dummy self-sends) will be mostly invisible to third-party scanning services. They will only see view tag matches for those enotes. A normal enote (sending to yourself) will also have a view tag match, but the scanner will see the destination's spend key + address tag (encoded address index). If the destination is randomly generated, then the spend key + address tag will be

indistinguishable from randomness, BUT if the scanner acquires the user's generate-address key, then they can decrypt the address tag which basically deanonymizes the destination.

enote means output, right ?

yes

A "dummy self-sends" is... sending yourself nothing ?

it's an optimization that helps third-party scanning with very little cost (an extra output will be added in only very rare cases)

basically you want every tx you create to have a self-send type in it

You know what, I've not kept up with this, so I'll stop there. I just want to say that making seld spends obvious is not good I think. But it looks like they can be made non-obvious, which is good. That's all.

I guess ultimately it's a wallet design choice how to handle sending to yourself (whether to use a self-spend type enote or a normal enote). Both have advantages

Anyway, it was good to re-evaluate the self-send design, thanks for the discussion