From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Date: Mon, 01 Jun 2020 02:34:03 +0000 [thread overview]
Message-ID: <WKC6zH0X8ad2bK_JwklQegyJBKf5rTp1Ub_fPPPkS_EeIkIoc_wcRd9k3a_aq6sFIZ3-gOtG9ubWq3gTPG5fZW5aA1s_2C8-emEsr67Qxjk=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjZn6+j10a_X_vCG3Qn1Fv19uidw50Cf38NNUvp8m+uh2w@mail.gmail.com>
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 payee that just provides an onchain address (i.e. all current payees today), then the 2-of-2 output it gets from the swap (both of whose keys it learns at the end of the swap) is **not** the payee onchain address.
And it cannot just hand over both private keys, because the payee will still want unambiguous ownership of the entire UTXO.
So it needs a second transaction anyway.
(with Schnorr then Alice and payee Carol can act as a single entity/taker to Bob, a la Lightning Nodelets using Composable MuSig, but that is a pretty big increase in protocol complexity)
If Alice does not want to store the remote-generated privkey as well, and use only an HD key, then it also has to make the second transaction.
Alice might want to provide the same assurances as current wallets that memorizing a 12-word or so mnemonic is sufficient backup for all the funds (other than funds currently being swapped), and so would not want to leave any funds in a 2-of-2.
If Bob is operating as a maker, then it also cannot directly use the 2-of-2 output it gets from the swap, and has to make a new 2-of-2 output, for the *next* taker that arrives to request its services.
So there is always going to be a second transaction in a SwapMarket system, I think.
What SAS / private key turnover gets us is that there is not a *third* transaction to move from a 1-of-1 to the next address that makers and takers will be moving anyway, and that the protocol does not have to add communication provisions for special things like adding maker inputs or specifying all destination addresses for the second stage and so on, because those can be done unilaterally once the private key is turned over.
> >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.
Hmmm right right.
Naively it seems both chaining SAS/private key turnover to multiple makers, and a multi-maker S6 augmented with private key turnover, would result in the same number of transactions onchain, but I probably have to go draw some diagrams or something first.
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.
On the other hand, funds claiming in S6 is also ordered in time, so someone paying attention to the mempool could guess as well the order of swaps.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-06-01 2:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 13:21 Chris Belcher
2020-05-30 16:00 ` Ruben Somsen
2020-05-31 2:30 ` ZmnSCPxj
2020-05-31 21:19 ` Ruben Somsen
2020-06-01 2:34 ` ZmnSCPxj [this message]
2020-06-01 10:19 ` Ruben Somsen
2020-06-02 22:24 ` Chris Belcher
2020-06-03 4:53 ` ZmnSCPxj
2020-06-03 14:50 ` ZmnSCPxj
2020-06-04 16:37 ` ZmnSCPxj
2020-06-05 22:39 ` Chris Belcher
2020-06-06 1:40 ` ZmnSCPxj
2020-06-06 3:59 ` ZmnSCPxj
2020-06-06 4:25 ` ZmnSCPxj
2020-06-10 10:15 ` Chris Belcher
2020-06-10 10:58 ` ZmnSCPxj
2020-06-10 11:19 ` Chris Belcher
2020-06-10 0:43 ` Mr. Lee Chiffre
2020-06-10 0:46 ` Mr. Lee Chiffre
2020-06-10 7:09 ` ZmnSCPxj
2020-06-10 11:15 ` Chris Belcher
2020-06-19 15:33 ` Jonas Nick
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='WKC6zH0X8ad2bK_JwklQegyJBKf5rTp1Ub_fPPPkS_EeIkIoc_wcRd9k3a_aq6sFIZ3-gOtG9ubWq3gTPG5fZW5aA1s_2C8-emEsr67Qxjk=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rsomsen@gmail$(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