Hello Nadav and ZmnSCPxj,
On 20/08/2020 22:38, ZmnSCPxj wrote:
> 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).
Yes this looks right. In hindsight my text could be clarified by
changing the relevant lines to:
p = nonce generated by taker, sent to maker
P = p.G = nonce point calculated by taker
R = Q + P = pubkey used in bitcoin transaction, calculated by taker
= (q + p).G = same pubkey, calculated by maker
I don't think the key subtraction attack described by Nadav will work
here...?
> 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.
I completely agree that 2of2 multisigs made with OP_CHECKMULTISIG are
lacking in terms of privacy, and that 2p-ECDSA is much better. However
this whole protocol is quite complicated and I thought it would be a
good move to first implement it with OP_CHECKMULTISIG, to get all the
other details right (miner fees, coinswap fees, private key handover,
contract transactions, tor hidden services, watchtowers, etc etc) and
then add 2p-ECDSA later. Of course in that case all this tweaking of
public keys would be superseded by the 2p-ECDSA protocol.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
