Date: Sat, 03 Oct 2020 13:31:58 +0000
To: Chris Belcher <belcher@riseup.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <hFfdzFfmpu_9RKZnEAiA4D9cZUos1wGES7Gryb_pc-2NPw5smt5IfNLgCZHzJLr27VkFYADYS7xJoDP6o6i8KndI27-KSsAQY6j025saxpo=@protonmail.com>
In-Reply-To: <be095fe7-77ca-f471-43e4-981076f48ed2@riseup.net>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <be095fe7-77ca-f471-43e4-981076f48ed2@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
	multi-transaction CoinSwap appendium
Precedence: list

Good morning Chris,

>
> Looking at these equations, I realize that the incentives against
> post-coinswap-theft-attempt still work even if we set K =3D 0, because th=
e
> extra miner fee paid by Bob could be enough disincentive.

This made me pause for a moment, but on reflection, is correct.

The important difference here relative to v1 is that the mining fee for the=
 collateralized contract transaction is deducted from the `Jb` input provid=
ed by Bob.


>     Unlike the v1 protocol, each CoinSwap party knows a different version=
 of
>     the contract transactions, so the taker Alice always knows which make=
r
>     broadcast a certain set of contract transactions, and so can always b=
an
>     the correct fidelity bond.

Great observation, and an excellent property to have.

Will go think about this more.

Regards,
ZmnSCPxj