s/ irc.chknet

koe: something that could be interesting to add to ZtM is a listing of methods for proving transaction control

e.g. signing with a new MLSAG, etc.

Thoughts?

Like proving you authored a tx?

aye

There's already functionality to do this, and it might be nice to have documented

It's been on my list for a while

Oh no, koe has vanished

sarang: the punchline is that not only \mathfrak{I} but \mathfrak{W} needs to correspond to a ring member in the definition of unforgeability.

is there any way to prove you haven't spent an owned output yet, without revealing the key image?

signing with an MLSAG just proves you spent a particular input

Not that I can think of, since it's a key image set membership question

You'd need some proof of accumulator non-membership that plays nicely with the pubkey -> image mapping

1) same MLSAG new message: spent that input; 2) 1-tier MSAG (i.e. multikey-Schnorr) with transaction public key(s): authored the tx; 3) 1-tier LSAG with one time key and key image: own an output and reveal if it has been spent (also reveals when spent in future); 4) provide view key: reveals owned outputs and their amounts

Sarang: could we use a fully homomorphic crypto system in some way?

Sure it's inefficient

But you can do operations on encrypted values that way

So the proved would provide the system both the key image and associated tx, and the system would spit out whether the TX is spent or still valid

koe: there's also a version of (2) that works for incoming transactions

a sort of per-transaction version of (4)

Ive thought about this problem for a DEX swap market

I think you have to accumulate all key-images and outputs

vtnerd what is a DEX swap market? Atomic swap in Decentralized Exchange?

yeah if you wanted to a private decentralized BTC<->XMR or Tari<->XMR market

the idea came from Maxwell, because he mentioned a BTC ZKP for "I have at least x BTC at height y" that didn't leak/reveal the output for the proof

I wonder how the Binance DEX works rn

so I thought about the XMR case briefly, its actually harder because every output is "possibly" spent

It makes sense to use atomic swap for DEX

who is Maxwell btw?

AFAIK, you swap into binance coin on ETH and trade

Greg Maxwell, a prominent developer

Known for his work on bitcoin

Previously with Blockstream

Ah I have heard of him briefly

ah so reveal the shared secret rK_v, then sign using your view key k_v to prove you constructed it, and provide your address so they can check it corresponds with the owned output (they can also decode the amount)

koe: for the incoming proof? yes

That's the method for InProofV1 (the construction uses the same proof routine as OutProofV2, FWIW)

vtnerd: I thought they moved away from ETH

*OutProofV1

What's OutProofV1 specifically?

koe : ah yes sorry, I was commenting on a mechnism for proofing an XMR balance without revealing outputs which is related but different problem

*proving eh

