<p>See question: <a href="https://bitcoin.stackexchange.com/q/123500/121614">Is there an economic incentive to use P2WSH over P2TR?</a></p>
<p>The answer is, if you're absolutely sure you don't need any of Taproot's features, then a P2TR input costs a bit more than a P2WSH input with the same script.</p>
<p>However, Taproot does have features that could be useful to you:</p>
<ul>
<li><strong>Script tree</strong>: Splitting a script into multiple alternative conditions and only revealing one of them when spending is perfect for HTLCs.</li>
<li><strong>PTLCs</strong>: <a href="https://bitcoinops.org/en/topics/ptlc/" rel="nofollow noreferrer">Point Time Locked Contracts</a> are a more efficient and private alternative to HTLCs. A successful execution of a PTLC doesn't need to use the script path at all.</li>
<li><strong>Privacy</strong>: Because P2TR combines key and script spending, an unspent P2TR output reveals less information than either a P2WPKH or P2WSH output. Additionally, P2TR outputs are already more common than P2WSH outputs, so you might want to choose the larger anonymity set.</li>
</ul>

CC BY-SA 4.0
2024-12-02T07:22:24.570Z
I was also interested in PTLCs, but as I understand it they cannot be used on Ethereum ([section 3.2.1 here](https://blog.bitlayer.org/Adaptor_Signatures_and_Its_Application_to_Cross-Chain_Atomic_Swaps/)) which would be quite limiting for my use case.
rdong8
CC BY-SA 4.0
2024-12-01T07:43:28.547Z
2024-12-01T07:43:28.547Z
Vojtěch Strnad
<p>Interested in making an HTLC, in which case there should not be a key spending path. According to <a href="https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path">this post</a>, one can set the internal public key to an essentially arbitrary value and just use the script path. But then is there any advantage to using P2TR over P2WSH?</p>

CC BY-SA 4.0
2024-12-01T07:15:27.333Z
See also: [Is there an economic incentive to use P2WSH over P2TR?](https://bitcoin.stackexchange.com/q/123500/121614)
Vojtěch Strnad
<segregated-witness><taproot><p2tr><hash-time-locked-contract><p2wpkh>
Is there a point to using taproot transactions over P2WSH if I only want to use the script path?
rdong8
# Is there a point to using taproot transactions over P2WSH if I only want to use the script path?

(Asked by: username_0 on 2024-12-01)

Interested in making an HTLC, in which case there should not be a key spending path. According to [this post](https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path), one can set the internal public key to an essentially arbitrary value and just use the script path. But then is there any advantage to using P2TR over P2WSH?

**Tags:** segregated-witness, taproot, p2tr, hash-time-locked-contract, p2wpkh

> **Comments:**
> **username_1**: See also: [Is there an economic incentive to use P2WSH over P2TR?](https://bitcoin.stackexchange.com/q/123500/121614)  

---

## 1 answers

### Answer by username_1 on 2024-12-01. Score: 3 | Accepted answer

See question: [Is there an economic incentive to use P2WSH over P2TR?](https://bitcoin.stackexchange.com/q/123500/121614)

The answer is, if you're absolutely sure you don't need any of Taproot's features, then a P2TR input costs a bit more than a P2WSH input with the same script.

However, Taproot does have features that could be useful to you:

* **Script tree**: Splitting a script into multiple alternative conditions and only revealing one of them when spending is perfect for HTLCs.
* **PTLCs**: [Point Time Locked Contracts](https://bitcoinops.org/en/topics/ptlc/) are a more efficient and private alternative to HTLCs. A successful execution of a PTLC doesn't need to use the script path at all.
* **Privacy**: Because P2TR combines key and script spending, an unspent P2TR output reveals less information than either a P2WPKH or P2WSH output. Additionally, P2TR outputs are already more common than P2WSH outputs, so you might want to choose the larger anonymity set.

> **Comments:**
> **username_0**: I was also interested in PTLCs, but as I understand it they cannot be used on Ethereum ([section 3.2.1 here](https://blog.bitlayer.org/Adaptor_Signatures_and_Its_Application_to_Cross-Chain_Atomic_Swaps/)) which would be quite limiting for my use case.  

---

