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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev