From: Chris Belcher <belcher@riseup•net>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>, Nadav Kohen <nadav@suredbits•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Thu, 20 Aug 2020 23:37:35 +0100 [thread overview]
Message-ID: <f0bce6e1-c116-6282-73c8-b75c0dfa62bf@riseup.net> (raw)
In-Reply-To: <eoSHJi6wcD_oq5w9XBzj91Q8bn_fGKIjyQ_F1xxKDUhuyjhKeJrUXVE315lC0G9VrN7DakXC-D9Yds7DQ5TVaHai_caCAnugp7SsgFYaH_Y=@protonmail.com>
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.
next prev parent reply other threads:[~2020-08-20 22:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 12:05 Chris Belcher
2020-08-20 11:17 ` ZmnSCPxj
2020-08-20 15:28 ` Nadav Kohen
2020-08-20 21:38 ` ZmnSCPxj
2020-08-20 22:37 ` Chris Belcher [this message]
2020-08-20 22:15 ` Chris Belcher
2020-08-21 4:20 ` ZmnSCPxj
2020-08-21 9:47 ` Chris Belcher
2020-08-22 1:09 ` ZmnSCPxj
2020-08-24 19:30 ` Antoine Riard
2020-08-25 3:16 ` ZmnSCPxj
2020-09-03 9:00 ` Chris Belcher
2020-09-03 9:45 ` ZmnSCPxj
2020-09-03 10:50 ` Chris Belcher
2020-09-03 23:39 ` ZmnSCPxj
2020-09-05 2:45 ` ZmnSCPxj
2020-09-05 1:10 ` Antoine Riard
2020-09-05 2:29 ` ZmnSCPxj
2020-08-29 22:03 ` Chris Belcher
2020-08-30 13:38 ` ZmnSCPxj
2020-09-05 1:07 ` Antoine Riard
2020-09-06 3:06 ` seid Mohammed
2020-10-03 10:36 ` [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher
2020-10-03 13:31 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f0bce6e1-c116-6282-73c8-b75c0dfa62bf@riseup.net \
--to=belcher@riseup$(echo .)net \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nadav@suredbits$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox