Date: Sat, 05 Sep 2020 02:45:00 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <w4WQcFmuXVY25fP69czESim9yHGOIB8v5G7jRnSiV5cqhpDXD9tG0AzFqWPUIxbFKfP1Kr-0mOuGocUVpBacFCTOAvRnO1MxBOcxB-w1KjM=@protonmail.com>
In-Reply-To: <Vf-RtORZUR0QYHZiYeyfVyJEIQbh0RYnPpZEeeDiIwaiGvu-R9wxhHm6D4b_Nwd8Ia2n6u2OL4u48Ra6t8BGWOCgGXJpFkFWQeAX2S4ijiI=@protonmail.com>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
 <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net>
 <bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com>
 <8f387b40-8212-9807-70cc-b527902609c2@riseup.net>
 <Vf-RtORZUR0QYHZiYeyfVyJEIQbh0RYnPpZEeeDiIwaiGvu-R9wxhHm6D4b_Nwd8Ia2n6u2OL4u48Ra6t8BGWOCgGXJpFkFWQeAX2S4ijiI=@protonmail.com>
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
Precedence: list

Good morning Chris, and probably also Lightningers,

> However, it might be possible to prevent the maker from learning the coll=
ateral input at all.
>
> If my understanding of BIP-143 is correct, inputs are hashed separately (=
`hashPrevouts`) from outputs (`hashOutputs`).
> Bob can provide the `hashPrevouts` as an opaque hash, while providing a d=
ecommitment of `hashOutputs` to show that the outputs of the collateralized=
 contract transaction are correct, which is all that Charlie really needs t=
o know.
>
> Bob is incentivized to provide the correct `hashPrevouts`, because if it =
provides an incorrect `hashPrevouts` it cannot get a signature for a transa=
ction it can use in case of a protocol abort, thus potentially losing its m=
oney in case of a protocol abort.
> Conversely, Charlie does not care where Bob gets the funds that goes into=
 its contract output come from, it only cares that the Bob collateralized c=
ontract output is I+K.
> It loses nothing to sign that transaction, and it would prefer that trans=
action since its own contract output is only I.
>
> This solution is mildly "unclean" as it depends on the details of the sig=
hash algorithm, though, and is not proposed seriously.
> Hopefully nobody will change the sighash algorithm anytime soon.........
>
> In addition, it complicates reusing Lightning watchtowers.
> Lightning watchtowers currently trigger on txid (i.e. it would have trigg=
ered on the txid of the B collateralized contract tx), but watching this ne=
eds to trigger on the spend of a txo, since it is not possible to prove tha=
t a specific `hashPrevouts` etc. goes with a specific txid without revealin=
g the whole tx (which is precisely what we are trying to avoid), as both ar=
e hashes.
> Watchtowers may need to be entrusted with privkeys, or need to wait for `=
SIGHASH_ANYPREVOUT` so that the exact txid of the B collateralized contract=
 tx does not need to be fixed at signing time, thus this solution is undesi=
rable as well.

On the other hand, when considering Decker-Russell-Osuntokun, the `(halftxi=
d, encrypted_blob)` approach to watchtowers simply does not work.
Watchtowers are simpler in Decker-Russell-Osuntoku if and only if the watch=
tower knows the funding outpoint, therefore knows which channel it is watch=
ing *before* an attack on the channel occurs, and is less private.

I have argued before that we should instead use `(sighash[0:15], encrypted_=
blob)` rather than `(txid[0:15], encrypted_blob)`.
This makes Decker-Russell-Osuntokun blobs indistinguishable from Poon-Dryja=
 blobs, and the watchtower is not even made aware what the commitment type =
of the channel is until an actual attack occurs.

If watchtowers use `(sighash[0:15], encrypted_blob)` instead, the proposal =
to hide the collateral input behind `hashPrevouts` would be workable, as Ch=
arlie knows the entire sighash of the B collateralized contract transaction=
 even if it does not know the txid.
This also does not reveal the funding outpoint, or whether it is watching a=
 Poon-Dryja channel, a Decker-Russell-Osuntokun channel, or a CoinSwap.

--

Even if we propose that CoinSwap makers should run their own watchtowers ra=
ther than hire a public watchtower, it's safer for a CoinSwap maker to have=
 watchtowers that are unaware of exactly *what* they are watching.
If the watchtowers are aware of the funding outputs they are watching, then=
 every additional watchtower a maker creates increases the attack surface o=
n the privacy of the maker, as the funding outputs becoming known allows th=
e maker hodlings to be derived.

If watchtowers only get a partial sighash, then the information that they c=
ontain are not sufficient by themselves to determine what coins are owned b=
y the maker, thus every additional watchtower is no longer a potential atta=
ck vector on the privacy of the maker.

So this is off-topic, but anyway, we should probably move to using `sighash=
[0:15]` instead of `txid[0:15]` for watchtowers.


Regards,
ZmnSCPxj