Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-07-17 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

> On 13/06/2020 15:06, ZmnSCPxj wrote:
>
> > Good morning Chris,
> >
> > > 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.
> >
> > I think so.
> > Regards,
> > ZmnSCPxj
>
> It's definitely a good idea. As well as improving privacy by pretending
> to be a service provider which uses batching, it may also be practical
> just because CoinSwap takers will want to slow down the process for
> greater privacy so that an adversary would have to search more of the
> blockchain to attempt to deanonymize them. Also, by being prepared to
> wait longer the takers will also save miner fees.

Despite the subject title, I have realized belatedly that the same kind of 
batching can be done by the taker as well.

For example, the taker can contact two makers in parallel to setup separate 
CoinSwaps with them.
Then the taker produces a transaction spending its funds and sending them out 
to two outputs.

If the taker uses P2PKH for receiving and change, and we use (via 2p-ECDSA) 
P2PKH 2-of-2 to anchor the swaps, then if both CoinSwap operations are 
successful, the transaction looks exactly like an ordinary 
pay-to-someone-and-get-back-change transaction.

Indeed, each of the two makers contacted, if they are not themselves colluding 
with each other, cannot really differentiate this from somebody doing a 
CoinSwap only with them, since the other output is indistinguishable from 
change.

I am uncertain how much extra privacy (or cheapness) this buys the taker, 
however.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-13 Thread Chris Belcher via bitcoin-dev
On 13/06/2020 15:06, ZmnSCPxj wrote:
> Good morning Chris,
> 
>>
>> 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.
> 
> I think so.
> 
> Regards,
> ZmnSCPxj
> 

It's definitely a good idea. As well as improving privacy by pretending
to be a service provider which uses batching, it may also be practical
just because CoinSwap takers will want to slow down the process for
greater privacy so that an adversary would have to search more of the
blockchain to attempt to deanonymize them. Also, by being prepared to
wait longer the takers will also save miner fees.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-13 Thread ZmnSCPxj via bitcoin-dev
Good morning Chris,

>
> 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.

I think so.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-13 Thread Chris Belcher via bitcoin-dev
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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-11 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev