path: root/ec/c5badeaf6ec0e33472a1d60e8144bcb18b97f6

Return-Path: <belcher@riseup.net>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F620C0175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 May 2020 19:28:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 0E2C1864EF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 May 2020 19:28:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1c9UE0-OCePJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 May 2020 19:28:27 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 9143D85F57
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 May 2020 19:28:27 +0000 (UTC)
Received: from capuchin.riseup.net (unknown [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 49Fbcq202PzFcxP;
 Sun,  3 May 2020 12:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1588534107; bh=dlj7y6s7ydMw2x5KQh3ZtQUxFo8T1nKsEA6ul7TeGt0=;
 h=Subject:To:Cc:References:From:Date:In-Reply-To:From;
 b=OugXDigKq4APN9/Le7EUJlT735Qjdr3joNrxLcJO9bRS1xduUCKgQnreN8FP4CJrd
 EjgjcEtEjHFjcoViGFpjgitNkizPN9E3uD8+3liZcDNpiQJ55/ZgB9nWRORzSj4Ff7
 6SmaE4+j9JRNlJc59bkvW+dm7ZPWmCRHkgqGiaS0=
X-Riseup-User-ID: DA84752869A97BC077C69E4F43FA2E171813D8F5E913983E3CFA98481A0E69F8
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by capuchin.riseup.net (Postfix) with ESMTPSA id 49Fbcp4Plqz8tYF;
 Sun,  3 May 2020 12:28:26 -0700 (PDT)
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <CALmj_sWCA6S_4bnmLetvLuzNhv=PfQvLnX3zVEZwsRtgzA=yqw@mail.gmail.com>
 <CALmj_sVwLG82_pCEnc-mdT-Cf+cPitpL59AruBbvyYLjaYoZ2Q@mail.gmail.com>
 <mRCFEsXTvivO-I7sBdoTbqV0RsnX9vdGGORqzJBGYWXd1Xqis-oBNtEFaCEWIt3g9ARrvNeqH3l6sWSH4uQdcj5ps5WAmaEbEUvb9Znk9Rw=@protonmail.com>
 <CALmj_sUuw8JkodDemnq4qkapWD28vpojKD3bmkiVYm3Cp76+NQ@mail.gmail.com>
 <-_xRcjb8H_0Bck71k4VkeukEBgHT-03ikLTIdyTG2P0rt0T_mvN4b4FejmWobwnAUCGNaDpFQlPc3TMwlml1gjnZ1lwSumeEYQpXSyijND0=@protonmail.com>
 <0e1c0287-617c-976c-9fd4-16683881d5d5@riseup.net>
 <muQZ5QzVScvrjDkpZg1pWQMPFekgn_yqaro1i-JBZWCowA4HhybWFi3e5clygh5EIeLIa7jlykipA5nAxpiuLXK0-5SE3wEXXOTVwMlPAVU=@protonmail.com>
 <ed482ed6-a79b-e20c-5356-8be4345333f5@riseup.net>
 <gAyc5MFCEkCjjdLSx_fKF-9MVnI4Zl6-BQ7Y-Q2_JNFYE2tQbCC1Js5YfE9RnPE_RPoVx57H0tWA-dpJ5SM7KP52DxTzHRdx6IF_pWjIh7A=@protonmail.com>
 <25848910-24ca-8b49-ad20-39afae2a856b@riseup.net>
 <MCKbq9k8bMWTqHyAAjWGhqNdwTZ1ELa5gmsnNQ3HgrtRu1ATsskYfyyT__X_L3c8AXHFI0bJfiPnGf_Y76I7P7BubGWKsFCJiejB6mAfwUQ=@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: <5e5ed1c3-085e-2137-5368-4e605e79b5bf@riseup.net>
Date: Sun, 3 May 2020 20:28:23 +0100
MIME-Version: 1.0
In-Reply-To: <MCKbq9k8bMWTqHyAAjWGhqNdwTZ1ELa5gmsnNQ3HgrtRu1ATsskYfyyT__X_L3c8AXHFI0bJfiPnGf_Y76I7P7BubGWKsFCJiejB6mAfwUQ=@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] Fwd: (Semi)Traceless 2-party coinjoin off-chain
 protocol using schnorr signatures
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: Sun, 03 May 2020 19:28:29 -0000

Hello ZmnSCPxj,

>>> This "as long as the inputs that should be separate are not co-spent" is precisely what mixdepths protect against, which is why I think some kind of mixdepth facility will still matter in CoinSwap.
>>> Still, you have convinced me that, for the purpose of multi-transaction CoinSwap where you do not merge any of your coins, it is immaterial if the sub-transactions come from the same mixdepth or not.
>>> And if you have to merge your coins (for instance, if you are a maker and your customer wants to get a UTXO that is larger than any you have on hand, you have to merge your coins), you just have to ensure they are in the same mixdepth.
>>> Of course, you could be proposing some other construct --- perhaps you have some relational entry which says "you cannot merge coin A and coin B" which allows you to merge A C D or B C E, but not A B?
>>> (I imagine this would make coin selection even harder, but I am not a mathematician and there may be some trivial solution to this.)
>>> Now --- if you have two coins that cannot be merged in the same onchain tx, what happens when you swap them in a multi-tx CoinSwap with somebody else?
>>> That somebody else does not know that information.
>>> Instead, that somebody else must always assume that any coins it got from the same CoinSwap operation must not be safely mergeable (though they can still be used in the same swap together).
>>> Coins received via receive addresses would also not be mergeable with any other coins, except coins to the same address (because coins in the same address already leak that they are owned by the same owner).
>>
>> Yes I guess you're right. This part about mixdepths requires further
>> thought.
>>
>> CoinSwap can be combined with some kind of CoinJoin (most likely
>> something similar to PayJoin or CoinJoinXT). That should help with the
>> reasoning about co-spending inputs and mixdepths, because other inputs
>> that are not owned by the taker will often be co-spent anyway.
>>
>> Regarding coins which mustn't be co-spent being coinswapped to somebody
>> else, ideally that coinswap maker will receive coins from unrelated
>> takers too, so will merge their coins along with those as well. Also the
>> fact that a coinswap happened means there are two transactions between
>> the taker's-inputs-which-mustnt-be-merged and them actually being merged.
> 
> One of those transactions (the second one) will be a 1-input 1-output tx (it moves the coin from bilateral control to unilateral control of Bob), which chain analysis already knows to be a self-transfer.
> The first transaction will also usually be a 1-input 1-output tx as well (it moves the coin from unilateral of Alice to bilateral control) if you did not do any splitting or merging before providing the coin into the swap (for example if this comes from the taker, and the taker knows all the coins it wants to swap cannot be safely merged together).
> 
> If chain analysis keeps the heuristic "1-input 1-output is a self-payment because srsly who has an exact amount for a payment Bitcoin is volatile lol", then the resulting coins still are not safe to merge, because chain analysis will "pass through" the swap operation and if the two coins are later merged then they still end up *correctly* concluding the original coins were owned by the same owner.
> 
> Using a PayJoin construction for the second tx would help, but if the receiving end does not have a spare UTXO it can merge with (e.g. all its liquidity got tied up in the swap) then there might not be an opportunity to PayJoin.
> 
> There is also little that can be done about the first transaction, in case it ends up being a 1-input 1-output.
> 
> Suppose Alice the taker has a 1 BTC output and a 1 BTC output *and no other coins*, both of which it cannot safely merge, and it has to pay 1.2 BTC to Carol.
> Alice then has to CoinSwap them to Bob the maker, requesting a 1.2 BTC output going to Carol and the rest in whatever loose change Bob has.
> Alice then has to use two 1-input 1-output txes for each of its 1 BTC outputs (because it cannot merge them together) to put them into bilateral control.
> Then Bob claims them from bilateral control with 1-input 1-output txes as well (it cannot merge them together, because that might break Alice privacy, and Bob might not have any other spare coins it can merge with the incoming funds).
> 
> Now, even if Bob PayJoins the second tx for both 1 BTC outputs, it still cannot merge the resulting joined coins together, because the "spent-together" analysis would still tie those coins as being owned by the same owner, it is simply that the surveillor will think the owner owns more coins than it actually does, but the two 1 BTC TXOs that Alice used to own are still analyzed as being owned by the same owner if they are ever merged.
> 
> What Alice could do, to "merge" its 1BTC coins together, would be to swap only one of the 1BTC coins first, for a single 1BTC coin as well.
> Then presumably the incoming 1BTC coin has no linkage with the coin Alice swapped out (Alice hopes), then Alice could spend that new 1BTC coin with the old one it could not merge with the coin it swapped out.
> (Actually Alice does not need to do that as it is the customer after all, but maybe Bob the maker has to do that sometimes, in case it finds there are too many cannot-spend-together constraints in its pool of UTXOs and it is getting harder to select coins --- but if so, who does Bob the maker swap *with*?
> If Bob can encounter that problem, then maybe other makers will also have that problem as well!)
> 
> (the above can be done by PayJoining with the unswapped coin on either the first or second transaction in the swap as well; the idea is more general.)

Chain analysis doesn't in fact know that 1-input-1-output transfers are
self-transfers, this is merely a heuristic that can be flawed. For
example I accept donations in bitcoin and a surprising number of them
are 1-input-1-output or multi-input-1-output, presumably the donators
did it for privacy reasons or cost reasons. Also I believe many people
use 1-input-1-output transactions for funding Lightning channels.

Although even so, your argument suggests that its better for at least
some of the time for Alice and Bob to create 2-output transactions and
mess with the change output detection heuristics to try to get chain
analyzers to assign the wrong output as change.

If the receiving end doesn't have a suitable UTXO for a PayJoin then
they won't get the CoinSwap deal. The liquidity market is a free market,
takers are the maker's customers and they have a wide choice. In such a
case the maker would have been outcompeted by other makers which do have
extra UTXOs.

Your discussion with Alice having two UTXOs she doesn't want to co-spend
is definitely interesting. Perhaps also another way to solve is for
Alice to spend her UTXOs in 2-output transactions and mess with the
change output detection heuristics, say CoinSwapping 0.5 BTC from one
coin and 0.7 BTC from the other, with the total 1.2 BTC going to Carol.


>>>>> Assuming Alice is the taker, and Bob is the maker, then Alice might want a specific coin value (or set of such) that Bob does not have.
>>>>> In that case, Bob will have to split a UTXO it owns.
>>>>> We could constrain it so that Bob at least is not allowed to use the change from splitting for the same CoinSwap, e.g. if Bob has only 9 BTC and 1 BTC coins and Alice wants a 6 BTC / 3 BTC / 1 BTC split, then Bob cannot split its own 9 BTC coin then swap.
>>>>> Or in terms of mixdepths, Bob can split within a mixdepth but each outgoing UTXO in the same swap should be from different mixdepths.
>>>>
>>>> A good way to do it could be for Alice to tell Bob that she wants 10 BTC
>>>> and let Bob figure out on his own how to get that amount, based on the
>>>> amounts he already has. If Alice is making a payment she can provide
>>>> that amount too, but all the other output amounts can be up to Bob.
>>>
>>> This leaks to Bob whether Alice is making a payment or not; it would be better for the privacy of Alice for Alice to always mention some "payment amount", even if this is not actually a payment and Alice is just mixing for herself prior to storing in cold storage.
>>> And if Alice wants to use a single swap to pay to multiple targets at once, that implies Alice has to have the ability to indicate the outputs it wants to Bob, and it would imply as well that Alice has to obfuscate which of those outputs have amounts that actually matter (by always insisting on what the output amounts must be, rather than insisting on N output amounts and letting Bob handle the rest).
>>> (We could constrain it such that Alice can make only one payment per CoinSwap, so that Alice only gives one "target" amount and one "total" amount, but that implies even bigger blockspace utilization, sigh.)
>>> Otherwise, Bob can get information:
>>>
>>> -   "Oh, Alice did not specify any of the outputs, just the total amount, all of my old coins are owned by Alice now."
>>> -   "Oh, Alice specified an exact value for one of the outputs, that one is no longer owned by Alice but the rest are owned by Alice."
>>> -   "Oh, Alice specified exact values for two of the outputs, those two are definitely no longer owned by Alice but the rest are owned by Alice."
>>>
>>> The conclusion here is either Alice never specifies any of the outputs --- in which case Alice cannot use a CoinSwap to pay directly to somebody else --- or Alice specifies all of them.
>>> Again, the maker might be an active surveillor, thus we should reduce information leaks to the maker as much as we can.
>>
>> Yep great point.
>>
>> A benefit of Alice not specifying any amounts is that Bob is able to
>> improve privacy and reduce costs by creating fewer change outputs. A
>> downside is that this leaks Alice's intentions (self-mix vs payment) to Bob.
>>
>> A solution could be to add randomness. Have Alice randomly specify
>> payment amounts with some probability even if she is only self-mixing.
>>
>> Although this doesn't solve everything, because Alice not specifying any
>> amounts implies self-mixing. But at least specifying some amounts
>> doesn't imply a payment.
> 
> I think that maybe it would be a better policy for Alice to always just give a specified payment amount at all times.
> Of course, a sufficiently motivated Bob could always just do statistical analysis on the payment amount (e.g. if it is not equivalent to some round number of United States Green Historical Commemoration Papers, it is unlikely to be a payment but instead a random amount that Alice had to provide on a self-payment).
> So .....
> 
> 
> Anyway, slightly unrelated, maybe we can simply have Alice specify a single payment amount always, as an unremovable part of the protocol.
> 
> I proposed "private key turnover" here: https://github.com/AdamISZ/CoinSwapCS/issues/53
> Basically, after exchanging the swap secret, it is now safe to give your share of bilateral control to your swap partner, so you can just turn over that private key to the swap partner.
> For clarity:
> 
> * Alice owns a 1 BTC coin it wants to swap with a 1 BTC coin from Bob.
> * Alice sends its 1 BTC coin to bilateral control (Alice temporary key and Bob temporary key).
>   * Backoffs and confirmations and etc etc are needed, we all know how to do CoinSwap safely, I elide those details here.
> * Bob sends its 1 BTC to bilateral control (Alice 2nd temporary key and Bob 2nd temporary key).
> * Alice and Bob complete the CoinSwap protocol and now both know the swap secret X, and have to claim the bilateral control before some future blockheight L.
> * Alice can send its Alice temporary key to Bob, so that Bob can change the second transaction as it likes.
>   * Bob can merge it with a coin it happens to have, without having to coordinate signing with Alice (i.e. it gets PayJoin on the second tx for free).
>   * If Bob the maker gets another swap request, it can spend directly from the bilateral control address to another bilateral control address with a different taker, reducing blockchain footprint.
>   * Bob can fee bump using RBF instead of CPFP.
> * Bob can also now send its Bob 2nd temporary key to Alice, for similar advantages for Alice.
> 
> It does require that both Alice and Bob respect the timeout --- the bilateral outputs have to be spent before the timeout, else the timelock branches come into play.
> But Alice and Bob, after private key turnover, need not *immediately* broadcast the claiming transactions --- they can wait a little time for opportunities to change the claiming transaction, for example if they get an incoming payment they could assume that the recently-concluded swap is safe to merge with the new incoming coin and they can CPFP the incoming payment on the mempool with their existing coin, or Bob the maker might get another customer and Bob can cut-through from one swap to the next, reducing 4 transactions for 2 swaps to just 3 transactions (and if it can continuously chain customers that way, in the long run Bob on average has 1 transaction per swap, halving the block space usage needed for CoinSwap).
> 
> This increases complication of the implementation, but you potentially get an improvement in blockchain space for popular makers, with an asymptote of 50% reduction, so it is probably worth implementing.
> 
> 
> Thus, if Alice wants to multipay, she could just sum up all the outgoing values, then specify the sum to Bob.
> Then it can modify the second transaction to pay multiple destinations (since it has the private keys to remake that).
> Of course, all the outgoing payments are now linked together.... but I suppose you can warn the user of Alice of such.
> 
> It would probably be best for both Alice and Bob to always change the destination address as well after private key turnover.

Of course if Alice specified an amount when she was actually
self-mixing, it would be easy for her to come up with a random value
that was close to some round number, either in BTC or another currency.

Private key turnover is a great idea. It could also help with the
earlier problem of 1-input-1-output transactions being markers, because
when the coins in 2-of-2 multisigs are spent they may end up being spent
in a wider variety of ways.


>>> Okay, from what little I understand it seems that "even if sparse subset sum is easier than subset sum, it is still hard, so it probably will not matter in practice", would that be a fair takeaway?
>>
>> Not exactly. Here's another summary:
>>
>> Suppose Alice has V bitcoins and mixes them with multi-transaction
>> CoinSwap, she receives transactions with amounts (w_0, w_1, w_2....)
>> which add up to V.
>>
>> Privacy relying on the (sparse) subset sum problem works by making it
>> computationally infeasible for an adversary to search the entire
>> blockchain for sets of transactions (w_0, w_1, w_2....) which add up to
>> V. I believe aiming for this kind of privacy isn't practical due to
>> block space considerations and others.
>>
>> Privacy relying on false positives does not make any search
>> computationally infeasible, it works by having a large number of other
>> sets of transactions (w_0, w_1, w_2....) which add up to V just by
>> chance. Then the transactions received by Alice's will have a big crowd
>> to hide in. I believe this is practical because the numbers are
>> proportional to the n-choose-k function which can still be very large.
> 
> Hmm.
> 
> So let us return to our example of Alice who owns a 1 BTC coin and a 1 BTC coin.
> Now suppose we find, by false-positive-statistics, that 2 BTC subset sums are rare but, say, 1.5 BTC subset sums are significantly more common.
> So what Alice should do, if it wants to send 1.2 BTC to Carol via a CoinSwap with maker Bob, would be to split one of her 1 BTC coins to a 0.5 BTC and 0.5 BTC coin.
> Then it takes the remaining 1 BTC coin and one of the 0.5 BTC and offers them in a CoinSwap to maker Bob, specifying a payment amount of 1.2 BTC.
> 
> It seems to me, however, that this is not much different from just specifying a set of standardized swap amounts.
> 
> The initial standards can be derived from false-positive-statistics, but once SwapMarket starts to become popular, then the actual statistics of the chain becomes skewed towards those standard swap amounts.
> This makes it even wiser to also use those standard swap amounts, because of the larger anonymity sets.

It's very unlikely for the 2 BTC subset sum to be uncommon but 1.5 BTC
to be common, because they are very close in value, and these functions
seem to end up being smooth and slowly-varying, at least in my brief
tests. It might be a concern when comparing 2 BTC to 20 BTC or 200 BTC.


Regards
CB