ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-20 📝 Original message:Good morning Nadav, > Hey ...
📅 Original date posted:2020-08-20
📝 Original message: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
Published at
2023-06-07 18:26:13Event JSON
{
"id": "302d93ecff3ddd66dd948ad93e9dc815e8ff8211a34f0b16911fbd53568956fa",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686162373,
"kind": 1,
"tags": [
[
"e",
"73a6325102a5be620da1390a6de4ad6fbfcf1dea8c17fc15805a6ae8270d97eb",
"",
"root"
],
[
"e",
"1f66f1f9c3ad2cc82e38456b8d12eaab60d1871d5616ed87a0223c8bf0cca15f",
"",
"reply"
],
[
"p",
"4640dfa33a2404507c1177a87aa949fcec805be1e1599e1df9bc823c35f5e208"
]
],
"content": "📅 Original date posted:2020-08-20\n📝 Original message:Good morning Nadav,\n\n\u003e Hey Chris and all,\n\u003e\n\u003e Looking good :) I have one major concern though\n\u003e\n\u003e \u003e q = EC privkey generated by maker\n\u003e \u003e Q = q.G = EC pubkey published by maker\n\u003e \u003e\n\u003e \u003e p = nonce generated by taker\n\u003e \u003e P = p.G = nonce point calculated by taker\n\u003e \u003e\n\u003e \u003e R = Q + P = pubkey used in bitcoin transaction\n\u003e \u003e = (q + p).G\n\u003e\n\u003e 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.\n\nMy reading from this is that nonce `p` has to be given by the taker to the maker outright.\nIn original post:\n\n\u003e Taker sends unsigned transaction which pays to multisig using pubkey Q,\n\u003e and also sends nonce p.\n\nThus, 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).\n\nOn 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.\nAnd 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).\n\nNot using 2p-ECDSA of some kind would remove most of the privacy advantages of CoinSwap.\nYou cannot hide among `2 \u003cA\u003e \u003cB\u003e 2 OP_CHECKMULTISIG` scripts of Lightning, because:\n\n* Lightning channel closes tend to be weeks at least after the funding outpoint creation, whereas CoinSwap envisions hours or days.\n* Lightning mutual channel closes have a very high probability of spending to two P2WPKH addresses.\n\nYou 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).\n\nOr is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH160 \u003chash\u003e OP_EQUAL \u003cA\u003e OP_ELSE \u003ctime\u003e OP_CHECKSEQUENCEVERIFY OP_DROP \u003cB\u003e OP_ENDIF OP_CHECKSIG`?\nThis provides a slight privacy boost in a case (contract transaction publication) where most of the privacy is lost anyway.\n\nRegards,\nZmnSCPxj",
"sig": "b57cee1a80bcec6b8633d03dd0cab4d2c9ee218dd5f88ec08bd01084f042a012ac91454bb741c0a6972dbe8074cb2280efff8c2b8078253bc62f8922fd42e453"
}