public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Sat, 05 Sep 2020 02:45:00 +0000	[thread overview]
Message-ID: <w4WQcFmuXVY25fP69czESim9yHGOIB8v5G7jRnSiV5cqhpDXD9tG0AzFqWPUIxbFKfP1Kr-0mOuGocUVpBacFCTOAvRnO1MxBOcxB-w1KjM=@protonmail.com> (raw)
In-Reply-To: <Vf-RtORZUR0QYHZiYeyfVyJEIQbh0RYnPpZEeeDiIwaiGvu-R9wxhHm6D4b_Nwd8Ia2n6u2OL4u48Ra6t8BGWOCgGXJpFkFWQeAX2S4ijiI=@protonmail.com>

Good morning Chris, and probably also Lightningers,

> However, it might be possible to prevent the maker from learning the collateral 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 decommitment of `hashOutputs` to show that the outputs of the collateralized contract transaction are correct, which is all that Charlie really needs to know.
>
> Bob is incentivized to provide the correct `hashPrevouts`, because if it provides an incorrect `hashPrevouts` it cannot get a signature for a transaction it can use in case of a protocol abort, thus potentially losing its money 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 contract output is I+K.
> It loses nothing to sign that transaction, and it would prefer that transaction since its own contract output is only I.
>
> This solution is mildly "unclean" as it depends on the details of the sighash 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 triggered on the txid of the B collateralized contract tx), but watching this needs to trigger on the spend of a txo, since it is not possible to prove that a specific `hashPrevouts` etc. goes with a specific txid without revealing the whole tx (which is precisely what we are trying to avoid), as both are 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 undesirable as well.

On the other hand, when considering Decker-Russell-Osuntokun, the `(halftxid, encrypted_blob)` approach to watchtowers simply does not work.
Watchtowers are simpler in Decker-Russell-Osuntoku if and only if the watchtower knows the funding outpoint, therefore knows which channel it is watching *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 Charlie 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 rather 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 on the privacy of the maker, as the funding outputs becoming known allows the maker hodlings to be derived.

If watchtowers only get a partial sighash, then the information that they contain are not sufficient by themselves to determine what coins are owned by the maker, thus every additional watchtower is no longer a potential attack 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


  reply	other threads:[~2020-09-05  2:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11 12:05 [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap Chris Belcher
2020-08-20 11:17 ` ZmnSCPxj
2020-08-20 15:28   ` Nadav Kohen
2020-08-20 21:38     ` ZmnSCPxj
2020-08-20 22:37       ` Chris Belcher
2020-08-20 22:15   ` Chris Belcher
2020-08-21  4:20     ` ZmnSCPxj
2020-08-21  9:47       ` Chris Belcher
2020-08-22  1:09         ` ZmnSCPxj
2020-08-24 19:30 ` Antoine Riard
2020-08-25  3:16   ` ZmnSCPxj
2020-09-03  9:00     ` Chris Belcher
2020-09-03  9:45       ` ZmnSCPxj
2020-09-03 10:50         ` Chris Belcher
2020-09-03 23:39           ` ZmnSCPxj
2020-09-05  2:45             ` ZmnSCPxj [this message]
2020-09-05  1:10     ` Antoine Riard
2020-09-05  2:29       ` ZmnSCPxj
2020-08-29 22:03   ` Chris Belcher
2020-08-30 13:38     ` ZmnSCPxj
2020-09-05  1:07     ` Antoine Riard
2020-09-06  3:06       ` seid Mohammed
2020-10-03 10:36 ` [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher
2020-10-03 13:31   ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='w4WQcFmuXVY25fP69czESim9yHGOIB8v5G7jRnSiV5cqhpDXD9tG0AzFqWPUIxbFKfP1Kr-0mOuGocUVpBacFCTOAvRnO1MxBOcxB-w1KjM=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox