Good morning Nadav, > Hey Chris and all, > > Looking good :) I have one major concern though > > > q = EC privkey generated by maker > > Q = q.G = EC pubkey published by maker > > > > p = nonce generated by taker > > P = p.G = nonce point calculated by taker > > > > R = Q + P = pubkey used in bitcoin transaction > > = (q + p).G > > If I'm understanding this correctly (which I'm not sure I ame), it seems like > the plan is to put R on-chain as the key to an output? As stated this is > completely insecure as Q is known in advance so the taker can always choose a > nonce p but then claim that their nonce point is p.G - Q so that the key that > goes on-chain is (p.G - Q + Q) = p.G allowing them to steal the funds.
My reading from this is that nonce `p` has to be given by the taker to the maker outright. In original post: > Taker sends unsigned transaction which pays to multisig using pubkey Q, > and also sends nonce p. Thus, taker provides a proof-of-knowledge, i.e. the actual `p` scalar itself (not zero-knowledge, but what the maker needs is proof-of-knowledge, and could not care less if the proof is zero-knowledge or not). On the other hand, I do not see the point of this tweak if you are going to use 2p-ECDSA, since my knowledge is that 2p-ECDSA uses the pubkey that is homomorphic to the product of the private keys. And that pubkey is already tweaked, by the fresh privkey of the maker (and the maker is buying privacy and wants security of the swap, so is incentivized to generate high-entropy temporary privkeys for the actual swap operation). Not using 2p-ECDSA of some kind would remove most of the privacy advantages of CoinSwap. You cannot hide among `2 <A> <B> 2 OP_CHECKMULTISIG` scripts of Lightning, because: * Lightning channel closes tend to be weeks at least after the funding outpoint creation, whereas CoinSwap envisions hours or days. * Lightning mutual channel closes have a very high probability of spending to two P2WPKH addresses. You need to hide among the much larger singlesig anonymity set, which means using a single signature (created multiparty by both participants), not two signatures (one from each participant). Or is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH160 <hash> OP_EQUAL <A> OP_ELSE <time> OP_CHECKSEQUENCEVERIFY OP_DROP <B> OP_ENDIF OP_CHECKSIG`? This provides a slight privacy boost in a case (contract transaction publication) where most of the privacy is lost anyway. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
