path: root/30/d192502e3a720d313f5dc07542381c5dd1a1a0

Return-Path: <belcher@riseup.net>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 782D0C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 09:00:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 6FE2087372
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 09:00:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aVM7aIIp53nq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 09:00:30 +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 hemlock.osuosl.org (Postfix) with ESMTPS id 5256B87359
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 09:00:30 +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 4Bhvs22PzLzFgn4;
 Thu,  3 Sep 2020 02:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1599123630; bh=8VCy6WiWhOHGf1relF3LI1UIK+yz1nT6BfnhxkkOaw0=;
 h=From:Subject:To:References:Date:In-Reply-To:From;
 b=icIXM9JSiBbT6DbSe1QWqnDiDl6RH/IwR1hLoqaymTP7aM+LG5IkAs52JIxelIdWe
 7l6lZbeJeAGy2fKmX/PyVl6TNKHVgdDlYFYROR8Z5avYwZV2MenjD6GkkReTprIjA4
 Rn5oXTnRVrp0KliLxsqsR3EraUAKrE4KxO4VkWCs=
X-Riseup-User-ID: 710D255F092C31091A2A9C3F5BBF96FA746B4FEC30A2CDA57AF89C3067CFC775
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by capuchin.riseup.net (Postfix) with ESMTPSA id 4Bhvs11xZKz8sZv;
 Thu,  3 Sep 2020 02:00:05 -0700 (PDT)
From: Chris Belcher <belcher@riseup.net>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
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: <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net>
Date: Thu, 3 Sep 2020 10:00:00 +0100
MIME-Version: 1.0
In-Reply-To: <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
 multi-transaction CoinSwap
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: Thu, 03 Sep 2020 09:00:31 -0000

Hello ZmnSCPxj,


