12:26:30 s/ irc.chknet 13:50:05 koe: something that could be interesting to add to ZtM is a listing of methods for proving transaction control 13:50:22 e.g. signing with a new MLSAG, etc. 14:14:43 Thoughts? 14:24:33 Like proving you authored a tx? 14:25:04 aye 14:25:35 There's already functionality to do this, and it might be nice to have documented 14:25:42 It's been on my list for a while 14:25:50 Oh no, koe has vanished 15:12:50 sarang: the punchline is that not only \mathfrak{I} but \mathfrak{W} needs to correspond to a ring member in the definition of unforgeability. 18:07:43 is there any way to prove you haven't spent an owned output yet, without revealing the key image? 18:08:35 signing with an MLSAG just proves you spent a particular input 18:11:24 Not that I can think of, since it's a key image set membership question 18:11:50 You'd need some proof of accumulator non-membership that plays nicely with the pubkey -> image mapping 18:14:15 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 18:18:39 Sarang: could we use a fully homomorphic crypto system in some way? 18:18:48 Sure it's inefficient 18:19:07 But you can do operations on encrypted values that way 18:19:46 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 18:21:35 koe: there's also a version of (2) that works for incoming transactions 18:21:42 a sort of per-transaction version of (4) 18:21:52 Ive thought about this problem for a DEX swap market 18:22:28 I think you have to accumulate all key-images and outputs 18:26:12 vtnerd what is a DEX swap market? Atomic swap in Decentralized Exchange? 18:26:53 yeah if you wanted to a private decentralized BTC<->XMR or Tari<->XMR market 18:27:43 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 18:28:27 I wonder how the Binance DEX works rn 18:28:30 so I thought about the XMR case briefly, its actually harder because every output is "possibly" spent 18:28:40 It makes sense to use atomic swap for DEX 18:28:50 who is Maxwell btw? 18:28:55 AFAIK, you swap into binance coin on ETH and trade 18:29:05 Greg Maxwell, a prominent developer 18:29:13 Known for his work on bitcoin 18:29:30 Previously with Blockstream 18:29:37 Ah I have heard of him briefly 18:29:42 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) 18:30:22 koe: for the incoming proof? yes 18:30:47 That's the method for InProofV1 (the construction uses the same proof routine as OutProofV2, FWIW) 18:31:13 vtnerd: I thought they moved away from ETH 18:31:27 *OutProofV1 18:31:37 What's OutProofV1 specifically? 18:31:45 koe : ah yes sorry, I was commenting on a mechnism for proofing an XMR balance without revealing outputs which is related but different problem 18:31:55 *proving eh 18:32:17 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 18:33:24 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 18:34:06 no worries vtnerd, two conversations going here :p 18:35:23 two-key? what's the second key? 18:35:58 The proof shows the same tx privkey is used in both the shared secret and in the tx pubkey 18:36:02 (with respect to different bases) 18:36:39 So for standard addresses, showing R = rG and D = rA (in the outgoing case, using the code's notation) 18:36:50 For subaddresses, replacing the base G with the subaddress key B 18:38:26 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 18:38:37 They don't 18:38:41 atoc : so to answer your question, binance DEX works because you swap tokens native to that chain 18:39:09 if its not native, then you are trading some sort of derivative, and who knows how that works 18:39:35 Yes that's correct, I forgot about the new Binance chain 18:39:39 https://cryptovest.com/news/binance-to-introduce-derivative-coins-pegged-to-bitcoin-btc/ 18:40:18 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 18:42:40 does the base key change for In or Out? so In would be base key rG, and Out would be base key K_v? 18:43:01 Yes 18:43:06 or for In, rK_s if it's a subaddress 18:43:18 In the code, you swap the input base keys, and the secret signing value when calling the function 18:43:31 (and there's a different label applied so the verifier knows which is in use) 18:43:48 So one is InProofV1 and the other is OutProofV1 18:44:21 do you say two-key since it technically takes two keys as input: base key, and key for proof of knowledge? 18:45:59 It's showing the equality of a discrete log across different bases 18:46:27 (which depends on in vs out and standard vs subaddress) 18:46:46 ah, so also showing knowledge of r in rG (with base point G), or k_v in K_v (also base point G) 18:47:17 For an Out with standard, you're showing that R=rG and D=rA, given (R,D,A) 18:47:38 (and, given the public spend key, you can recreate the output to check its construction too) 18:48:38 For an Out with standard, you're showing that R=rB and D=rA, given (R,D,A,B) 18:49:06 For an In with standard, you're showing that A=aG and D=aR, given (A,D,R) 18:49:07 etc. 18:49:29 Same style of two-key Schnorr proof, different inputs 18:49:58 I think I see it now, sort of like a bLSAG with responses directed at two chunks of the challenge hash 18:50:00 FWIW the function could be simplified by taking all base points explicitly, instead of branching in the case where G is used 18:50:09 It's a pretty standard construction 18:50:59 If you look at the code, note that it doesn't actually include all the public points in the hash 18:51:05 I'm writing up a new version that does 18:51:30 Right now, only the shared secret is included as public parameter 18:52:25 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.) 18:55:05 Anyway, I think a clear write-up of the different types of transaction proofs/assertions would be useful 18:55:24 since I doubt most people know you can safely do a per-transaction view 18:58:35 ok Ill look into this; for multisig you can collaboratively construct the key image ex-post, but Im not sure how it was implemented 18:59:27 is there an implemented proof of knowledge of an output's key image? 18:59:58 though the In/OutProofs could be applied to that use easily I think 19:00:18 ImageProof, something like that 19:09:51 Yes, that'd be equivalent to a single entry LSAG 19:10:36 I thought there was already such functionality but I am not locating it 19:20:34 It could simply be an `n=1` signature already 19:24:07 There's export functionality that does such signatures IIRC, so it exists _somewhere_ 19:24:17 Another case for writing it up :) 19:24:42 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 19:25:01 and also a good chance to revisit and review the proofs in code 20:00:36 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 20:10:08 I'm happy to write it up as well koe if you prefer 20:10:57 it should be fine, just a short one since there are only 2-3 things implemented 20:27:33 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 20:38:07 fun fact: output selection depends in part on how 'related' outputs are; randomly found this get_output_relatedness() in the depths of wallet2.cpp 22:40:50 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) 22:41:36 no wait, that would allow senders to know when it's spent hm 22:44:27 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) 22:44:39 question is how to enforce that at protocol 22:52:24 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 22:53:54 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. 22:54:06 If you want to segregate stuff, use another address. 22:54:25 they can still provide a list of key images 22:54:48 Why would they want to try and hide somehting from auditors when it can trivially be spotted ? 22:54:51 that's why it's convenience, since in an audit environment you still have to provide all key images 22:55:23 well supposing someone tried to pretend that it was adequate, when it isn't 22:56:16 "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" 22:58:20 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) 23:09:58 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) 23:10:23 and min3 23:20:05 This has been looked at 23:23:12 this? 23:55:41 koe do you plan on doing a writeup on the new RandomX algorithm? 23:56:07 no randomX is way outside my scope 23:56:18 and plus I dont understand it at all 23:56:28 mm I see 23:56:48 'hash function' it's magic! 23:56:53 I was looking for a section to look into it. It's new so I don't expect great documentation 23:57:09 yet* 23:58:26 hyc made a presentation, might get you started https://www.youtube.com/watch?v=4Hkd-n1W_e4&list=PLsSYUeVwrHBkJHJg_l2uDgbicDJ1PmAVW&index=19 23:58:56 some great videos from that conference, suraeNoether did a stellar job