📅 Original date posted:2020-06-13
📝 Original message:Hello ZmnSCPxj,
On 11/06/2020 12:51, ZmnSCPxj wrote:
> Good morning Chris, and bitcoin-dev (but mostly Chris),
>
>
> I made a random comment regarding taint on bitcoin-dev recently: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html
>
>> For CoinSwap as well, we can consider that a CoinSwap server could make multiple CoinSwaps with various clients.
>> This leads to the CoinSwap server owning many small UTXOs, which it at some point aggregates into a large UTXO that it then uses to service more clients (for example, it serves many small clients, then has to serve a single large client that wants a single large UTXO for its own purposes).
>> This aggregation again leads to spreading of taint.
>
> I want to propose some particular behaviors a SwapMarket maker can engage in, to improve the privacy of its customers.
>
> Let us suppose that individual swaps use some variant of Succinct Atomic Swap.
> Takers take on the role of Alice in the SAS description, makers take on the role of Bob.
> We may be able to tweak the SAS protocol or some of its parameters for our purposes.
>
> Now, what we will do is to have the maker operate in rounds.
>
> Suppose two takers, T1 and T2, contact the sole maker M in its first ever round.
> T1 and T2 have some coins they want to swap.
> They arrange things all the way to confirmation of the Alice-side funding tx, and pause just before Bob creates its own funding tx for their individual swaps.
> The chain now shows these txes/UTXOs:
>
> 42 of T1 ---> 42 of T1 & M
> 50 of T2 ---> 50 of T2 & M
> 100 of T1 ---> 100 of T1 & M
>
> 200 of M -
>
> Now the entire point of operating in rounds is precisely so that M can service multiple clients at the same time with a single transaction, i.e. batching.
> So now M provides its B-side tx and complete the SAS protocols with each of the takers.
> SAS gives unilateral control of the outputs directly to the takers, so we elide the fact that they are really 2-of-2s below:
>
> 42 of T1 ---> 42 of T1 & M
> 50 of T2 ---> 50 of T2 & M
> 100 of T1 ---> 100 of T1 & M
>
> 200 of M +--> 11 of M
> +--> 140 of T1
> +--> 49 of T2
>
> (M extracted 1 unit from each incoming coin as fee; they also live in a fictional universe where miners mine transactions out of the goodness of their hearts.)
> Now in fact the previous transactions are, after the SAS, solely owned by M the maker.
> Now suppose on the next round, we have 3 new takers, T3, T4, and T5, who offer some coins to M to CoinSwap, leading to more blockchain data:
>
> 42 of T1 ---> 42 of T1 & M
> 50 of T2 ---> 50 of T2 & M
> 100 of T1 ---> 100 of T1 & M
>
> 200 of M -+-> 11 of M
> +-> 140 of T1
> +-> 49 of T2
>
> 22 of T3 ---> 22 of T3 & M
> 90 of T3 ---> 90 of T3 & M
> 11 of T4 ---> 11 of T4 & M
> 50 of T4 ---> 50 of T4 & M
> 20 of T5 ---> 20 of T5 & M
>
> In order to service all the new takers of this round, M takes the coins that it got from T1 and T2, and uses them to fund a new combined CoinSwap tx:
>
> 42 of T1 ---> 42 of T1 & M -+--+-> 110 of T3
> 50 of T2 ---> 50 of T2 & M -+ +-> 59 of T4
> 100 of T1 ---> 100 of T1 & M -+ +-> 14 of T5
> +-> 9 of M
> 200 of M -+-> 11 of M
> +-> 140 of T1
> +-> 49 of T2
>
> 22 of T3 ---> 22 of T3 & M
> 90 of T3 ---> 90 of T3 & M
> 11 of T4 ---> 11 of T4 & M
> 50 of T4 ---> 50 of T4 & M
> 15 of T5 ---> 15 of T5 & M
>
> That transaction, we can observe, looks very much like a batched transaction that a custodial service might produce.
>
> Now imagine more rounds, and I think you can begin to imagine that the magic of transaction batching, ported into SwapMarket, would help mitigate the blockchain size issues that CoinSwap has.
>
> Makers are expected to adopt this technique as this reduces the overall cost of transactions they produce, thus they are incentivized to use this technique to increase their profitability.
>
> At the same time, it spreads taint around and increases the effort that chain analysis must go through to identify what really happened.
>
> Regards,
> ZmnSCPxj
>
Would it be fair to summarize the idea in this way:
CoinSwappers can slow down the CoinSwap process which will give an
opportunity for makers to use batching.
Chris Belcher [ARCHIVE] /
npub1ek…lnm2u
2023-06-07 18:25:28
in reply to nevent1q…mf5k
Author Public Key
npub1ekvnqhww3aagwuj9t55dgj5y29u8cxdjllfv3vgppt8vc0zljhrs6lnm2uPublished at
2023-06-07 18:25:28Event JSON
{
"id": "84f69a98c71499e3fc92b4a87b65e8d49a9394ce2de331a38184ec3bf785c69e",
"pubkey": "cd99305dce8f7a8772455d28d44a8451787c19b2ffd2c8b1010acecc3c5f95c7",
"created_at": 1686162328,
"kind": 1,
"tags": [
[
"e",
"037339796b69a837a603acb802b61f4a99a31f4d94ccab270a00bd5d66d71199",
"",
"root"
],
[
"e",
"5a6fca404b4495708619bb299be370663ce4dc5fe4a7236e608359c84ee3bf6c",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-06-13\n📝 Original message:Hello ZmnSCPxj,\n\nOn 11/06/2020 12:51, ZmnSCPxj wrote:\n\u003e Good morning Chris, and bitcoin-dev (but mostly Chris),\n\u003e \n\u003e \n\u003e I made a random comment regarding taint on bitcoin-dev recently: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html\n\u003e \n\u003e\u003e For CoinSwap as well, we can consider that a CoinSwap server could make multiple CoinSwaps with various clients.\n\u003e\u003e This leads to the CoinSwap server owning many small UTXOs, which it at some point aggregates into a large UTXO that it then uses to service more clients (for example, it serves many small clients, then has to serve a single large client that wants a single large UTXO for its own purposes).\n\u003e\u003e This aggregation again leads to spreading of taint.\n\u003e \n\u003e I want to propose some particular behaviors a SwapMarket maker can engage in, to improve the privacy of its customers.\n\u003e \n\u003e Let us suppose that individual swaps use some variant of Succinct Atomic Swap.\n\u003e Takers take on the role of Alice in the SAS description, makers take on the role of Bob.\n\u003e We may be able to tweak the SAS protocol or some of its parameters for our purposes.\n\u003e \n\u003e Now, what we will do is to have the maker operate in rounds.\n\u003e \n\u003e Suppose two takers, T1 and T2, contact the sole maker M in its first ever round.\n\u003e T1 and T2 have some coins they want to swap.\n\u003e They arrange things all the way to confirmation of the Alice-side funding tx, and pause just before Bob creates its own funding tx for their individual swaps.\n\u003e The chain now shows these txes/UTXOs:\n\u003e \n\u003e 42 of T1 ---\u003e 42 of T1 \u0026 M\n\u003e 50 of T2 ---\u003e 50 of T2 \u0026 M\n\u003e 100 of T1 ---\u003e 100 of T1 \u0026 M\n\u003e \n\u003e 200 of M -\n\u003e \n\u003e Now the entire point of operating in rounds is precisely so that M can service multiple clients at the same time with a single transaction, i.e. batching.\n\u003e So now M provides its B-side tx and complete the SAS protocols with each of the takers.\n\u003e SAS gives unilateral control of the outputs directly to the takers, so we elide the fact that they are really 2-of-2s below:\n\u003e \n\u003e 42 of T1 ---\u003e 42 of T1 \u0026 M\n\u003e 50 of T2 ---\u003e 50 of T2 \u0026 M\n\u003e 100 of T1 ---\u003e 100 of T1 \u0026 M\n\u003e \n\u003e 200 of M +--\u003e 11 of M\n\u003e +--\u003e 140 of T1\n\u003e +--\u003e 49 of T2\n\u003e \n\u003e (M extracted 1 unit from each incoming coin as fee; they also live in a fictional universe where miners mine transactions out of the goodness of their hearts.)\n\u003e Now in fact the previous transactions are, after the SAS, solely owned by M the maker.\n\u003e Now suppose on the next round, we have 3 new takers, T3, T4, and T5, who offer some coins to M to CoinSwap, leading to more blockchain data:\n\u003e \n\u003e 42 of T1 ---\u003e 42 of T1 \u0026 M\n\u003e 50 of T2 ---\u003e 50 of T2 \u0026 M\n\u003e 100 of T1 ---\u003e 100 of T1 \u0026 M\n\u003e \n\u003e 200 of M -+-\u003e 11 of M\n\u003e +-\u003e 140 of T1\n\u003e +-\u003e 49 of T2\n\u003e \n\u003e 22 of T3 ---\u003e 22 of T3 \u0026 M\n\u003e 90 of T3 ---\u003e 90 of T3 \u0026 M\n\u003e 11 of T4 ---\u003e 11 of T4 \u0026 M\n\u003e 50 of T4 ---\u003e 50 of T4 \u0026 M\n\u003e 20 of T5 ---\u003e 20 of T5 \u0026 M\n\u003e \n\u003e In order to service all the new takers of this round, M takes the coins that it got from T1 and T2, and uses them to fund a new combined CoinSwap tx:\n\u003e \n\u003e 42 of T1 ---\u003e 42 of T1 \u0026 M -+--+-\u003e 110 of T3\n\u003e 50 of T2 ---\u003e 50 of T2 \u0026 M -+ +-\u003e 59 of T4\n\u003e 100 of T1 ---\u003e 100 of T1 \u0026 M -+ +-\u003e 14 of T5\n\u003e +-\u003e 9 of M\n\u003e 200 of M -+-\u003e 11 of M\n\u003e +-\u003e 140 of T1\n\u003e +-\u003e 49 of T2\n\u003e \n\u003e 22 of T3 ---\u003e 22 of T3 \u0026 M\n\u003e 90 of T3 ---\u003e 90 of T3 \u0026 M\n\u003e 11 of T4 ---\u003e 11 of T4 \u0026 M\n\u003e 50 of T4 ---\u003e 50 of T4 \u0026 M\n\u003e 15 of T5 ---\u003e 15 of T5 \u0026 M\n\u003e \n\u003e That transaction, we can observe, looks very much like a batched transaction that a custodial service might produce.\n\u003e \n\u003e Now imagine more rounds, and I think you can begin to imagine that the magic of transaction batching, ported into SwapMarket, would help mitigate the blockchain size issues that CoinSwap has.\n\u003e \n\u003e Makers are expected to adopt this technique as this reduces the overall cost of transactions they produce, thus they are incentivized to use this technique to increase their profitability.\n\u003e \n\u003e At the same time, it spreads taint around and increases the effort that chain analysis must go through to identify what really happened.\n\u003e \n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e \n\nWould it be fair to summarize the idea in this way:\n\nCoinSwappers can slow down the CoinSwap process which will give an\nopportunity for makers to use batching.",
"sig": "2316a81bbb99138591eb4b98746f36fcbf6f9ae57911e60039184f0b82dc4df58c0cb436e4f3450d0c5ab9684cbd35276c434cde048b0c90d4e23014a4c56b62"
}