Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 782D0C0051 for ; 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 ; 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 ; 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 ; 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 To: ZmnSCPxj , Antoine Riard , Bitcoin Protocol Discussion References: <813e51a1-4252-08c0-d42d-5cef32f684bc@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: <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net> Date: Thu, 3 Sep 2020 10:00:00 +0100 MIME-Version: 1.0 In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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