<p>See Pieter's responses.
(1) seems ok
(2) Mark's concern is real, but worry about exposing the tweaked pubkey doesn't seem to be of a high concern to people supporting Taproot. In ref to Taproot exposing pubkey, &quot;numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier).&quot;</p>
<p>&quot;TL;DR: public keys should be public.&quot;</p>
<p>Quotes from:
<a href="https://bitcoin.stackexchange.com/questions/95123/what-are-the-potential-attacks-against-ecdsa-that-would-be-possible-if-we-used-r/95133#95133">What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?</a></p>

CC BY-SA 4.0
2021-05-24T04:04:53.943Z
2021-05-24T04:04:53.943Z
Michael Tidwell
<p>Here seeking information. I have 2 questions marked with parens</p>
<p>Would like some clarification pertaining to the Mark Friedenbach article:</p>
<ul>
<li><a href="https://freicoin.substack.com/p/why-im-against-taproot" rel="nofollow noreferrer">Why I'm Against Taproot</a></li>
</ul>
<p>The point of contention with Mark seems to be with the space savings for the N-N Musig2 everyone signs/happy path, being embedded into the the root of the MAST/Taproot, thus exposing a pubkey in an output that sits on the blockchain.</p>
<p>(1) please correct if I'm wrong about the way I'm describing this.</p>
<p>I did see Pieter's presentation at Bitdevs from a while back reference, &quot;plain pubkey security model in mind&quot; for taproot. But, it wasn't apparent that this would hypothetically make it quantum vulnerable,.. as Mark's article says, &quot;a naked secp256k1 pubkey on chain at the time the output is created which has absolute spend authority for the underlying bitcoins&quot;.</p>
<p>(2) Would love for someone to rebut or verify this claim.</p>

CC BY-SA 4.0
2021-05-24T02:08:40.667Z
See https://bitcoin.stackexchange.com/a/95133/208
Pieter Wuille
CC BY-SA 4.0
2021-05-24T03:13:03.537Z
Help me understand something.. a pubkey for bech32 (native segwit v0) is only revealed on a spend. Segwit v1 will make it where a pubkey is available before a spend?
Michael Tidwell
CC BY-SA 4.0
2021-05-24T03:43:50.077Z
Yes, the (tweaked) pubkey goes directly in the scriptPubKey.
Pieter Wuille
<taproot><schnorr-signatures><musig><quantum-computing>
Taproot, potential quantum bug, and general clarification
Michael Tidwell
# Taproot, potential quantum bug, and general clarification

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

Here seeking information. I have 2 questions marked with parens

Would like some clarification pertaining to the Mark Friedenbach article:

* [Why I'm Against Taproot](https://freicoin.substack.com/p/why-im-against-taproot)

The point of contention with Mark seems to be with the space savings for the N-N Musig2 everyone signs/happy path, being embedded into the the root of the MAST/Taproot, thus exposing a pubkey in an output that sits on the blockchain.

(1) please correct if I'm wrong about the way I'm describing this.

I did see username_1's presentation at Bitdevs from a while back reference, "plain pubkey security model in mind" for taproot. But, it wasn't apparent that this would hypothetically make it quantum vulnerable,.. as Mark's article says, "a naked secp256k1 pubkey on chain at the time the output is created which has absolute spend authority for the underlying bitcoins".

(2) Would love for someone to rebut or verify this claim.

**Tags:** taproot, schnorr-signatures, musig, quantum-computing

> **Comments:**
> **username_1**: See https://bitcoin.stackexchange.com/a/95133/208  
> **username_0**: Help me understand something.. a pubkey for bech32 (native segwit v0) is only revealed on a spend. Segwit v1 will make it where a pubkey is available before a spend?  
> **username_1**: Yes, the (tweaked) pubkey goes directly in the scriptPubKey.  

---

## 1 answers

### Answer by username_0 on 2021-05-24. Score: 1 | Accepted answer

See username_1's responses.
(1) seems ok
(2) Mark's concern is real, but worry about exposing the tweaked pubkey doesn't seem to be of a high concern to people supporting Taproot. In ref to Taproot exposing pubkey, "numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier)."

"TL;DR: public keys should be public."

Quotes from:
[What are the potential attacks against ECDSA that would be possible if we used raw public keys as addresses?](https://bitcoin.stackexchange.com/questions/95123/what-are-the-potential-attacks-against-ecdsa-that-would-be-possible-if-we-used-r/95133#95133)


---

