public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Chris Belcher <belcher@riseup.net>
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: Sat, 06 Jun 2020 01:40:18 +0000	[thread overview]
Message-ID: <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com> (raw)
In-Reply-To: <e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>

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 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock
>
> And you propose a second pre-signed transaction?
> 2of2 multisig (Alice+Bob) ---> Bob+timelock2

No, it is:

2of2 multisig (Alice+Bob) --(nLockTime=locktime1)-> Alice

The timelock is  imposed as a `nLockTime`, not as an `OP_CLTV` (so not in the output of the tx, but part of the tx), and the backout returns the funds to Alice, not sends it to Bob.
This transaction is created *before* the contract transaction.

The order is:

* Create (but not sign) Alice funding tx (Alice --> Alice+Bob).
* Create and sign Alice backout transaction (Alice+Bob -(nLockTime=locktime1)-> Alice).
* Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret).
* Create and sign Bob backout transaction (Alice+Bob+sharedSecret -(nLocktime=locktime2)-> Bob) where timelock2 < timelock1.
* Sign and broadcast funding txes.
  * At this point, even if Bob funding tx is confirmed but Alice funding tx is not, Bob can recover funds with the backout, but Alice cannot steal the funds (since there is no hashlock branch at this point).
* When Alice funding tx is confirmed, create and sign contract transaction (Alice+Bob --> Alice+timelock1 OR Bob+hashlock).
* When Bob funding tx is confirmed and Bob has received the Alice contract transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecret --> Bob+timelock2 OR Alice+hashlock).
* Continue as normal.

In effect, the backout transaction creates a temporary Spilman unidirectional time-bound channel.
We just reuse the same timelock on the HTLC we expect to instantiate, as the time bound of the Spilman channel; the timelock exists anyway, we might as well reuse it for the Spilman.

Creation of the contract tx invalidates the backout tx (the backout tx is `nLockTime`d, the contract tx has no such encumbrance), but the backout allows Alice and Bob to fund their txes simultaneously without risk of race loss.
However, they do still have to wait for (deep) confirmation before signing contract transactions, and Bob has to wait for the incoming contract transaction as well before it signs its outgoing contract transaction.

The protocol is trivially extendable with more than one Bob.

The insight basically is that we can split CoinSwap into a "channel establishment" phase and "HTLC forwarding" phase followed by "HTLC resolution" and "private key handover".
HTLC forwarding and HTLC resolution are "done offchain" in the channels, and channel establishment can be done in any order, including reverse.

Indeed, the Spilman channel need not have the same timelock as the HTLC it will eventually host: it could have a shorter timelock, since the contract transaction has no `nLockTime` it can be instantiated (with loss of privacy due to the nonstandard script) before the Spilman timeout.

Regards,
ZmnSCPxj


  reply	other threads:[~2020-06-06  1:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-25 13:21 [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility 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
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 [this message]
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='Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=belcher@riseup.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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