Ruben Somsen [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-31 📝 Original message:Hi ZmnSCPxj, >Just to be ...
📅 Original date posted:2020-05-31
📝 Original message:Hi ZmnSCPxj,
>Just to be clear, you mean we can use the MuSig key-combination protocol
for the non-timelocked SAS output, but (of course) not the signing protocol
which is inherently Schnorr. Then knowledge of both of the original private
keys is enough to derive the single combined private key.
That's correct.
>basically private key handover gets us PayJoin for free
That assumes there will be a second transaction. With SAS I believe we can
avoid that, and make it look like this:
+---+
Alice ---| |--- Bob
Alice ---| |
Bob ---| |
+---+
This is basically what I was trying to explain in my previous email: "I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement)"
I don't have a strong opinion on whether it is actually useful to combine
CoinSwap with PayJoin.
>A thing I have been trying to work out is whether SAS can be done with
more than one participant, like in S6
S6 requires timelocks for each output in order to function, so I doubt it
can be made to work with SAS.
I've also tried applying SAS to partially blind swaps and ran into
likability issues, though it's less clear to me whether there is some
fundamental reason why it couldn't work there.
Cheers,
Ruben
On Sun, May 31, 2020 at 4:31 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Ruben and Chris,
>
> > >For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses
> >
> > This may perhaps be counter-intuitive, but SAS doesn't actually require
> multisig for one of the two outputs, so a single key will suffice. ECDSA is
> a signing algorithm that doesn't support single key multisig (at least not
> without 2p-ECDSA), but notice how for the non-timelocked SAS output we
> never actually have to sign anything together with the other party. We swap
> one of the two keys, and the final owner will create a signature completely
> on their own. No multisig required, which means we can simply use MuSig,
> even today without Schnorr.
>
> Just to be clear, you mean we can use the MuSig key-combination protocol
> for the non-timelocked SAS output, but (of course) not the signing protocol
> which is inherently Schnorr.
>
> Then knowledge of both of the original private keys is enough to derive
> the single combined private key.
>
> > Of course the other output will still have to be a 2-of-2, for which you
> rightly note 2p-ECDSA could be considered. It may also be interesting to
> combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
> want to open a channel with 1 BTC each, but Alice funds it in her entirety
> with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
> to tell Bob entered the Lightning Network, especially if the channel is
> opened in a state that isn't perfectly balanced. And Alice will gain an
> uncorrelated single key output.
>
> Dual-funding could be done by a single-funding Lightning open followed by
> an onchain-to-offchain swap.
> Though the onchain swap would have to be done, at least currently, with
> hashes.
>
> > >=== PayJoin with CoinSwap ===
> >
> > While it's probably clear how to do it on the timelocked side of SAS, I
> believe PayJoin can also be applied to the non-timelocked side. This does
> require adding a transaction that undoes the PayJoin in case the swap gets
> aborted, which means MuSig can't be used. Everything else stays the same:
> only one tx if successful, and no timelock (= instant settlement). I can
> explain it in detail, if it happens to catch your interest.
>
> I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much
> privacy.
>
> These transactions:
>
> +---+ +---+
> Alice ---| |--| |--- Bob
> Alice ---| | | |
> Bob ---| | +---+
> +---+
>
> Are not really much different in coin ownership analysis from these:
>
> +---+ +---+
> Alice ---| |----| |--- Bob
> Alice ---| | +--| |
> +---+ | +---+
> Bob ---------+
>
> The latter is possible due to private key handover, the intermediate
> output becomes owned solely by Bob and Bob can add many more inputs to that
> second transaction unilaterally for even greater confusion to chain
> analysis, basically private key handover gets us PayJoin for free.
> It also removes the need for Bob to reveal additional UTXOs to Alice
> during the swap protocol; yes PoDLE mitigates the privacy probing attack
> that Alice can mount on Bob, but it is helpful to remember this is "only" a
> mitigation.
>
> Now of course things are different if Alice is paying some exact amount to
> Carol, and Alice wants to dissociate her funds from the payment.
> The difference is then:
>
> +---+ +---+
> Alice ---| |----| |--- Bob
> Alice ---| |--+ | |
> Bob ---| | | +---+
> +---+ +--------- Alice Change
>
> +---+ +---+
> Bob ---| |----| |--- Carol
> | |--+ +---+
> +---+ |
> +--------- Bob Change
>
> Versus:
>
> +---+ +---+
> Alice ---| |----| |--- Bob
> Alice ---| | +--| |
> +---+ | +---+
> Bob ---------+
>
> +---+ +---+
> Bob ---| |----| |--- Carol
> | |--+ | |--- Alice Change
> +---+ | +---+
> +--------- Bob Change
>
> In the above, with PayJoin on the first-layer transaction, the Alice
> Change is correlated with Alice and Bob inputs, whereas with the PayJoin on
> the second the Alice change is correlated with Bob inputs and Carol outputs.
>
> But if Alice, using commodity CoinSwap wallets, always has a policy that
> all sends are via CoinSwap (a reasonable policy, similar to the policy in
> JoinMarket of ensuring that all spends out of the wallet are via CoinJoin),
> then the above two trees are not much different for Alice in practice.
> The Alice Change will be swapped with some other maker anyway when it gets
> spent, so what it correlates with will not be much of a problem for Alice.
> At the same time, with PayJoin on the second-layer transaction (possible
> due to private key turnover, which is an inherent part of the SAS protocol):
>
> * Bob does not have to reveal any other coins it owns to Alice other than
> what it is directly swapping, removing a privacy probe vector.
> * Bob can unilaterally combine more than one input to the second
> transaction going to Bob, which further increases the uncertainty of
> clustering around the inputs from Alice than just adding *one* input.
>
> ---
>
> A thing I have been trying to work out is whether SAS can be done with
> more than one participant, like in [S6](
> https://joinmarket.me/blog/blog/multiparty-s6/).
>
> So far, I have not figured out a way to make it multiparty (multihop?).
> Because the secret being transported is a private key that protects a
> specific UTXO, it seems it is not possible to safely use the same secret
> across more than two parties.
> Perhaps others have come ideas?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200531/eea6bdba/attachment.html>;
📝 Original message:Hi ZmnSCPxj,
>Just to be clear, you mean we can use the MuSig key-combination protocol
for the non-timelocked SAS output, but (of course) not the signing protocol
which is inherently Schnorr. Then knowledge of both of the original private
keys is enough to derive the single combined private key.
That's correct.
>basically private key handover gets us PayJoin for free
That assumes there will be a second transaction. With SAS I believe we can
avoid that, and make it look like this:
+---+
Alice ---| |--- Bob
Alice ---| |
Bob ---| |
+---+
This is basically what I was trying to explain in my previous email: "I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement)"
I don't have a strong opinion on whether it is actually useful to combine
CoinSwap with PayJoin.
>A thing I have been trying to work out is whether SAS can be done with
more than one participant, like in S6
S6 requires timelocks for each output in order to function, so I doubt it
can be made to work with SAS.
I've also tried applying SAS to partially blind swaps and ran into
likability issues, though it's less clear to me whether there is some
fundamental reason why it couldn't work there.
Cheers,
Ruben
On Sun, May 31, 2020 at 4:31 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Ruben and Chris,
>
> > >For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses
> >
> > This may perhaps be counter-intuitive, but SAS doesn't actually require
> multisig for one of the two outputs, so a single key will suffice. ECDSA is
> a signing algorithm that doesn't support single key multisig (at least not
> without 2p-ECDSA), but notice how for the non-timelocked SAS output we
> never actually have to sign anything together with the other party. We swap
> one of the two keys, and the final owner will create a signature completely
> on their own. No multisig required, which means we can simply use MuSig,
> even today without Schnorr.
>
> Just to be clear, you mean we can use the MuSig key-combination protocol
> for the non-timelocked SAS output, but (of course) not the signing protocol
> which is inherently Schnorr.
>
> Then knowledge of both of the original private keys is enough to derive
> the single combined private key.
>
> > Of course the other output will still have to be a 2-of-2, for which you
> rightly note 2p-ECDSA could be considered. It may also be interesting to
> combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
> want to open a channel with 1 BTC each, but Alice funds it in her entirety
> with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
> to tell Bob entered the Lightning Network, especially if the channel is
> opened in a state that isn't perfectly balanced. And Alice will gain an
> uncorrelated single key output.
>
> Dual-funding could be done by a single-funding Lightning open followed by
> an onchain-to-offchain swap.
> Though the onchain swap would have to be done, at least currently, with
> hashes.
>
> > >=== PayJoin with CoinSwap ===
> >
> > While it's probably clear how to do it on the timelocked side of SAS, I
> believe PayJoin can also be applied to the non-timelocked side. This does
> require adding a transaction that undoes the PayJoin in case the swap gets
> aborted, which means MuSig can't be used. Everything else stays the same:
> only one tx if successful, and no timelock (= instant settlement). I can
> explain it in detail, if it happens to catch your interest.
>
> I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much
> privacy.
>
> These transactions:
>
> +---+ +---+
> Alice ---| |--| |--- Bob
> Alice ---| | | |
> Bob ---| | +---+
> +---+
>
> Are not really much different in coin ownership analysis from these:
>
> +---+ +---+
> Alice ---| |----| |--- Bob
> Alice ---| | +--| |
> +---+ | +---+
> Bob ---------+
>
> The latter is possible due to private key handover, the intermediate
> output becomes owned solely by Bob and Bob can add many more inputs to that
> second transaction unilaterally for even greater confusion to chain
> analysis, basically private key handover gets us PayJoin for free.
> It also removes the need for Bob to reveal additional UTXOs to Alice
> during the swap protocol; yes PoDLE mitigates the privacy probing attack
> that Alice can mount on Bob, but it is helpful to remember this is "only" a
> mitigation.
>
> Now of course things are different if Alice is paying some exact amount to
> Carol, and Alice wants to dissociate her funds from the payment.
> The difference is then:
>
> +---+ +---+
> Alice ---| |----| |--- Bob
> Alice ---| |--+ | |
> Bob ---| | | +---+
> +---+ +--------- Alice Change
>
> +---+ +---+
> Bob ---| |----| |--- Carol
> | |--+ +---+
> +---+ |
> +--------- Bob Change
>
> Versus:
>
> +---+ +---+
> Alice ---| |----| |--- Bob
> Alice ---| | +--| |
> +---+ | +---+
> Bob ---------+
>
> +---+ +---+
> Bob ---| |----| |--- Carol
> | |--+ | |--- Alice Change
> +---+ | +---+
> +--------- Bob Change
>
> In the above, with PayJoin on the first-layer transaction, the Alice
> Change is correlated with Alice and Bob inputs, whereas with the PayJoin on
> the second the Alice change is correlated with Bob inputs and Carol outputs.
>
> But if Alice, using commodity CoinSwap wallets, always has a policy that
> all sends are via CoinSwap (a reasonable policy, similar to the policy in
> JoinMarket of ensuring that all spends out of the wallet are via CoinJoin),
> then the above two trees are not much different for Alice in practice.
> The Alice Change will be swapped with some other maker anyway when it gets
> spent, so what it correlates with will not be much of a problem for Alice.
> At the same time, with PayJoin on the second-layer transaction (possible
> due to private key turnover, which is an inherent part of the SAS protocol):
>
> * Bob does not have to reveal any other coins it owns to Alice other than
> what it is directly swapping, removing a privacy probe vector.
> * Bob can unilaterally combine more than one input to the second
> transaction going to Bob, which further increases the uncertainty of
> clustering around the inputs from Alice than just adding *one* input.
>
> ---
>
> A thing I have been trying to work out is whether SAS can be done with
> more than one participant, like in [S6](
> https://joinmarket.me/blog/blog/multiparty-s6/).
>
> So far, I have not figured out a way to make it multiparty (multihop?).
> Because the secret being transported is a private key that protects a
> specific UTXO, it seems it is not possible to safely use the same secret
> across more than two parties.
> Perhaps others have come ideas?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200531/eea6bdba/attachment.html>;