14:37:22 <sarang> Moving convo with TheCharlatan and kayabaNerve from -community to here
14:37:35 <sarang> Having a simple sum key seemed odd
14:37:58 <sarang> Either you could have rogue keys, and should compute the total key differently and with commitment, or it doesn't matter, and one party should do it all
14:38:36 <sarang> Even if that party could choose the key badly (fixed value, etc.) this is trivially possible with rogue keys anyway
14:38:39 <sarang> unless you precommit
14:51:50 <kayabaNerve> sarang: The DL EQ proof verifies key validity according to the modulus. Public keys clearly define the underlying key. VES signatures allow secure recovery.
14:52:12 <kayabaNerve> Mind filling me in on what I seem to be missing?
14:56:26 <zkao> as far as i understand, u do commit to moneros pub keys, but on the bitcoin side. if a rogue monero key is used, the bitcoin is lost for the attacker
15:52:07 <sarang> Well, the private view keys are shared between participants and summed, as are the spend public keys
15:52:22 <sarang> This means either party, depending on communication ordering, can set either value to whatever they wish
16:55:10 <zkao> i dont think anyone ever worked out the initialization in great detail, but h4sh3d  got contacted by coauthors of yours, if i recall correctly, to prove the security of the protocol. if u would have interest to work on that, let us know
17:06:25 <h4sh3d[m]> Yes, without the DLEQ proof this wouldn’t work. But if you choose the result A = B + C such as you know a instead of b (C is chosen by the other), you can’t compute the zkp that requires knowledge of b, thus the other participants must cancel the swap.
17:06:40 <h4sh3d[m]> But adding commit-reveal might be good anyway
17:12:13 <sarang> It depends on the consequences of a rogue or otherwise fixed known key