On 25/08/2020 04:16, ZmnSCPxj wrote:
> 
> Good morning Antoine,
> 
> 
>> Note, I think this is independent of picking up either relative or absolute timelocks as what matters is the block delta between two links.
> 
> I believe it is quite dependent on relative locktimes.
> Relative locktimes *require* a contract transaction to kick off the relative locktime period.
> On the other hand, with Scriptless Script (which we know how to do with 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a contract transaction.
> 
> With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one participant holds a completely-signed timelock transaction while the other participant holds a completely-signed pointlock transaction.
> This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition.
> There is no transaction that both participants hold in completely-signed form.
> 
> This should remove most of the shenanigans possible, and makes the 30xRBF safe for any range of fees.
> I think.
> 
> Since for each PTLC a participant holds only its "own" transaction, it is possible for a participant to define its range of fees for the RBF versions of the transaction it owns, without negotiation with the other participant.
> Since the fee involved is deducted from its own transaction, each participant can define this range of RBFed fees and impose it on the partial signatures it gets from the other participant.
> 
> --
> 
> Private key turnover is still useful even in an absolute-timelock world.
> 
> If we need to bump up the block delta between links, it might be impractical to have the total delta of a multi-hop swap be too long at the taker.
> 
> As a concrete example, suppose A is a taker who wants to route over makers B and C.
> However, B and C require a CLTV delta of 1 week.
> 
> If A wants to route "directly" A->B->C->A, then if something bad happens, it could be looking at having its funds locked for two weeks.
> 
> To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A.
> This limits its funding lockup to 1 week.
> 
> Private key turnover is useful since as soon as the A->B->A swap completes, it can directly fund the A->C->A swap from the B-side funding transaction of the A->B->A swap.
> 
>          |   A->B->A         |    A->C->A           |
>          :                   :                      :
>       A -:->funding A&B--> B :                      :
>          :                   :                      :
>       B -:->funding A&B -----:--> funding A&C --> C :
>          :                   :                      :
>          :                   :C-> funding A&C ------:-> to-cold  A -->
>          :                   :                      :
> 
> This increases the number of transactions by 1 per swap beyond the first, compared to a direct routing A->B->C->A, but this may be worth it for A if the timelocks involved are too big for A.
> 
> With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is unable to reliably determine if it is the last hop in the route.
> 
> Without private key turnover, A would have:
> 
>                       **NO** private key turnover!
> 
>          |   A->B->A         |    A->C->A                      |
>          :                   :                                 :
>       A -:->funding A&B--> B :                                 :
>          :                   :                                 :
>       B -:->funding A&B -----:--> claim A -> funding A&C --> C :
>          :                   :                                 :
>          :                   :           C-> funding A&C ------:-> to-cold  A -->
>          :                   :                                 :
> 
> So if timelock-deltas are possibly-high (to reduce the probability of the MAD-HTLC argument, and other attacks, succeeding), takers might prefer to route by completing one swap first before starting the next one, and private key turnover is useful by reducing blockspace required by each hop.
> 
> For reference, this is how it looks like with a single A->B->C->A swap with private key turnover:
> 
>          |   A->B->C->A      |
>          :                   :
>       A -:->funding A&B--> B :
>          :                   :
>       B -:->funding B&C -> C :
>          :                   :
>       C -:->funding A&C -----:-> to-cold A -->
>          :                   :
> 
> This is still smaller than in the A->B->A, A->C->A with private key turnover, by one funding tx per hop.
> However, A risks a much higher timelock (twice the timelock).
> Thus, A might prefer a lower timelock in exchange for paying for an additional transaction.
> 
> Regards,
> ZmnSCPxj
> 


Separating the timelock and hashlock cases into two separate
transactions is a nice way to solve many of these problems.

A big downside is that it really ruins the property of allowing coins to
remain unspent indefinitely. That has privacy implications: if a coin
remains unspent for longer than 2 weeks (or another short locktime) then
for sure the transaction was not a CoinSwap, and so the anonymity set of
the CoinSwap system would be far smaller For this reason I'm pretty
desperate to solve the vulnerability without losing the coins remaining
unspent indefinitely feature.

We need to solve the vulnerability you found, which I'll call the
riskless theft attempt problem. So what do you think of this solution:


== Building block 1: A, B and C having different contract txes ==

In the original proposal each CoinSwap peer has the same contract
transaction, and either side can broadcast it whenever they like. This
actually isn't necessary. We can have a contract transaction
fully-signed but only known to one peer, with a possibly-different
transaction transaction fully-signed and only known to the other peer.

Obviously for the CoinSwap to work both contract transactions must have
the same hash-time-locked contract, but they can differ in other ways.

== Building block 2: collateral payments ==

The riskless theft attempt problem happens because the previous owner of
the coins knows the fully-signed contract transaction and can broadcast
it at no cost to themselves. So to solve the problem we add a cost.

There is a 2of2 multisig made up of Bob's and Charlie's keys. The
associated contract transaction known to Bob must now also have one of
Bob's single-sig inputs. The outputs are such that some of the money
from Bob's input now ends up in the HTLC output. The result is that
after the CoinSwap if Bob broadcasts his contract transaction but fails
to take the money from the HTLC output, then Bob will have lost money.

I'm calling this idea collateral payments, by analogy with collateral
used for loans. A collateral is someone valuable a debtor puts on the
table, and if they don't repay the loan then they lose the collateral
(presumably the creditor sells it to repay the loan).

Here is a diagram of the contract transaction known to Bob:

    multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
    collateral(B)  [J btc]     (Bob)                    [J-K btc]

where:
    I = CoinSwap amount
    J = Value of Bob's collateral input
    K = Value that Bob loses if he broadcasts his contract tx but doesnt
get the money
    M~ = miner fee (random variable)

The value K is something that can be set by the protocol, and made high
enough so that doing a riskless theft attempt is not worth it. Probably
the value of K will be quite small because the odds of a riskless
payment attempt succeeding is very small (assuming the makers all use
multiple redundant watchtowers). Mostly likely K will be smaller than
M~, so if the collateral is lost to Bob then the miners will the ones to
gain, rather than Charlie.

The other contract transaction, known only to Charlie, does not contain
a collateral input or collateral value (K), because Charlie can't do a
riskless theft attempt to Bob.

If Bob ever spends his collateral input in another transaction, then his
contract transaction will become invalid. However Bob will only be
harming himself, so he'll never do this.

I think this might be a fruitful idea, and soon I'll modify my earlier
detailed design to include it, and see if it can be made to work with no
weird edge cases or attacks.



=== Appendix: Brief historical note about separate contract txes ===

Separating hash- and time-lock branches into different transactions as
in ZmnSCPxj's design is actually very similar to the way the original
2013 CoinSwap design worked:
https://bitcointalk.org/index.php?topic=321228.0

The timelock branch was a transaction locked with nLockTime. And the
hashlock branch is another transaction spending to an output requiring
Carol's public key + hash preimage.

However Adam Gibson in 2017 found a vulnerability to this:
https://github.com/AdamISZ/CoinSwapCS/blob/master/docs/coinswap_tweak.md

The vulnerability is that even though Carol doesn't know the hash
preimage, she can still broadcast the hashlock transaction, which sends
the coins _into_ the hashlock contract, and that invalidates Alice's
timelock transaction. Carol is the only one who can spend the coins but
she doesn't know the hash preimage. The protocol then degenerates to the
MAD (mutually assured destruction) case because the coins are locked
forever.

Adam Gibson's fix was to include the hashlock and timelock branches into
the same transaction known to both peers, which is exactly the design I
used and for which all these vulnerabilities were found.

I realize now there is another way to solve the vulnerability, which is
to include a (Alice pubkey + OP_CLTV timelock) in Carol's contract
transaction. This means that if Carol broadcasts her contract tx (called
TX_2 in the text) without knowing the preimage then Alice can still get
her money back after a timeout, breaking the MAD situation. The crucial
part making this work is that Alice won't know the fully-signed Carol
contract transaction, and so won't be able to unilaterally broadcast it.
I believe this fix makes the scheme equivalent to ZmnSCPxj's idea of
separated transactions, but without scriptless scripts (and so the
scheme is less useful)


Kind regards
CB