Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning CB, > 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. A heuristic need not be perfect to be effective, and I am quite sure that, outside of donation, most 1-output transfers will be self-transfers. Indeed, the old cliche of donating tainted/stolen funds is most likely a cliche for a reason. Perhaps you are a beneficiary of some movie hero who has stolen the money from a villain who acquired wealth by immoral means. Unlike change heuristics, misleading the 1-output heuristic is difficult; whoever got control of the single output is either yourself, or somebody who swapped coins with you. > Also I believe many people > use 1-input-1-output transactions for funding Lightning channels. Yes, Lightning helps privacy, that is correct. However, do note that Lightning channels tend to be long-lived, meaning it will be a large number of blocks that such a TXO will be unspent. Due to the timeout on CoinSwap, the fund needs to be claimed quickly, in much shorter time than a typical Lightning channel. This can help narrow down payment heuristics. > > 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. Yes, I agree. > 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. PayJoin might not buy you as much as you think. So Alice has two coins it does not want to CoinJoin for unknown reasons: Salary as ---> Alice teacher LiveJasmin ---> Alice payout Alice swaps them to Bob, who PayJoins the incoming funds. Since Bob has been operating for a long time, its coins have a varied and storied history. WannaCry > Bob + | | Salary as ---> Alice ---+--> Bob teacher LiveJasmin ---> Alice ---+--> Bob payout | | ex-JoinMarket -> Bob + maker Alice does *not* want Bob to join those two Bob-owned coins, still, because chain analysis would not only implicate her in WannaCry, but also as a LiveJasmin model ***and*** (gasp!) a JoinMarket money launderer (I am being facetious here). And since the swap has completed, Bob controls those coins. If another taker comes along, offering a high fee for a big swap, and Bob *has to* merge those two coins (that ultimately got history from Alice) in order to cover what the taker is requesting (because the taker has to make a big single payout to some other party, so needs a single large UTXO, not two small ones), what do you think Bob will do? In a free market where the takers have wide choice, do you think Bob will economically-rationally help protect the secret life of Alice when not doing so would let Bob earn more coins? Now of course, it would seem very unlikely that Alice the teacher is the hacker behind WannaCry *and* a LiveJasmin model *and* a money launderer, so no problem, right? It just makes surveillors looks like fools right? Except that Bob could have skipped the PayJoin step and just merged those four coins in a single transaction later, and the conclusion of surveillors would still be the same, for much the same effect, at reduced blockspace (spend in a single transaction instead of 3). So I think it is better if Bob actually avoids small merges of a two or three or four coins, and should do the occasional mass merge of large numbers of coins. This leads to better misleading of surveillors, and is incentive compatible since it reduces blockspace usage for Bob to do the occasional mass merge rather than PayJoining at every swap. > 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. That seems to be a good idea indeed, and significantly better than relying on PayJoin to obscure the history of coins. Of course, doing change-output-heuristic-breaking means splitting up coins, increasing the number of UTXOs. But that combines well with Bob the maker periodically merging many small coins. > Of course if Alice specified an
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
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
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning CB, > > 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
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Hello ZmnSCPxj, On 30/04/2020 09:54, ZmnSCPxj wrote: > Good morning CB, > > >> Equal-output-coinjoins and JoinMarket also have a version of the >> common-input-ownership-heuristic (CIOH), because its often possible to >> separate the inputs into sets of their owners of a equal-output-coinjoin >> using the input amounts. CoinSwap can be combined with something like >> PayJoin or CoinJoinXT, which would genuinely break the CIOH, so such a >> system wouldn't have this flaw either. >> >> For those reasons I've been thinking a CoinSwap system wouldn't need as >> many mixdepths, maybe it could use two or even just one. > > Would the ZeroLink proposal of separating a receiving (pre-mix) wallet from a > sending (post-mix) wallet apply, thus having two implicit mixdepths (the > receiving mixdepth and the sending mixdepth)? > Or would imposing the rule "all sends must be via CoinSwap" be sufficient > (and follow the ZeroLink rule in spirit)? > >> If so, then it follows that multi-transaction CoinSwaps can be done by >> having UTXOs come from the same mixdepth, as long as the inputs that >> should be separate are not co-spent in the same transaction. > > 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. Great point on the receive addresses coins. Another use case of mixdepths is to stop incoming payments from two different sources being linked together. >>> 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
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning CB, > Equal-output-coinjoins and JoinMarket also have a version of the > common-input-ownership-heuristic (CIOH), because its often possible to > separate the inputs into sets of their owners of a equal-output-coinjoin > using the input amounts. CoinSwap can be combined with something like > PayJoin or CoinJoinXT, which would genuinely break the CIOH, so such a > system wouldn't have this flaw either. > > For those reasons I've been thinking a CoinSwap system wouldn't need as > many mixdepths, maybe it could use two or even just one. Would the ZeroLink proposal of separating a receiving (pre-mix) wallet from a sending (post-mix) wallet apply, thus having two implicit mixdepths (the receiving mixdepth and the sending mixdepth)? Or would imposing the rule "all sends must be via CoinSwap" be sufficient (and follow the ZeroLink rule in spirit)? > If so, then it follows that multi-transaction CoinSwaps can be done by > having UTXOs come from the same mixdepth, as long as the inputs that > should be separate are not co-spent in the same transaction. 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). > > Remember that a passive surveillor of the blockchain doesn't see > mixdepths at all, they see addresses and transactions, and must use > heuristics to try to cluster them together. We can break these heuristics. > > > Attempting to completely detach a market-for-CoinSwap from JoinMarket seems > > to be impossible to my mind: the protocols are known, implementations open, > > and someone will inevitably write code for a single piece of software that > > can operate as both a JoinMarket maker and a maker for a > > market-for-CoinSwap (to increase their market, so to speak), so it might be > > better to just add CoinSwap to JoinMarket in the first place. > > Someone who has the ability to write such code should also have the > awareness to realize that mixing equal-output-coinjoins with coinswaps > damages the privacy because it breaks the steganography of coinswaps. > > Also, because CoinSwap is better than equal-output CoinJoin in almost > every way, we can expect users (who are takers) to stop using JoinMarket > and switch over to CoinSwap if the software becomes mature. So such a > JoinMarket maker won't get many customers, and so there wouldn't be much > point writing such maker code. An unscrupulous possible maker might not value the privacy of its customers (indeed makers are a privacy attack vector, which requires something like fidelity bonds like you suggested before to protect against), and takers might not want to do possibly-computationally-expensive blockchain analysis to evaluate whether a particular maker values privacy. An unscrupulous maker might thus earn more than a more scrupulous maker can, at least during the transition from JoinMarket to SwapMarket, and get a greater share of the future SwapMarket available liquidity due to their increased earnings during the transition. Against this we should remember that software that does two things is four times as complicated as software that does one thing, so hopefully your projected transition from JoinMarket to SwapMarket will be fast enough that such a combined Join/SwapMarket maker software does not arise fast enough to matter. > But for sure it would be good to reuse code in any eventual > implementation. Indeed Waxwing's implementation did: > https://github.com/AdamISZ/CoinSwapCS > > > Assuming
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning CB, I have been thinking about CoinSwap for a good while as well. Here are some very unorganized thoughts. It wold be nice to interoperate with JoinMarket, i.e. have a JoinMarket maker that also provides CoinSwap services using the same UTXOs. However, this requires us to retain compatibility with the JoinMarket wallet structure, which is divided into mixdepths, with the rule that UTXOs in different mixdepths cannot be spent together in the same onchain UTXO (to move across mixdepths you have to do a send, and sending out is always done by a single CoinJoin round with multiple makers). I am uncertain what is the best way to handle multitransaction when considering the mixdepth system. My instinct is that if you are doing multitransaction (whether as taker or maker) then each transaction in the swap *has to* come from a different mixdepth. The issue here is: * If all the UTXOs in the multitransaction swap come from the same mixdepth, then a surveillor who is monitoring that mixdepth gets a good hint in solving the sparse subset sum problem. * On the other hand, if all the UTXOs in the multitransaction swap come from different mixdepths, then a surveillor who has solved the sparse subset sum problem now has the hint that the different mixdepths are really owned by the same JoinMarket user. I am uncertain which tradeoff is better here, though I am inclined to think the latter is better. Attempting to completely detach a market-for-CoinSwap from JoinMarket seems to be impossible to my mind: the protocols are known, implementations open, and someone will inevitably write code for a single piece of software that can operate as both a JoinMarket maker *and* a maker for a market-for-CoinSwap (to increase their market, so to speak), so it might be better to just add CoinSwap to JoinMarket in the first place. > A couple of thoughts on multi-transaction coinswaps: > > - Users should never split up a single UTXO before doing a coinswap, > instead they should send the one UTXO to a coinswap address and get back > multiple UTXOs. > > For example, this 1-to-3 TXO coinswap (The symbol > means bitcoin > > > transaction). > > AliceA (10 BTC) > CoinSwap AddressA > BobA (10 BTC) > > BobB (3 BTC) > CoinSwap AddressB > AliceB (6 BTC) > > BobC (2 BTC) > CoinSwap AddressC > AliceC (3 BTC) > > BobD (5 BTC) > CoinSwap AddressD > AliceD (1 BTC) > > > Note that the Bob-to-Alice set of transactions add up to 10 BTC, the > entire CoinSwap is swapping the same amount. > > Or written another way: > > Alice TXO (10 BTC) > Coinswap Protocol > Alice TXO1 (6 BTC) > >> Alice TXO2 (3 BTC) > >> Alice TXO3 (1 BTC) > 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. > - It's helpful if any CoinSwap app is actually used for spending rather > than just mixing back to yourself. That will help avoid the problem of > users inadvertently co-spending all their coinswap outputs in the same > transaction. > An example of Alice paying for a VPN anonymously: > > Alice TXO (10 BTC) ---> Coinswap Protocol ---> VPN Payment (0.1 BTC) > > ---> Change1 (6 BTC) > > ---> Change2 (3 BTC) > > ---> Change3 (0.9 BTC) > > > > In this case Alice will never accidentally merge all her TXOs together, > because the VPN Payment TXO doesn't belong to her. Also this could > improve privacy because unlike in normal transaction the VPN provider > might not be able to figure out the lower bound of Alice's balance (10 > BTC in this case). This is a good idea, akin to the rule in JoinMarket that all outgoing spends are done through a CoinJoin. Of course, if a surveillor ***does*** solve the sparse subset sum, then the CoinSwap Protocol part looks exactly like a Bitcoin transaction, with a "main" paying output and a "change" output, and the same techniques that work with current Bitcoin txes work with "CoinSwap Protocol" virtual transactions. It seems to me that, in a system of makers and takers, even if the maker is really just paying the taker(s) to do CoinSwaps to mix back to itself, it should still "require" some output amount that really goes to itself, so that the
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
On 24/04/2020 02:34, ZmnSCPxj via bitcoin-dev wrote: > Good morning Germán, > > >> With regards to trying to tackle the problem of value-based correlations, >> wouldn't it be possible to try to model the solution after the >> equal-sum-subset problem (np complete problem)( >> https://www.cs.mcgill.ca/~lyepre/pdf/assignment2-solutions/subsetSumNPCompleteness.pdf >> )? >> That is, a pair of individuals with a set of UTXOs that both add up to >> similar if not equal value perform a swap of similar-(total)value sets. In >> this way the values of the UTXOs can be broken up essentially at random >> (following some nominal distribution so that it doesn't stand out; e.g. >> https://en.wikipedia.org/wiki/Benford%27s_law), but swapped in conjunction >> and decorrelated by using different keys + randomized locktimes. > > There are a number of issues to simply modeling this to the subset-sum > problem. > > * There is a practical limit to the number of UTXOs you would be willing to > receive in the swap. > * Every UTXO you receive increases the potential fee you have to pay to > spend them, meaning you would strongly dislike receiving 100 UTXOs that sum > up to 1mBTC. > * Thus, a practical blockchain analyst can bound the size of the sets > involved, and the problem becomes less than NP in practice. > * If you have a single UTXO and split it, then swap, anyone looking at the > history can conjecture that the split involved is part of a CoinSwap. > * The split is now a hint on how the subset sums can be tried. > * If after the CoinSwap you spend the UTXOs you received in a single > transaction, then you just published the solution to the subset sum for your > adversary. > * This ties in even further to the "practical limit on the number of UTXOs". > * Because it is not safe to spend the UTXOs from a single CoinSwap > together, you want to have fewer, larger UTXOs for more flexibility in > spending later. > > I believe belcher and waxwing and nopara73 have been working far longer on > privacy tech, and you should try to get in contact with them as well, they > may know of other issues (or solutions to the above problems). > > Regards, > ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > Hello list, A couple of thoughts on multi-transaction coinswaps: * Users should never split up a single UTXO before doing a coinswap, instead they should send the one UTXO to a coinswap address and get back multiple UTXOs. For example, this 1-to-3 TXO coinswap (The symbol > means bitcoin transaction). AliceA (10 BTC) > CoinSwap AddressA > BobA (10 BTC) BobB (3 BTC) > CoinSwap AddressB > AliceB (6 BTC) BobC (2 BTC) > CoinSwap AddressC > AliceC (3 BTC) BobD (5 BTC) > CoinSwap AddressD > AliceD (1 BTC) Note that the Bob-to-Alice set of transactions add up to 10 BTC, the entire CoinSwap is swapping the same amount. Or written another way: Alice TXO (10 BTC) > Coinswap Protocol > Alice TXO1 (6 BTC) > Alice TXO2 (3 BTC) > Alice TXO3 (1 BTC) This kind of thing could also be used for consolidation of many UTXOs without necessarily leaking information that the same person owns them. For example, if Alice owns 5 UTXOs: Alice TXO1 > Coinswap Protocol > Alice TXO Alice TXO2 > Alice TXO3 > Alice TXO4 > Alice TXO5 > * It's helpful if any CoinSwap app is actually used for spending rather than just mixing back to yourself. That will help avoid the problem of users inadvertently co-spending all their coinswap outputs in the same transaction. An example of Alice paying for a VPN anonymously: Alice TXO (10 BTC) ---> Coinswap Protocol ---> VPN Payment (0.1 BTC) ---> Change1 (6 BTC) ---> Change2 (3 BTC) ---> Change3 (0.9 BTC) In this case Alice will never accidentally merge all her TXOs together, because the VPN Payment TXO doesn't belong to her. Also this could improve privacy because unlike in normal transaction the VPN provider might not be able to figure out the lower bound of Alice's balance (10 BTC in this case). * Multi-transaction CoinSwaps aren't truly an example of a subset-sum problem, but "sparse subset sum", a related and easier problem. The way its normally formulated, subset sum is about finding a subset that adds up to a target value. But in multi-transaction coinswap there'd only be three or four CoinSwap outputs, so the problem is finding just three or four integers in a big set that add up to the target. You could think of it mathematically that the n-choose-k function is near-polynomial when k
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning ZmnSCPxj, The issues you point out are indeed important to note. Thank you for your wonderful feedback! * There is a practical limit to the number of UTXOs you would be willing to > receive in the swap. > * Every UTXO you receive increases the potential fee you have to pay to > spend them, meaning you would strongly dislike receiving 100 UTXOs that sum > up to 1mBTC. > Absolutely agree. It wouldn't be particularly nice to have to manage that. * Thus, a practical blockchain analyst can bound the size of the sets > involved, and the problem becomes less than NP in practice. > Definitely, though they first have to consider all subsets of a fixed size with values bounded above by the value of the unknown sum. So the analyst has to search through all fixed size sets (up to the practical bound) whose elements are less than a maximum sum. This is a number of choices that is (in a crude estimation) exponential (in the size of the UTXO set), and polynomial in the number UTXOs below that maximum sum value on-chain which can be pretty big at sufficiently large value-transfers. * If you have a single UTXO and split it, then swap, anyone looking at the > history can conjecture that the split involved is part of a CoinSwap. > * The split is now a hint on how the subset sums can be tried. > You're right that anybody could conjecture that it is involved in a CoinSwap, however in my proposed protocol the swap would like a (schnorr) P2PKH to the chain so you'd have to make that conjecture for every UTXO, so it's not much of a hint. Especially so noting that one, both or none of the outputs could be part of a swap. * If after the CoinSwap you spend the UTXOs you received in a single > transaction, then you just published the solution to the subset sum for > your adversary. > * This ties in even further to the "practical limit on the number of > UTXOs". > * Because it is not safe to spend the UTXOs from a single CoinSwap > together, you want to have fewer, larger UTXOs for more flexibility in > spending later. > Yes, this is definitely a weakness and some over-the-top UTXO management techniques (e.g. try to avoid combining different UTXOs in a known set into the same transaction by default, where possible) would be needed or like you say fewer larger UTXOs. It's interesting to note one can pick some subset of recent UTXOs and add up their output values, and select that as the amount of value transfer to exchange in a given operation. Resulting in a bit of added obfuscation as there are now seemingly (at least) 3 utxo sets that add up to similar or identical values, but only two of which are really participating in the swap. I believe belcher and waxwing and nopara73 have been working far longer on > privacy tech, and you should try to get in contact with them as well, they > may know of other issues (or solutions to the above problems). > Thank you for your input and suggestions! I will reach out to them. -- Germán Mathematician ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning Germán, > With regards to trying to tackle the problem of value-based correlations, > wouldn't it be possible to try to model the solution after the > equal-sum-subset problem (np complete problem)( > https://www.cs.mcgill.ca/~lyepre/pdf/assignment2-solutions/subsetSumNPCompleteness.pdf > )? > That is, a pair of individuals with a set of UTXOs that both add up to > similar if not equal value perform a swap of similar-(total)value sets. In > this way the values of the UTXOs can be broken up essentially at random > (following some nominal distribution so that it doesn't stand out; e.g. > https://en.wikipedia.org/wiki/Benford%27s_law), but swapped in conjunction > and decorrelated by using different keys + randomized locktimes. There are a number of issues to simply modeling this to the subset-sum problem. * There is a practical limit to the number of UTXOs you would be willing to receive in the swap. * Every UTXO you receive increases the potential fee you have to pay to spend them, meaning you would strongly dislike receiving 100 UTXOs that sum up to 1mBTC. * Thus, a practical blockchain analyst can bound the size of the sets involved, and the problem becomes less than NP in practice. * If you have a single UTXO and split it, then swap, anyone looking at the history can conjecture that the split involved is part of a CoinSwap. * The split is now a hint on how the subset sums can be tried. * If after the CoinSwap you spend the UTXOs you received in a single transaction, then you just published the solution to the subset sum for your adversary. * This ties in even further to the "practical limit on the number of UTXOs". * Because it is not safe to spend the UTXOs from a single CoinSwap together, you want to have fewer, larger UTXOs for more flexibility in spending later. I believe belcher and waxwing and nopara73 have been working far longer on privacy tech, and you should try to get in contact with them as well, they may know of other issues (or solutions to the above problems). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning ZmnSCPxj, Thank you for your excellent feedback! Indeed, with a little protocol-level sugar so that the coins being swapped get paid out of different pubkeys. I read your article. Excellent idea on the randomized locktimes! I've still to read the details of what S6 amounts to but I'm excited to. With regards to trying to tackle the problem of value-based correlations, wouldn't it be possible to try to model the solution after the equal-sum-subset problem (np complete problem)( https://www.cs.mcgill.ca/~lyepre/pdf/assignment2-solutions/subsetSumNPCompleteness.pdf )? That is, a pair of individuals with a set of UTXOs that both add up to similar if not equal value perform a swap of similar-(total)value sets. In this way the values of the UTXOs can be broken up essentially at random (following some nominal distribution so that it doesn't stand out; e.g. https://en.wikipedia.org/wiki/Benford%27s_law), but swapped in conjunction and decorrelated by using different keys + randomized locktimes. Regards, Germán On Thu, Apr 23, 2020 at 11:56 AM ZmnSCPxj wrote: > Good morning Germán, > > It looks to me like this is CoinSwap with Schnorr Scriptless Scripts. > > * https://joinmarket.me/blog/blog/coinswaps/ > * > https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/ > > I also recently put up an article on extending such a protocol across 3 or > more participants: > > * https://zmnscpxj.github.io/bitcoin/multiswap.html > > Regards, > ZmnSCPxj > > > ## Objective > > * Make atomic swaps within the same chain possible in a traceless way > > * Achieving traceless same-chain atomic-swaps effectively turns an > entire chain into a (P2PKH) mixer by default > > > > ## Proposed solution > > Similar to the way that atomic swaps would work with schnorr signatures > (i.e. leveraging adaptor signatures), the proposed solution is to use - in > place of the secret 't' - a suitably chosen schnorr signature. The end > result being that when one counterparty claims their side of the funds, the > party can obtain the signature they're missing to claim the funds in the > (schnorr) multisig that pays them. > > On-chain, this would appear like two independent transactions, even > though effectively the two parties have “exchanged” the history attached to > the UTXOs. Unlike a mixing service, in which all of the histories get > merged, with this protocol histories can be pairwise swapped without > anybody’s knowledge. > > > > ## Protocol description > > * Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2 > (controlled by Bob) wish to swap them. > > * Alice provides Bob with a single public key P_A > > * Bob provides Alice two pubkeys P_B1, P_B2. > > * Bob and Alice construct the P2PKH addresses Addr1 = Hash(P_A+P_B1) > [where the UTXO1 funds will be sent to eventually] and Addr2 = > Hash(P_A+P_B2) [where the UTXO2 funds will be sent to eventually] > > * Bob and Alice exchange time-locked refund transactions for the funding > transactions sending the funds to Addr1 and Addr2. > > * Bob and Alice submit the funding transactions (Alice pays to Addr1 > from UTXO1; Bob pays to Addr2 from UTXO2) > > * Alice sends Bob an adaptor signature: r1 + H(r1 | m)*x_a + r2 + H( r2 > | m')*x_a > > * Bob verifies the adaptor signature Alice sent contains a valid > signature for spending from Addr1 AND another valid signature for spending > from Addr2. Both signatures from Alice. Bob cannot separate out the two > signatures and hence cannot claim any of the funds, provided H( r1 | m) != > H( r2 | m') in the signature commitment. > > * Bob now sends Alice the valid signature: r2 + H( r2 | m' )*x_b2 > > * Alice can now add her signature to Bob's and get: r2 + H( r2| m' > )*(x_b2 + x_a) which is a valid signature to spend the funding transaction > sent to Addr2. > > * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that > signature to subtract his own: r2 + H( r2 | m' )*(x_b2 + x_a) - (r2 + H( r2 > | m' )*x_b2) = H( r2 | m ')*x_a > > * Bob takes the original adaptor signature and subtracts the known > quantity r2+ H( r2 | m' )*x_a, to get a valid signature: r1 + H( r1 | m > )*x_a > > * Bob can now add to that valid signature, his own signature and > retrieve the funds. > > ## Notes > > * It is possible for the counterparty to store copies of the signatures > as proof that such a join has taken place. But plausible deniability is > available upon discarding signatures since the joint private keys (x_a + > x_b*) are unavailable. > > > > I'm interested in hearing feedback on this idea if possible, and deemed > interesting enough. > > > > Best regards, > > -- > > Germán > > Mathematician > > > -- Germán Mathematician ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Good morning Germán, It looks to me like this is CoinSwap with Schnorr Scriptless Scripts. * https://joinmarket.me/blog/blog/coinswaps/ * https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr/ I also recently put up an article on extending such a protocol across 3 or more participants: * https://zmnscpxj.github.io/bitcoin/multiswap.html Regards, ZmnSCPxj > ## Objective > * Make atomic swaps within the same chain possible in a traceless way > * Achieving traceless same-chain atomic-swaps effectively turns an entire > chain into a (P2PKH) mixer by default > > ## Proposed solution > Similar to the way that atomic swaps would work with schnorr signatures (i.e. > leveraging adaptor signatures), the proposed solution is to use - in place of > the secret 't' - a suitably chosen schnorr signature. The end result being > that when one counterparty claims their side of the funds, the party can > obtain the signature they're missing to claim the funds in the (schnorr) > multisig that pays them. > On-chain, this would appear like two independent transactions, even though > effectively the two parties have “exchanged” the history attached to the > UTXOs. Unlike a mixing service, in which all of the histories get merged, > with this protocol histories can be pairwise swapped without anybody’s > knowledge. > > ## Protocol description > * Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2 > (controlled by Bob) wish to swap them. > * Alice provides Bob with a single public key P_A > * Bob provides Alice two pubkeys P_B1, P_B2. > * Bob and Alice construct the P2PKH addresses Addr1 = Hash(P_A+P_B1) [where > the UTXO1 funds will be sent to eventually] and Addr2 = Hash(P_A+P_B2) > [where the UTXO2 funds will be sent to eventually] > * Bob and Alice exchange time-locked refund transactions for the funding > transactions sending the funds to Addr1 and Addr2. > * Bob and Alice submit the funding transactions (Alice pays to Addr1 from > UTXO1; Bob pays to Addr2 from UTXO2) > * Alice sends Bob an adaptor signature: r1 + H(r1 | m)*x_a + r2 + H( r2 | > m')*x_a > * Bob verifies the adaptor signature Alice sent contains a valid signature > for spending from Addr1 AND another valid signature for spending from Addr2. > Both signatures from Alice. Bob cannot separate out the two signatures and > hence cannot claim any of the funds, provided H( r1 | m) != H( r2 | m') in > the signature commitment. > * Bob now sends Alice the valid signature: r2 + H( r2 | m' )*x_b2 > * Alice can now add her signature to Bob's and get: r2 + H( r2| m' )*(x_b2 + > x_a) which is a valid signature to spend the funding transaction sent to > Addr2. > * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that > signature to subtract his own: r2 + H( r2 | m' )*(x_b2 + x_a) - (r2 + H( r2 | > m' )*x_b2) = H( r2 | m ')*x_a > * Bob takes the original adaptor signature and subtracts the known quantity > r2+ H( r2 | m' )*x_a, to get a valid signature: r1 + H( r1 | m )*x_a > * Bob can now add to that valid signature, his own signature and retrieve the > funds. > ## Notes > * It is possible for the counterparty to store copies of the signatures as > proof that such a join has taken place. But plausible deniability is > available upon discarding signatures since the joint private keys (x_a + > x_b*) are unavailable. > > I'm interested in hearing feedback on this idea if possible, and deemed > interesting enough. > > Best regards, > -- > Germán > Mathematician ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures
Hello All, ## Objective * Make atomic swaps within the same chain possible in a traceless way * Achieving traceless same-chain atomic-swaps effectively turns an entire chain into a (P2PKH) mixer by default ## Proposed solution Similar to the way that atomic swaps would work with schnorr signatures (i.e. leveraging adaptor signatures), the proposed solution is to use - in place of the secret 't' - a suitably chosen schnorr signature. The end result being that when one counterparty claims their side of the funds, the party can obtain the signature they're missing to claim the funds in the (schnorr) multisig that pays them. On-chain, this would appear like two independent transactions, even though effectively the two parties have “exchanged” the history attached to the UTXOs. Unlike a mixing service, in which all of the histories get merged, with this protocol histories can be pairwise swapped without anybody’s knowledge. ## Protocol description * Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2 (controlled by Bob) wish to swap them. * Alice provides Bob with a single public key P_A * Bob provides Alice two pubkeys P_B1, P_B2. * Bob and Alice construct the P2PKH addresses Addr1 = Hash(P_A+P_B1) [where the UTXO1 funds will be sent to eventually] and Addr2 = Hash(P_A+P_B2) [where the UTXO2 funds will be sent to eventually] * Bob and Alice exchange time-locked refund transactions for the funding transactions sending the funds to Addr1 and Addr2. * Bob and Alice submit the funding transactions (Alice pays to Addr1 from UTXO1; Bob pays to Addr2 from UTXO2) * Alice sends Bob an adaptor signature: r1 + H(r1 | m)*x_a + r2 + H( r2 | m')*x_a * Bob verifies the adaptor signature Alice sent contains a valid signature for spending from Addr1 AND another valid signature for spending from Addr2. Both signatures from Alice. Bob cannot separate out the two signatures and hence cannot claim any of the funds, provided H( r1 | m) != H( r2 | m') in the signature commitment. * Bob now sends Alice the valid signature: r2 + H( r2 | m' )*x_b2 * Alice can now add her signature to Bob's and get: r2 + H( r2| m' )*(x_b2 + x_a) which is a valid signature to spend the funding transaction sent to Addr2. * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that signature to subtract his own: r2 + H( r2 | m' )*(x_b2 + x_a) - (r2 + H( r2 | m' )*x_b2) = H( r2 | m ')*x_a * Bob takes the original adaptor signature and subtracts the known quantity r2+ H( r2 | m' )*x_a, to get a valid signature: r1 + H( r1 | m )*x_a * Bob can now add to that valid signature, his own signature and retrieve the funds. ## Notes * It is possible for the counterparty to store copies of the signatures as proof that such a join has taken place. But plausible deniability is available upon discarding signatures since the joint private keys (x_a + x_b*) are unavailable. I'm interested in hearing feedback on this idea if possible, and deemed interesting enough. Best regards, -- Germán Mathematician ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
