+Return-Path: <belcher@riseup.net>

+Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])

+ by lists.linuxfoundation.org (Postfix) with ESMTP id 948F7C016F

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 10 Jun 2020 10:15:42 +0000 (UTC)

+Received: from localhost (localhost [127.0.0.1])

+ by silver.osuosl.org (Postfix) with ESMTP id 80BF022DD3

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 10 Jun 2020 10:15:42 +0000 (UTC)

+X-Virus-Scanned: amavisd-new at osuosl.org

+Received: from silver.osuosl.org ([127.0.0.1])

+ by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)

+ with ESMTP id 54oZPChWssrd

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 10 Jun 2020 10:15:41 +0000 (UTC)

+X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6

+Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])

+ by silver.osuosl.org (Postfix) with ESMTPS id 572E922D24

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 10 Jun 2020 10:15:41 +0000 (UTC)

+Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176])

+ (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))

+ (Client CN "*.riseup.net",

+ Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))

+ by mx1.riseup.net (Postfix) with ESMTPS id 49hjYS6kzmzFgmt;

+ Wed, 10 Jun 2020 03:15:40 -0700 (PDT)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;

+ t=1591784141; bh=20+kL7ZELV5lOP+gBPkAQuAKnpRZvoWWYuN5ykFQBc4=;

+ h=Subject:To:Cc:References:From:Date:In-Reply-To:From;

+ b=gM+rTR27r0Oxyhr1AQQWTbKPbgkPVfDyx19WUM2VQYzlY8s5WO6tDc8RrQ2KgCv+b

+ tX6sY2oWwJeRD3+bcnivdM3gGQqJGKysBQ+mARsmNYi+RSGN6Yu+UlB4XhYDgVNKO+

+ nfOqI/V+s4OMiEMCzFJJbEMbZjfIb8hd1J7bLCi0=

+X-Riseup-User-ID: E7FB9685AAB5ADB3A8A8AAA00245750897B7A051682BD8065710E4FB73A45556

+Received: from [127.0.0.1] (localhost [127.0.0.1])

+ by capuchin.riseup.net (Postfix) with ESMTPSA id 49hjYS12zWz8tmk;

+ Wed, 10 Jun 2020 03:15:39 -0700 (PDT)

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>

+References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>

+ <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>

+ <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>

+ <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>

+ <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com>

+ <e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>

+ <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>

+From: Chris Belcher <belcher@riseup.net>

+Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata=

+ xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92

+ f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl

+ YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR

+ FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE

+ 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7

+ ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz

+ WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu

+ sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht

+ 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi

+ Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj

+ aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV

+ CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX

+ TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA

+ btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A

+ HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm

+ 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF

+ LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA

+ wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7

+ OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb

+ jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl

+ 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2

+ k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr

+ ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r

+ KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf

+ xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM

+ KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6

+ q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC

+ z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW

+ dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI

+ 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc

+ /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA

+ DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN

+ IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93

+ qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0

+ +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON

+ xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA

+ aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ

+ uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK

+ MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc

+ d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN

+ HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM

+ 1aSoTg==

+Message-ID: <27f05cf1-08b2-a281-75b7-5c035317d030@riseup.net>

+Date: Wed, 10 Jun 2020 11:15:36 +0100

+MIME-Version: 1.0

+In-Reply-To: <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>

+Content-Type: text/plain; charset=utf-8

+Content-Language: en-US

+Content-Transfer-Encoding: 7bit

+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

+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org

+X-Mailman-Version: 2.1.15

+Precedence: list

+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Wed, 10 Jun 2020 10:15:42 -0000

+

+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 (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

+>

+

+Thanks for the explanation. I understand now, and I understand how this

+makes it possible for all funding transactions in a coinswap route to be

+confirmed in the same block.

+

+However, I think this also breaks private key handover. Here's why:

+

+Recall that in a Alice/Bob coinswap we have two funding transactions

+(Alice --> multisig(Alice, Bob) and Bob --> multisig(Bob,Alice)), and

+two contract transactions (multisig(Alice, Bob) -->

+Alice+OP_CSV_timelock OR Bob+hashlock and multisig(Bob,Alice -->

+Bob+OP_CSV_timelock OR Alice+hashlock). After the hashlock preimage

+becomes known to all then Alice and Bob give their multisig privkey to

+the other party.

+

+Bob now has both privkeys in the multisig(Alice,Bob) so he can sign any

+transaction he wants spending from it, but the contract transaction

+still exists. So until Bob actually spends from the multisig he must

+always be watching the blockchain, and if Alice broadcasts the contract

+transaction then Bob must immediately spend from it using the hash

+preimage branch. If Bob waits too long and the OP_CSV timelock value

+passes then Alice can steal Bob's money by spending with that path. The

+OP_CSV timelock only starts ticking when the contract transaction

+actually confirms, and this is crucial for making privkey handover

+practical because it means the coins in the multisig can stay unspent

+indefinitely.

+

+However, I think this does not apply to the scheme you described which

+uses nLockTime, because after the privkeys are handed over Alice's

+backout transaction (Alice+Bob -(nLockTime=locktime1)-> Alice) still

+exists, and Alice could broadcast it. Once locktime1 passes then Alice

+can steal Bob's coins by broadcasting even though Bob holds both

+privkeys to that multisig. And using relative nLockTime doesn't help

+either because its timelock will start ticking down from when the

+funding transaction is confirmed, not when the contract transaction is

+confirmed, and so the coins in the multisig cant remain unspent

+indefinitely.

+

+So fundamentally I think privkey handover gets broken here because it

+requires relative timelocks. And those the relative timelocks need to

+start ticking down only after a contract transaction is confirmed.

+

+

+> 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.

+

+I was aware. In such a scheme we'd still require the other building

+blocks like fidelity bonds, multi-transaction and routing. So I was

+thinking to code the project using the simplest hash-time-locked

+contracts and once it all works we can add things like ECDSA-2P

+scriptless scripts or schnorr signatures when they get added. Making the

+Spilman channel scheme work with that is an interesting idea, thanks for

+the thought.

+

+> 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

+for its privacy and censorship-resistant properties. So for example if

+they want to pay for a VPN anonymously, so they buy bitcoins and

+immediately send all of them to the VPN merchant. The swap-on-receive

+wouldn't be appropriate for them because they'll be doing a coinswap

+straight away to the VPN merchant. So perhaps this plan could be an

+optional mode of operation (which may or may not be the default). The

+scheme obviously is useful when bitcoin is being used more as a

+day-to-day money.

+

+

+Regards

+CB

+

+

+