14:31:25 Hello all 15:07:24 sarang: hi. is Pedro Moreno-Sanchez in this chat room? 15:07:47 Not that I know of 15:09:32 https://eprint.iacr.org/2019/595.pdf Figure 3, says the keygen process should generate a random bitstring m. but when someone opens a payment channel, who generates m and how would they share it with each other? im thinking of putting it in the signature. 15:10:59 along with all the other ms from other signatures of course 15:14:46 They're defined using hashes of public transaction data when generated 15:15:12 hmm interesting 15:15:33 This isn't made explicit in that figure, but is discussed at several other points in the paper 15:15:56 Keep in mind, of course, that the DLSAG construction suffers from a tracing issue due to its linking tag construction 15:16:13 oh i didnt know 15:17:26 Yeah, I wanted that to be made much more upfront in the paper (it is mentioned, FWIW) 15:17:51 This issue can be solved with a self-spend on receipt of funds, but this operation can't be protocol-enforced 15:17:59 meaning it relies on user action for safety 15:18:21 We've tried to replicate the functionality of DLSAG without linear linking tags, but have not found a solution yet 15:18:30 (the linearity of the tags is what ruins things) 15:18:31 ouch 15:18:44 i already implemented a version 15:18:51 should have read the entire paper first lol 15:19:12 section 3.1 speaks of this tracing issue 15:19:42 im assuming these self spends should be done using other signature schemes like CLSAG 15:20:29 The issue is mentioned on page 6 and again on pages 23-24 15:20:39 I really wanted it to be mentioned immediately 15:20:40 :( 15:20:48 its ok 15:20:54 it is a fun exercise for me anyways 15:20:56 No, the self-spends can use DLSAG 15:21:04 oh ok 15:21:11 Because then the sender and receiver of the self-spend operation are the same entity 15:21:34 Of course, the timing of self-spends could lend itself to additional adversarial heuristics 15:21:43 but that was not examined in the scope of the paper 15:21:58 :( 15:22:34 Although hidden timelocks do mitigate this somewhat :) 15:23:11 i havent got to those in the paper. i assume it is like amount hiding but for block heights 15:23:32 Yep, the timelock is hidden using a Pedersen commitment 15:23:40 nice 15:23:45 and the signature construction is further modified to account for this 15:23:57 The hidden timelock construction could be used outside of DLSAG too 15:24:15 It's been examined by a few researchers in the context of the current Monero protocol 15:24:42 It would introduce a nontrivial addition to verification time, but is quite reasonable in terms of size 15:25:15 but is a very clever approach 15:26:18 im frankly amazed after reading Z2M2 by UkoeHB_ . all of it is very clever. mere mortals like me can only appreciate the music but never create it 17:51:56 maybefbi: keep in mind Monero has been, and continues to be, developed in a very incremental fashion. Most complex human constructions materialize that way. 17:52:25 We all stand on the shoulders of giants, as they say 17:52:45 Better than on their feet. 18:24:44 If I have not seen as far as others, it is because they were standing on my shoulders 18:25:14 and blocking my view 18:27:32 The lesson is to avoid wearing tall hats in theatres 19:18:35 Omniring received a small but important update: https://eprint.iacr.org/2019/580 19:19:01 Another researcher and I independently pointed out a problem with a particular inversion step that didn't work in the original paper 19:19:27 They posted the update publicly last month after fixing this 19:20:20 Always a bit of a feather-in-your-cap to be listed in the acknowledgements of a paper :D 19:25:22 nice 19:28:16 cool 19:29:26 I guess this might be fairly tangential, but it would be quite cool if it was possible to have a Monero stablecoin. Unfortunately I can't think of a way to make it work 19:30:11 what makes any stablecoin work? 19:30:28 the ability to sell it for the peg :P 19:37:07 speaking of incremental improvements, it seems we can reduce the 48-byte Janus Schnorr proof to 32 bytes (or even 16 bytes); however... it is a bit messy since we still need 48-byte proofs for 2-out tx 20:18:43 updated https://github.com/monero-project/monero/issues/6456, important part is Proposal Part 2 (new) method 3: 32-byte consolidated Schnorr proof. sarang would you mind taking a look? It's a new/unusual kind of proof dynamic 20:20:19 Im wondering if we could reduce the 32-byte proof to 16 bytes (e.g. only use a 16-byte response, and 16-byte challenge) by constraining the tx private key to 16 bytes. Doing so would also reduce the 48-byte proof to 32 bytes. 22:03:39 Yeah nvm, rather than unique it's just a convoluted way of encoding the tx private key. Now that I think about it, we might be able to do away with Janus proofs altogether and just use encoded tx private keys. What were the objections to encoding the tx private key in the past? knaccc 22:09:34 the ignorant one is posting a link, hopefully it is meaningful 22:09:38 https://twitter.com/SomsenRuben/status/1259880539907129347 22:09:39 [ Ruben Somsen ⚡️🇳🅾️2️⃣❎ on Twitter: "SAS: Succinct Atomic Swaps The #Bitcoin block subsidy is not the only thing that's halving today! A regular atomic swap takes 4 transactions. What if I told you w ] - twitter.com 22:28:21 UkoeHB_ i'm trying to remember, i guess you're saying you'd need to encode a tx private key per non-change output, right? 22:37:35 Right, only costs 32 bytes at most instead of 48 bytes. Then for change outs modify how derivation_to_scalar is computed (e.g. prefix with the private view key) to make the non-change out's knowledge of the tx private key irrelevant. 22:38:58 By doing that we wouldn't need an separate change tag to encode the amount, since the entire change output would be encoded with a change tag essentially 22:39:28 It's kind of annoying, but the other option is 48-byte schnorr which is 16 bytes more expensive 22:39:29 i'm trying to think about implications for tx proofs when the tx private key is no longer only known to the sender 22:40:09 since there is the "here is another ring signature for the same key images being spent" tx proof, i guess maybe it's not a loss 22:40:21 Yes OutProofs no longer prove you created an output, so you'd also need a SpendProof. However, solo OutProofs are still sufficient to prove about a recipient 22:40:41 Unfortunately OutProofs would need a special construction for change outs, which is really annoying too 22:40:50 and one could argue that having many differnet types of tx proof was confusing anyway, so why not just have one type that is always used, regardless of whether you remembered the tx priv key or not 22:41:27 i'm trying to remember, currently, is there a different txprivkey per output? 22:41:48 Only sometimes 22:42:07 >=3 outputs is where you have multiple txprivkeys right? 22:42:52 In the new construction it would be that way yes, and in the current construction it's more situational 22:43:02 how is it done currently 22:43:06 what are the situations 22:43:37 There are multiple tx private keys when there are at least 2 non-change outputs and at least one of them is a subaddress 22:44:46 it basically mirrors situations where there is more than one tx pubkey specified, right? 22:45:11 Yes tx pub keys always have their own tx private key 22:47:25 The tradeoff here is ~16 bytes per transaction vs a lot of development hassle 22:48:04 you're saying that encrypting and sending the txprivkey is more dev hassle than adding the janus schnorr proof? 22:48:27 Yeah, due to 2-out tx where there is only 1 tx pub key 22:48:53 so what are you proposing in that scenario 22:49:06 So change outs need a special construction that has broad repercussions 22:49:24 it does sound a little messy 22:50:45 The basic problem is if I know the tx private key for someone else's output, then I could figure out who they are by testing known addresses. 22:50:46 so change output is Hs( Hs(a||r)A )G+B instead of Hs(rA)G+B? 22:51:10 Yeah that's the gist of it 22:51:38 that doesn't sound like that much of a hassle 22:51:53 oh wait 22:51:53 More like H(a, rA)G + B 22:52:06 ok i see 22:52:23 is there a scanning time implication therE? 22:52:26 Well you have to keep track of change outs.. and then always apply the change out computation 22:52:55 No, since we can use view tags 22:54:00 ah ok yes i see 22:54:01 Also OutProofs need some massaging to get them to work 22:54:35 Without revealing the view key 22:54:52 yeah it feels a bit messy, but it does the job 22:55:16 i'll see if i can think of any other implications of divulging the txprivkey 22:56:20 I also wonder if we can use a smaller tx private key, maybe 16 bytes. At that point Janus mitigation would be very cheap 22:57:31 that sounds like playing with fire 22:57:33 Hmm there may be a way around the change out nonsense by exploiting view tags 22:58:33 on what basis are you saying that a DH exchange would not need a full 32-byte scalar? 22:59:01 Well I imagine 31 byte tx private keys would be ok, so is there a limit how small they can go? I wonder what sarang thinks 22:59:44 More of a wondering and less of a real basis :p 23:00:23 i mean it does make intuitive sense to me that txprivkey=Hs(16 byte random scalar) should deliver a 128-bit security level actually 23:00:30 And it only matters since it would reduce on-chain storage for the solution we are discussing 23:01:29 i think you are onto something 23:04:32 i guess it's a question of defense-in-depth and quantum resistance 23:16:04 For the change output, instead of altering derivation-to-scalar which is a core part of the tx protocol, make a 'hidden tx pub key' deterministically from the encoded non-change tx private key + the tx author's view key. This is cheap because of view tags. There are 2 tags: non-change tag and change tag. First compute the sender-receiver shared secret like normal with k_v*R, then the two view tags H("view", 23:16:04 k_v*R), H("view", k_v*R, k_v). If the former matches e.g. the first view tag in a tx, then set output index = 0 and check if the output is owned like normal. If it is owned then decode the tx private key and use it to check the tx pub key is legitimate. If the former matches e.g. the second view tag in a tx then set output index = 1 and compute the hidden tx private key r_hidden = H(r_encoded, k_v), and 23:16:04 hidden tx pub key R_h = r_hidden*G, then compute the shared secret k_v*R_hidden and use that to see if the output is owned. If it's owned, the Janus test automatically passes. 23:20:44 Anyway I'll update the proposal so it's more clear 23:24:34 Reducing the complexity of private keys sounds unwise 23:30:04 Regarding OutProofs.. I don't believe they work for all change outputs currently. Not that I can see a point to proving you sent yourself something 23:33:26 The workaround is an InProof + SpendProof 23:35:05 sarang idk how I feel about you crushing my hopes and dreams 😢 23:38:36 Replace all signatures with a written promise that you didn't cheat :D 23:48:06 knaccc: suppose you used `H(1 bit scalar)` as an extreme example... 23:50:24 It seems hard to get an attack that's better than brute force. 23:50:55 But if you're restricting your search space, brute force itself becomes easier