> In particular, you care more about privacy when you are contesting a
> close of a channel or other script path because then the miners could be more
> likely to extract a rent from you as "ransom" for properly closing your channel
> (or in other words, in a contested close the value of the closing transaction is
> larger than usual).

Not sure this point holds, independently of which Taproot/MASTmechanism deployed,
any time-sensitive transaction will likely leak its "contestness" by the setting of its
nSequence/nLocktime fields. E.g, for LN, justice tx are not encumbered by a CSV
delay which distinguish them from a non-revoked spend. And when you're relaying
htlcs and need to close unilaterally channel to prevent different settlement on
incoming/outgoing links the HTLC-timeout tx broadcast have a nLocktime set.

Beyond LN, timelocks are a privacy leak and miner-withholding vector for any
offchain protocols but this problem is not tied to Taproot design. Confidential
enforcement of them would be great but that's another debate..

Antoine








Le dim. 9 févr. 2020 à 15:40, Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a écrit :
Responding purely to one point as this may be sufficient to clear up
lots of discussion:

On 2/9/20 8:19 PM, Bryan Bishop via bitcoin-dev wrote:
> Is Taproot just a probability assumption about the frequency and
> likelihood of
> the signature case over the script case? Is this a good assumption?  The BIP
> only goes as far as to claim that the advantage is apparent if the outputs
> *could be spent* as an N of N, but doesn't make representations about
> how likely
> that N of N case would be in practice compared to the script paths. Perhaps
> among use cases, more than half of the ones we expect people to be doing
> could be
> spent as an N of N. But how frequently would that path get used?
> Further, while
> the *use cases* might skew toward things with N of N opt-out, we might
> end up in
> a power law case where it's the one case that doesn't use an N of N opt
> out at
> all (or at a de minimis level) that becomes very popular, thereby making
> Taproot
> more costly then beneficial.
Its not just about the frequency and likelihood, no. If there is a
clearly-provided optimization for this common case in the protocol, then
it becomes further more likely that developers put in the additional
effort required to make this possibility a reality. This has a very
significant positive impact on user privacy, especially those who wish
to utilize more advanced functionality in Bitcoin. Further, yes, it is
anticipated that the N of N case is possible to take in the vast
majority of deployed use-cases for advanced scripting systems, ensuring
that it is maximally efficient to do so (and thereby encouraging
developers to do so) is a key goal in this work.

Matt
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev