Hello list,
This email is an appendium or modification of the earlier CoinSwap
protocol published on this list. It is intended to fix the problems
found in review. (Original email quoted here too)
On 11/08/2020 13:05, Chris Belcher via bitcoin-dev wrote:
> I'm currently working on implementing CoinSwap (see my other email
> "Design for a CoinSwap implementation for massively improving Bitcoin
> privacy and fungibility").
>
> CoinSwaps are special because they look just like regular bitcoin
> transactions, so they improve the privacy even for people who do not use
> them. Once CoinSwap is deployed, anyone attempting surveillance of
> bitcoin transactions will be forced to ask themselves the question: how
> do we know this transaction wasn't a CoinSwap?
>
> This email contains a detailed design of the first protocol version. It
> makes use of the building blocks of multi-transaction CoinSwaps, routed
> CoinSwaps, liquidity market, private key handover, and fidelity bonds.
> It does not include PayJoin-with-CoinSwap, but that's in the plan to be
> added later.
>
> == Routed CoinSwap ==
>
> Diagram of CoinSwaps in the route:
>
> Alice > Bob > Charlie > Alice
>
> Where (>) means one CoinSwap. Alice gives coins to Bob, who gives
> coins to Charlie, who gives coins to Alice. Alice is the market taker
> and she starts with the hash preimage. She chooses the CoinSwap amount
> and chooses who the makers will be.
>
> This design has one market taker and two market makers in its route, but
> it can easily be extended to any number of makers.
>
> == Multiple transactions ==
>
> Each single CoinSwap is made up of multiple transactions to avoid amount
> correlation
>
> (a0 BTC) ---> (b0 BTC) ---> (c0 BTC) --->
> Alice (a1 BTC) ---> Bob (b1 BTC) ---> Charlie (c1 BTC) ---> Alice
> (a2 BTC) ---> (b2 BTC) ---> (c2 BTC) --->
>
> The arrow (--->) represent funding transactions. The money gets paid to
> a 2-of-2 multisig but after the CoinSwap protocol and private key
> handover is done they will be controlled by the next party in the route.
>
> This example has 6 regular-sized transactions which use approximately
> the same amount of block space as a single JoinMarket coinjoin with 6
> parties (1 taker, 5 makers). Yet the privacy provided by this one
> CoinSwap would be far far greater. It would not have to be repeated in
> the way that Equal-Output CoinJoins must be.
>
> == Direct connections to Alice ===
>
> Only Alice, the taker, knows the entire route, Bob and Charlie just know
> their previous and next transactions. Bob and Charlie do not have direct
> connections with each other, only with Alice.
>
> Diagram of Tor connections:
>
> Bob Charlie
> | /
> | /
> | /
> Alice
>
> When Bob and Charlie communicate, they are actually sending and
> receiving messages via Alice who relays them to Charlie or Bob. This
> helps hide whether the previous or next counterparty in a CoinSwap route
> is a maker or taker.
>
> This doesn't have security issues even in the final steps where private
> keys are handed over, because those private keys are always for 2-of-2
> multisig and so on their own are never enough to steal money.
>
>
> === Miner fees ===
>
> Makers have no incentive to pay any miner fees. They only do
> transactions which earn them an income and are willing to wait a very
> long time for that to happen. By contrast takers want to create
> transactions far more urgently. In JoinMarket we coded a protocol where
> the maker could contribute to miner fees, but the market price offered
> of that trended towards zero. So the reality is that takers will pay all
> the miner fees. Also because makers don't know the taker's time
> preference they don't know how much they should pay in miner fees.
>
> The taker will have to set limits on how large the maker's transactions
> are, otherwise makers could abuse this by having the taker consolidate
> maker's UTXOs for free.
>
> == Funding transaction definitions ==
>
> Funding transactions are those which pay into the 2-of-2 multisig addresses.
>
> Definitions:
> I = initial coinswap amount sent by Alice = a0 + a1 + a2
> (WA, WB, WC) = Total value of UTXOs being spent by Alice, Bob, Charlie
>respectively. Could be called "wallet Alice", "wallet
>Bob", etc
> (B, C) = Coinswap fees paid by Alice and earned by Bob and Charlie.
> (M1, M2, M3) = Miner fees of the first, second, third, etc sets of
>funding transactions. Alice will choose what these are
>since she's paying.
> multisig(A+B) = A 2of2 multisig output with private keys held by A and B
>
> The value in square parentheses refers to the bitcoin amount.
>
> Alice funding txes
> [WA btc] ---> multisig (Alice+Bob) [I btc]
> change [WA-M1-I btc]
> Bob funding txes
> [WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc]
>
