<p>The foundation of a channel is a multisig output which can't be distinguished from other outputs when using musig and taproot.</p>
<p>The mutual channel close is just a regular tx spending this output so I'd say it'll be hard to detect this as a lightning Chanel without other data (similar as with current channels)</p>
<p>However the unilateral close is different and leaves a footprint of the channel state. I think the update transaction that is used to kick of the settlement tx might have the detectable structure that you have been referring to. (I'd actually like to ask you for your source)</p>

CC BY-SA 4.0
2021-05-23T02:03:07.140Z
I'm aware of the limitations in current Taproot proposal in the event of a non-cooperative close. What I'm wondering though is if anyprevout would impact even the cooperative case since it is proposed to use a different pubkey length? Unless I'm misunderstanding something (most likely) then it seems like anybody using the Eltoo protocol with anyprevout would have their channel operations easily visible onchain. My source for the pubkey length difference is this snippet from AJ Towns on the Stephan Livera podcast: https://youtu.be/8S7D_FdZfE8?t=2978
user121612
CC BY-SA 4.0
2021-05-23T02:10:43.953Z
I think the update txs use anyprevout but in the case of the mutual close it will just be a regular spend as mentioned without the need of anyprevout. (There won't be any update tx in the mutual close as partners can negotiate the spend from the funding TX directly - unless I am missing something, which also could happen.
Rene Pickhardt
CC BY-SA 4.0
2021-05-23T03:09:56.560Z
Ok interesting. So in that case the use of anyprevout for eltoo would only be visible if the channel was closed unilaterally? That's more like the original Taproot assumption. If simply scanning the chain for 33 byte pubkeys is possible then eltoo doesn't seem to have much privacy despite the scaling benefits it can bring
user121612
CC BY-SA 4.0
2021-05-22T23:33:20.633Z
2021-05-22T23:33:20.633Z
Rene Pickhardt
<p>One of the advantages I've heard about Taproot is that all transactions will appear identical to a blockchain observer. This would of course also be true for lightning channel open/close transactions as well which would be a great privacy benefit for lightning users.</p>
<p>For what I understand of the proposed ANYPREVOUT upgrade, it will build on top of Taproot but will need to use a different length pubkey. Would it be possible for an observer to scan the blockchain for this pubkey length in order to determine which transactions are using ANYPREVOUT, and are therefore likely to be lightning related? Or is it possible to somehow hide this inside Taproot in such a way that privacy can still be maintained?</p>

<lightning-network><privacy><taproot><bip118-sighash-anyprevout>
Does the future SIGHASH_ANYPREVOUT capability hurt the privacy of Taproot lightning channels?
user121612
# Does the future SIGHASH_ANYPREVOUT capability hurt the privacy of Taproot lightning channels?

(Asked by: username_0 on 2021-05-22)

One of the advantages I've heard about Taproot is that all transactions will appear identical to a blockchain observer. This would of course also be true for lightning channel open/close transactions as well which would be a great privacy benefit for lightning users.

For what I understand of the proposed ANYPREVOUT upgrade, it will build on top of Taproot but will need to use a different length pubkey. Would it be possible for an observer to scan the blockchain for this pubkey length in order to determine which transactions are using ANYPREVOUT, and are therefore likely to be lightning related? Or is it possible to somehow hide this inside Taproot in such a way that privacy can still be maintained?

**Tags:** lightning-network, privacy, taproot, bip118-sighash-anyprevout


---

## 1 answers

### Answer by username_1 on 2021-05-22. Score: 4

The foundation of a channel is a multisig output which can't be distinguished from other outputs when using musig and taproot.

The mutual channel close is just a regular tx spending this output so I'd say it'll be hard to detect this as a lightning Chanel without other data (similar as with current channels)

However the unilateral close is different and leaves a footprint of the channel state. I think the update transaction that is used to kick of the settlement tx might have the detectable structure that you have been referring to. (I'd actually like to ask you for your source)

> **Comments:**
> **username_0**: I'm aware of the limitations in current Taproot proposal in the event of a non-cooperative close. What I'm wondering though is if anyprevout would impact even the cooperative case since it is proposed to use a different pubkey length? Unless I'm misunderstanding something (most likely) then it seems like anybody using the Eltoo protocol with anyprevout would have their channel operations easily visible onchain. My source for the pubkey length difference is this snippet from AJ Towns on the Stephan Livera podcast: https://youtu.be/8S7D_FdZfE8?t=2978  
> **username_1**: I think the update txs use anyprevout but in the case of the mutual close it will just be a regular spend as mentioned without the need of anyprevout. (There won't be any update tx in the mutual close as partners can negotiate the spend from the funding TX directly - unless I am missing something, which also could happen.  
> **username_0**: Ok interesting. So in that case the use of anyprevout for eltoo would only be visible if the channel was closed unilaterally? That's more like the original Taproot assumption. If simply scanning the chain for 33 byte pubkeys is possible then eltoo doesn't seem to have much privacy despite the scaling benefits it can bring  

---

