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
next prev parent 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 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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