From: Ruben Somsen <rsomsen@gmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•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, 1 Jun 2020 12:19:38 +0200 [thread overview]
Message-ID: <CAPv7TjZf60VPKXL2s8bFXEF1kUGS-LMEpuURf4O4CPM3kFuyZQ@mail.gmail.com> (raw)
In-Reply-To: <WKC6zH0X8ad2bK_JwklQegyJBKf5rTp1Ub_fPPPkS_EeIkIoc_wcRd9k3a_aq6sFIZ3-gOtG9ubWq3gTPG5fZW5aA1s_2C8-emEsr67Qxjk=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]
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 non-timelocked output, though perhaps that is
not very useful.
Cheers,
Ruben
On Mon, Jun 1, 2020 at 4:34 AM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> 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
>
[-- Attachment #2: Type: text/html, Size: 4020 bytes --]
next prev parent reply other threads:[~2020-06-01 10:19 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
2020-06-01 10:19 ` Ruben Somsen [this message]
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=CAPv7TjZf60VPKXL2s8bFXEF1kUGS-LMEpuURf4O4CPM3kFuyZQ@mail.gmail.com \
--to=rsomsen@gmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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