<p>This was discussed today on the <a href="https://botbot.me/freenode/bitcoin-wizards/msg/100716593/" rel="nofollow noreferrer">#bitcoin-wizards</a> IRC channel.  The reasons offered by Andrew Poelstra (andytoshi) were:</p>

<ol>
<li><p>"Segwit had enough scope already."  That is, it was already a large change that some people considered controversial, so minimizing further changes was considered desirable.</p></li>
<li><p>"Pubkey recovery is incompatible with batch validation."  Poelstra goes on to explain that Bitcoin doesn't currently have batch validation for ECDSA and the reasons why, but it doesn't sound to me like batch validation would be impossible to add at a later point (though perhaps it would require a soft fork); presumably devs would prefer to work on batch validation and signature aggregation using Schnorr signatures instead.</p></li>
</ol>

<p>Later, Gregory Maxwell (gmaxwell) added that "Certicom has a patent on key recovery that could potentially apply" to a possible construction, which could've made using that construction controversial.</p>

<p>FYI: your second question asked in edits should probably be asked separately as it's a completely different issue.</p>

CC BY-SA 4.0
2018-06-02T15:50:08.353Z
2018-06-02T16:36:53.837Z
2018-06-02T16:36:53.837Z
David A. Harding
<p>As we want to minimize the data payload in a blockchain, which also led to concepts like SegWit, and is matter of discussion in Signature aggregation etc, I wonder why do we actually need to supply public key in order to spend? It's needless 33B of data. ScriptPubKey could look like this <code>&lt;HASH160&gt; OP_CHECKSIG2</code> and ScriptSig <code>&lt;Signature&gt;</code>. I know this requires Softfork, but as we introduced SegWit, why wasn't this the design? Is it because mapping signature -> public key is not unambiguous?</p>

<p>Edit:<br>
As in the comments suggested: the issue with public key recovery from EC signature is simply trade-off between fast verifiability and space requirements. The public key recovery from signature <em>(r,s)</em> involves conversion of scalar <em>r = x<sub>r</sub></em> into a curve point <em>R = (x<sub>r</sub>, y<sub>r</sub>)</em>, i. e. modular square root. This raises another question:</p>

<p>What's the idea of segwit transaction verification? Do we have multiple levels of consensus rules validation? E.g. <em>basic</em> validation evaluates all transaction scripts according to <em>pre-segwit</em> rules (which is just push of 2 stack items, which is always <em>True</em>), and <em>deep</em> validation that triggers the witness validation logic. I'm not sure whether I should look at segwit as "We moved the data away from transaction that represent just some ownership proof which is relevant at the time of confirmation but not years thereafter" or maybe rather like "Witness data is inherent part of transaction, just as it has always been, and was actually meant as tx-malleability fix and Script language generalization allowing future protocol extension."?</p>

CC BY-SA 4.0
2018-05-19T12:09:55.137Z
The questioner seems to be alluding to the ability to recover public keys from ECDSA signatures, such as described in https://bitcointalk.org/index.php?topic=6430.0
David A. Harding
CC BY-SA 4.0
2018-05-20T14:29:56.630Z
Pub key recovery generally wasn't known about when bitcoin was designed, and has some small caveats like being more CPU intensive. Most of the resource usage of Bitcoin is CPU time already.
Claris
CC BY-SA 4.0
2020-09-15T23:13:53.383Z
@Anonymous not really. It could be faster if so many steps weren’t single thread.
user2284570
<segregated-witness><public-key><signature><checksig>
Why do we need public key as part of Witness in P2WPKH transactions?
jakob
# Why do we need public key as part of Witness in P2WPKH transactions?

(Asked by: username_0 on 2018-05-19)

As we want to minimize the data payload in a blockchain, which also led to concepts like SegWit, and is matter of discussion in Signature aggregation etc, I wonder why do we actually need to supply public key in order to spend? It's needless 33B of data. ScriptPubKey could look like this `<HASH160> OP_CHECKSIG2` and ScriptSig `<Signature>`. I know this requires Softfork, but as we introduced SegWit, why wasn't this the design? Is it because mapping signature -> public key is not unambiguous?

Edit:  
As in the comments suggested: the issue with public key recovery from EC signature is simply trade-off between fast verifiability and space requirements. The public key recovery from signature *(r,s)* involves conversion of scalar *r = xr* into a curve point *R = (xr, yr)*, i. e. modular square root. This raises another question:

What's the idea of segwit transaction verification? Do we have multiple levels of consensus rules validation? E.g. *basic* validation evaluates all transaction scripts according to *pre-segwit* rules (which is just push of 2 stack items, which is always *True*), and *deep* validation that triggers the witness validation logic. I'm not sure whether I should look at segwit as "We moved the data away from transaction that represent just some ownership proof which is relevant at the time of confirmation but not years thereafter" or maybe rather like "Witness data is inherent part of transaction, just as it has always been, and was actually meant as tx-malleability fix and Script language generalization allowing future protocol extension."?

**Tags:** segregated-witness, public-key, signature, checksig

> **Comments:**
> **username_1**: The questioner seems to be alluding to the ability to recover public keys from ECDSA signatures, such as described in https://bitcointalk.org/index.php?topic=6430.0  
> **username_2**: Pub key recovery generally wasn't known about when bitcoin was designed, and has some small caveats like being more CPU intensive. Most of the resource usage of Bitcoin is CPU time already.  
> **username_3**: @Anonymous not really. It could be faster if so many steps weren’t single thread.  

---

## 1 answers

### Answer by username_1 on 2018-06-02. Score: 1 | Accepted answer

This was discussed today on the [#bitcoin-wizards](https://botbot.me/freenode/bitcoin-wizards/msg/100716593/) IRC channel. The reasons offered by Andrew Poelstra (andytoshi) were:

1. "Segwit had enough scope already." That is, it was already a large change that some people considered controversial, so minimizing further changes was considered desirable.
2. "Pubkey recovery is incompatible with batch validation." Poelstra goes on to explain that Bitcoin doesn't currently have batch validation for ECDSA and the reasons why, but it doesn't sound to me like batch validation would be impossible to add at a later point (though perhaps it would require a soft fork); presumably devs would prefer to work on batch validation and signature aggregation using Schnorr signatures instead.

Later, Gregory Maxwell (gmaxwell) added that "Certicom has a patent on key recovery that could potentially apply" to a possible construction, which could've made using that construction controversial.

FYI: your second question asked in edits should probably be asked separately as it's a completely different issue.


---