You use the same two-key Schnorr proof, but sign with the tx private key to generate the shared secret, as opposed to signing with the private view key (which the sender doesn't know0

The verifier is assured that the prover knows either the tx privkey (for Out) or the recipient private view key (for In), as well as confirming the destination wallet address and giving visibility into the amount, Pedersen mask, and payment ID plaintext

no worries vtnerd, two conversations going here :p

two-key? what's the second key?

The proof shows the same tx privkey is used in both the shared secret and in the tx pubkey

(with respect to different bases)

So for standard addresses, showing R = rG and D = rA (in the outgoing case, using the code's notation)

For subaddresses, replacing the base G with the subaddress key B

wait, how are Out and In the same construction if they both sign with the tx private key? since recipients (InProovV1) dont know the tx private key

They don't

atoc : so to answer your question, binance DEX works because you swap tokens native to that chain

if its not native, then you are trading some sort of derivative, and who knows how that works

Yes that's correct, I forgot about the new Binance chain

For In, the recipient is showing they know the private viewkey to construct the shared secret, and showing that view key corresponds to the given public view key

does the base key change for In or Out? so In would be base key rG, and Out would be base key K_v?

Yes

or for In, rK_s if it's a subaddress

In the code, you swap the input base keys, and the secret signing value when calling the function

(and there's a different label applied so the verifier knows which is in use)

So one is InProofV1 and the other is OutProofV1

do you say two-key since it technically takes two keys as input: base key, and key for proof of knowledge?

It's showing the equality of a discrete log across different bases

(which depends on in vs out and standard vs subaddress)

ah, so also showing knowledge of r in rG (with base point G), or k_v in K_v (also base point G)

For an Out with standard, you're showing that R=rG and D=rA, given (R,D,A)

(and, given the public spend key, you can recreate the output to check its construction too)

For an Out with standard, you're showing that R=rB and D=rA, given (R,D,A,B)

For an In with standard, you're showing that A=aG and D=aR, given (A,D,R)

etc.

Same style of two-key Schnorr proof, different inputs

I think I see it now, sort of like a bLSAG with responses directed at two chunks of the challenge hash

FWIW the function could be simplified by taking all base points explicitly, instead of branching in the case where G is used

It's a pretty standard construction

If you look at the code, note that it doesn't actually include all the public points in the hash

I'm writing up a new version that does

Right now, only the shared secret is included as public parameter

Oh, and note that the proof also takes an arbitrary message that includes the tx hash and arbitrary data... so a verifier can require a fresh proof from a prover by specifying its own message (maybe include the datetime, purpose of the proof, etc.)

Anyway, I think a clear write-up of the different types of transaction proofs/assertions would be useful

since I doubt most people know you can safely do a per-transaction view

ok Ill look into this; for multisig you can collaboratively construct the key image ex-post, but Im not sure how it was implemented

is there an implemented proof of knowledge of an output's key image?

though the In/OutProofs could be applied to that use easily I think

ImageProof, something like that

Yes, that'd be equivalent to a single entry LSAG

I thought there was already such functionality but I am not locating it

It could simply be an `n=1` signature already

There's export functionality that does such signatures IIRC, so it exists _somewhere_

Another case for writing it up :)

Mainly because I think it will be useful for readers to know the differences between proof types and what information is or is not revealed to verifiers in the process

and also a good chance to revisit and review the proofs in code

ok Ill add a chapter with different proof methods, we are up to 9 now so what's a couple more anyway? might as well describe my escrowed marketplace protocol as well

I'm happy to write it up as well koe if you prefer

it should be fine, just a short one since there are only 2-3 things implemented

sarang if you want to be a coauthor Id be happy to accept a chapter draft for tx knowledge proofs. I'd be looking for information related to current proofs, future upgrades to those proofs, and non-implemented proofs that might be useful. And be warned I will ruthlessly edit the whole thing :D

fun fact: output selection depends in part on how 'related' outputs are; randomly found this get_output_relatedness() in the depths of wallet2.cpp

re: view-only wallet, knowledge of spent outputs. If the spend-key component of the key image is included in transaction data, then viewers can calculate (KI - KI_s) = H(rK_v)*H_p(onetime address)

no wait, that would allow senders to know when it's spent hm

ah here we go, multiply the KI_s by the view key's inverse, then viewers calculate (KI - k_v*KI_s) ?= H(rK_v)*H_p(onetime address)

question is how to enforce that at protocol

this idea is more of a convenience tool without protocol-level enforcement (additional 32 bytes per input); if a user wishes to hide some spends from view-key-authorized auditors, he may use a fake KI_vs

If this means a user who wants to has no way to prove to auditors everything is accounted for, it doesn't seem like a good idea.

If you want to segregate stuff, use another address.

they can still provide a list of key images

Why would they want to try and hide somehting from auditors when it can trivially be spotted ?

that's why it's convenience, since in an audit environment you still have to provide all key images

well supposing someone tried to pretend that it was adequate, when it isn't

"if a user wishes to hide some spends from view-key-authorized auditors, he may use a fake KI_vs" -> "this method is not sufficient for audit environments, since if a user wishes to hide some spends he may use a fake KI_vs"

it entails some more scanning, since each instance of a user's owned output in someone's ring must be checked, although the amount of checks would be far lower than finding owned outputs in the first place (current view-only method)

Isthmus might be interesting to know the spread on how often a given one time addresses is referenced as a ring member, at different times throughout history (e.g. in each minimum ring member region: min5, min7, fixed11)

and min3

This has been looked at

this?

koe do you plan on doing a writeup on the new RandomX algorithm?

no randomX is way outside my scope

and plus I dont understand it at all

mm I see

'hash function' it's magic!

I was looking for a section to look into it. It's new so I don't expect great documentation

yet*

hyc made a presentation, might get you started youtube.com/watch?v=4Hkd-n1W_e4&lis…wrHBkJHJg_l2uDgbicDJ1PmAVW&index=19

some great videos from that conference, suraeNoether did a stellar job