01:13:18 Multisig stuff is all out-of-band, right? Anybody working on a way to [privately] [interactively] build a multisig txn on chain? 01:35:46 Doesn't make sense afaict 10:04:04 I've update the protocol using the common dl proof, you can find it here: https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/dl-proof/whitepaper/xmr-btc.pdf 10:04:34 This would work if Bitcoin's opcode `OP_AND` was not disabled 10:05:50 Maybe we can turn around the protocol and disclose the private key share on the monero side 10:08:13 As I mentioned before this protocol can be implemented between ETH and XMR, with ethereum capabilities 11:27:37 h4sh3d: im convinced u have to disclose the secret key on the monero side. last night i brainstormed a bit in here: https://demo.codimd.org/QqrMAAIwSNy_L6xMQtJQWQ?both 11:28:34 basically an adaptor signature in monero commits to a public key that locks the swaplock in the btc side 16:30:40 moneromooo: ph4r05 noted that replacing the list of public keys in CLSAG hash inputs with a hash of the lists is better in the event that ring size scales significantly, so I might proactively change this 16:30:57 I don't expect such an increase, but it might reduce the necessary workload in the future if it were to happen 16:31:19 Any particular opinion on this? 16:31:45 It could also be worked into the prehash routine too, committing all keys as part of the signature message 16:32:03 As long as there's some commitment to keys somewhere, it should be fine 16:36:11 Hmm in fact, if the MLSAG prehash routine already includes all public keys and the commitment offset, we could remove the key data from the CLSAG signing routine altogether; it isn't clear if this is already happening 16:36:23 If it is, the key addition to the CLSAG round hashes is redundant! 16:36:33 * sarang will investigate 16:37:10 If it's new code anyway, might as well use the version that's an improvement, even if only slight. 16:37:22 Assuming it's not much more complicated than the one it replaces. 16:41:07 At worst, a single extra two-line device-specific function 16:41:26 really more for future-proofing 16:51:00 Ah yeah the message signed is 'all tx data except the signature itself'. Although it's the key offsets not keys directly 16:52:52 What should be included are the output keys, the commitment keys, and the pseudo-out commitments 16:53:07 which can be used to construct the actual keys that go into the signature 16:53:14 If that's what you mean UkoeHB_ 16:53:54 CLSAG only requires the offset keys (one of which is a comm. to zero), but the transaction should include the actual keys used to construct these sets-to-zero 16:54:17 And since you can derive the sets-to-zero from the original keys and pseudo-out commitments, the latter is fine 17:11:44 The message signed by MLSAGS is all data contained in a tx (except the MLSAG themselves). Tx store 'key offsets' which are the block chain indices for all ring members. The one-time addresses for those ring members are not signed 17:12:54 That poses an interesting conundrum about the relationship between offsets and keys 17:13:09 How so? 17:13:14 If the verifier has a different chain view than the prover did, then the offsets need not correspond to the proper keys anyway 17:13:27 It's an offset since indices are stored as relative offsets or each other 17:13:33 No, I get that 17:13:46 But I mean that the verifier is obtaining one-time keys from the offsets and their view of the chain anyway 17:14:19 Well the point of a chain is consensus. If they don't have the same view it's a big problem already right? 17:14:41 Yeah, but I'm trying to think through the consequences of different views when it comes to the signature itself 17:15:18 Since the verifier has to get the keys from the offsets anyway, from its perspective there's a 1-1 correspondence between offsets and keys anyway 17:15:41 and it has no other way (besides signature success) to know if that's the same view the prover had anyway 17:16:09 Sounds right 17:16:17 Meaning that I think this means it is safe to use only the MLSAG prehash message in the CLSAG round hashes, and not the added key lists obtained from the offsets 17:16:29 Since the signature message includes commitments to the offsets for the keys 17:17:27 UkoeHB_: does this seem reasonable to you as well? 17:17:52 e.g. CLSAG round hashes change from `hash(message,list_of_keys,signature_stuff)` to `hash(message,signature_stuff)` 17:17:53 Well I don't really understand what you gain from key prefixing in the first place 17:18:26 It means the prover can't produce signature data and select keys later in an attempt to game the construction 17:18:54 Committing to them assures the verifier that the prover knew the keys it was using in advance 17:19:02 (or could break the hash function, which we assume is not possible) 17:19:17 Well sure they could in your case. Just make a signature ahead of time, then put the keys you want at those indices 17:19:33 Not trivial, not impossible 17:20:14 Right, but in this case the offsets are what are used for the lookups 17:20:34 What would be better is including the keys, so the verifier knows it has the keys that the prover used 17:20:47 but in this case, the offsets are the only things used to obtain the keys in the first place 17:20:57 So "key prefixing" now means "offset prefixing" 17:21:03 Yeah but you could make it look up a future key that hasn't been added to chain yet, then later on fill that index after your signature is done 17:21:13 and the best we can do is assume the prover can't also game the chain structure too much 17:21:18 Then publish the signature in the end 17:21:42 Right, I agree that using only offsets has downsides 17:21:56 but I want to assure that we do the best we can given the way lookups happen 17:22:02 which would be index prefixing 17:22:38 Index prefixing already happens. The question seems to be whether to remove key prefixing 17:24:21 Given that at best, indices and keys always correspond, and at worst, the prover can select a key after the fact (and that the verifier can't detect this anyway as long as lookups happen), there is no advantage to key prefixing in addition to index 17:24:24 ^ is what I claim 17:24:33 But only because all verifier lookups happen by index 17:24:47 and therefore, key prefixing adds no additional security 17:27:37 I'm not sure how different that is from non-key prefixing in the normal case. Say you make a signature, no key prefixing. The verifier must learn a public key that makes the sig work, which he presumably learns from you. It would be the same if the signature included an index in its message (i = 1) and then told to find the public key in some table at that index. Which you filled in! 17:28:26 Basically. But the use of an index on the chain at least means that the prover could influence block packing 17:29:43 Well I'm trying to say that index prefixing doesn't really address the purpose of key prefixing, as I understand it 17:30:03 IMO it is an attempt at a partial incomplete solution, given the structure of the chain 17:30:09 Since key prefixing means the key was determined before the signature got made 17:30:17 Better than not including it, but not as ideal as removing index lookups altogether 17:30:46 If the prover can't directly influence block packing, then it's essentially key prefixing 17:30:54 if the prover can influence it enough, then it isn't sufficient 17:31:08 But he certainly can, or can with some probability 17:31:15 Anyone can make tx or mine blocks 17:31:49 Yes, this assumes the probability is low enough compared to the added complexity of having index prefixing 17:32:03 I am _not_ saying that index prefixing is equivalent to key prefixing in general 17:32:14 but I _am_ saying that statistically it's better than doing no prefixing 17:32:25 and since it's computationally trivial, might as well include it 17:32:36 Is there added complexity? It is directly included in the signed message already as the tx blob. More complex to remove it I think! 17:32:58 it = what? 17:33:07 the existing indexing, or the round-hash keys? 17:33:09 Key offsets (indices) 17:33:58 I think I'm being confusing here... I think that because the indexes are already included (and don't really cost much of anything), and because adding round-hash keys doesn't improve security at all, the best solution given the current setup is to remove the round-hash keys and rely instead on the prehash indices 17:34:19 So my proposal is to remove round-hash keys 17:34:37 (which has the added advantage of simplifying things for trezor/ledger, presumably) 17:34:46 Adding round-hash keys doesn't improve severity at all? 17:34:51 No 17:35:06 because they come from the index lookups anyway 17:35:40 they aren't included in the prover's committed transaction data 17:35:54 or rather, not in a way that's separately verified by the verifier 17:36:07 Hmm this goes back to my earlier argument that indices aren't equivalent to keys, since the keys can be set after the sig is done 17:36:18 Well, there are 2 possibilities 17:36:27 1. The prover cannot influence block packing 17:36:39 In this case, the indices and keys are equivalent, security-wise 17:36:42 Right? 17:36:58 Seems that way 17:37:13 2. The prover can influence what public key appears at a given index 17:37:28 In this case, it can select the index, generate the signature, and later pack a malicious public key at that index 17:37:36 Agreed 17:37:50 The verifier will use the index to look up its view of the public key at that index, and include it 17:38:01 It will find the key that the prover maliciously included 17:40:35 Hmm but this discounts that if the prover does this, the inclusion of the key in the round hash at least means that the signature fails both if the index-key combination is invalid (i.e. the block packing failed) or if the prover did not try to set the malicious key beforehand... 17:40:49 I think I get the case you mean here UkoeHB_ 17:41:40 An easy fix that's trezor/ledger-friendly is to include a hash of all the pubkeys, then, in the round hash 17:41:50 Meaning they don't need to all be passed to the devices 17:42:33 This is also simpler than modifying mlsag_prehash to a new clsag_prehash 17:43:27 Really depends on whether it's assumed that the prover can influence block packing with high enough probability 17:48:17 It's definitely way higher chance than solving dlp 17:49:02 Oh, for sure 17:49:04 (we hope!) 18:00:28 Doesn't seem like it's worth taking any risks 18:05:36 From my talks with ph4r05, the current ring size means passing the keys directly to the device isn't a problem 18:05:42 but would be for much larger ring sizes 18:05:56 so doing a key hash is future-proofing, if it's needed at all (CLSAG doesn't support large ring sizes well anyway) 18:18:08 If/when the project moves to an epoch-based next-gen protocol, I think it will be important to include both epoch index references and at least truncated hashes of epoch keys 18:19:01 This would also help to mitigate possible shenanigans from malicious remote nodes, since the client could cache epoch hashes and check the keys it receives from its remote node 18:19:16 (assuming that the original sync is valid) 18:23:53 Sounds good to me 😄