From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2CCD5C0051 for ; Sat, 5 Sep 2020 02:45:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 1AB6086AD8 for ; Sat, 5 Sep 2020 02:45:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXTcD8GLshcz for ; Sat, 5 Sep 2020 02:45:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by whitealder.osuosl.org (Postfix) with ESMTPS id E1B1286A6D for ; Sat, 5 Sep 2020 02:45:09 +0000 (UTC) Date: Sat, 05 Sep 2020 02:45:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1599273907; bh=YfWogWmoGurn7bAc/ltsD29rdIWVxzE4O2yJoUQ2sbc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=TgQJuUsQLQ3YkJbBrdaWQ4QjsUcPPKzmDA+QgFdUPJmM/jv/SZE1uW9J3Y79RQoy1 g94E5lFnknXGKc6YNgZZlqYyZgU3Waerttr8qVRHc7bd0e0pwQ8NPr6ozLT0WY7TlW iWDNctlWJFSzAOGIgSJPbaXBI+mZrRz+wTyTIcwQ= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net> <8f387b40-8212-9807-70cc-b527902609c2@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 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 02:45:12 -0000 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