> [...] we can use 2-party ECDSA to create 2-of-2 multisignature addresses that
> look the same as regular single-signature addresses[2]. Even the old-style
> p2pkh addresses starting with 1 can be CoinSwap addresses.
Probably worth considering that p2pkh, p2wpkh and p2sh are vulnerable to the
Hello ZmnSCPxj,
On 10/06/2020 11:58, ZmnSCPxj wrote:
> Good morning Chris,
>
>>> Let me propose an alternative: swap-on-receive+swap-on-change.
>>
>> That's an interesting point, thanks for the thought. This scheme might
>> not be appropriate for every threat model and use case.
>> For example,
Hello Lee,
Thanks for the review.
On 10/06/2020 01:43, Mr. Lee Chiffre wrote:
>
>>
>> === Combining multi-transaction with routing ===
>>
>> Routing and multi-transaction must be combined to get both benefits. If
>> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
>>
Good morning Chris,
> > Let me propose an alternative: swap-on-receive+swap-on-change.
>
> That's an interesting point, thanks for the thought. This scheme might
> not be appropriate for every threat model and use case.
> For example, if someone wants to use bitcoin just as a foreign currency
>
Good morning ZmnSCPxj,
On 06/06/2020 02:40, ZmnSCPxj wrote:
> Good morning Chris,
>
>> I think I'm having trouble understanding this, does it work like this:
>>
>> Say we're in the 2-party coinswap case (Alice and Bob)
>>
>> We have Alice's funding transaction:
>> Alice UTXO ---> 2of2 multisig
Good morning Mr. Lee,
> > === Combining multi-transaction with routing ===
> > Routing and multi-transaction must be combined to get both benefits. If
> > Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
> > easy with this configuration:
> >
> > Alice
> >
>
> === Combining multi-transaction with routing ===
>
> Routing and multi-transaction must be combined to get both benefits. If
> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is
> easy with this configuration:
>
> Alice
> (6 BTC) (8 BTC) (1 BTC)
>
> Coinjoin on Monero can be
> compared to ring signatures in Monero from the view of using decoys to
> help conceal the source. From this proposal is this to say that
> transactions will be at least 12 times larger in size to achieve the
> property of privacy that bitcoin is currently missing?
>
Good morning a third time Chris,
Now unrelated to the funding order, but one of the reasons why timeliness is
desirable for CoinSwap is that if possible, we want to ensure that sends from a
user wallet are not correlatable with receives into that wallet.
Thus, there is the strong suggestion
Good morning again Chris,
I am uncertain if you are aware, but some years ago somebody claimed that
2p-ECDSA could use Scriptless Script as well over on lightning-dev.
*
https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf
*
Good morning Chris,
> I think I'm having trouble understanding this, does it work like this:
>
> Say we're in the 2-party coinswap case (Alice and Bob)
>
> We have Alice's funding transaction:
> Alice UTXO ---> 2of2 multisig (Alice+Bob)
>
> And we have the regular contract transaction
> 2of2
Good day ZmnSCPxj,
>>> But S6 has the mild advantage that all the funding transactions paying to
>>> 2-of-2s can appear on the same block, whereas chaining swaps will have a
>>> particular order of when the transactions appear onchain, which might be
>>> used to derive the order of swaps.
>>
Good morning yet again Chris,
> > For the avoidance of theft, it is probably better for Bob to wait for
> > Alice-side funding tx to confirm, probably deeply because reorgs suck.
I realized that the *other* improvement I proposed in the [CoinSwapCS
Good morning Chris again,
> For the avoidance of theft, it is probably better for Bob to wait for
> Alice-side funding tx to confirm, probably deeply because reorgs suck.
Over in Lightning-land, we have a concept called "irrevocably committed".
This is a state where a newly-created contract
Good morning Chris,
> > Good morning Ruben and Chris,
>
> > I am not in fact convinced that PayJoin-with-CoinSwap adds that much
> > privacy.
> > These transactions:
> >
> > +---+ +---+
> > Alice ---| |--| |--- Bob
> > Alice ---| | | |
> > Bob ---| | +---+
Hello ZmnSCPxj,
On 31/05/2020 03:30, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Ruben and Chris,
> I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much
> privacy.
>
> These transactions:
>
> +---+ +---+
> Alice ---| |--| |--- Bob
> Alice ---|
Hi ZmnSCPxj,
>If Alice is paying to a non-SAS aware payee
Yeah, I agree that this use case is not possible without a third
transaction (preferably from the timelocked side, in the case of SAS). My
point was merely that you can swap and simultaneously merge some of your
outputs into the post-swap
Good morning Ruben,
>
> 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 ---| |
> +---+
If Alice is paying to a non-SAS aware
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.
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
Hey Chris,
Excellent write-up. I learned a few new things while reading this
(particularly how to overcome the heuristics for address reuse and address
types), so thank you for that.
I have a few thoughts about how what you wrote relates to Succinct Atomic
Swaps (SAS)[0]. Perhaps it's useful.
21 matches
Mail list logo
