<ol>
<li>In any transaction you'll have the signature inside scriptsig using a push OP to indicate its length and in a SegWit tx you'll have it as a witness item with a CompactInt to indicate its length. After <em>extracting</em> the signature it is only a matter of decoding DER.</li>
<li>To get the full <code>(x,y)</code> coordinates you have to use the elliptic curve equation (<code>y^2 = x^3 + ax + b</code>) to compute <code>y</code> by only having <code>x</code>. <a href="https://bitcoin.stackexchange.com/q/32634/87716">ECDSA x,y coordinate validity verification doesn&#39;t seem to work</a></li>
<li>To sign a transaction, a <em>modified</em> serialization is always used as the data to be hashed and then signed not the original transaction (in other words the resulting hash will be different from txid). This is true for all standard scripts such as P2PK, P2PKH, P2SH, P2WPKH, P2WSH,... The only difference is the modification and serialization. In legacy ones (the first 3) the procedure is described in <a href="https://en.bitcoin.it/wiki/OP_CHECKSIG" rel="nofollow noreferrer">OP_CheckSig on bitcoin wiki</a> and the SegWit ones are defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">BIP-143</a>.</li>
</ol>

CC BY-SA 4.0
2020-02-19T17:51:41.980Z
Using this equation is just simple math like y = sqrt(xˆ3+0+7)?
Allan Romanato
CC BY-SA 4.0
2020-02-19T17:53:59.680Z
Not exactly. `sqrt` is [modular square root](https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm) not a normal square root. A fast way to compute it for bitcoin curve is to find the result of `ModPow(a, (p+1)/4, p)`
Coding Enthusiast
CC BY-SA 4.0
2020-02-19T17:57:51.723Z
So it is a normal square root that I have to use right?
Allan Romanato
CC BY-SA 4.0
2020-02-19T17:59:10.780Z
What is the meaning of this equation `ModPow(a, (p+1)/4, p)`
Allan Romanato
CC BY-SA 4.0
2020-02-19T18:03:41.443Z
It means find the result of `(a ^ ((p+1)/4)) % p` where `a` is the result of the right side of the equation (y_squared) or `xˆ3+7`. Usually `BigInteger` classes in different languages have `ModPow` methods, in .Net it is `BigInteger.ModPow`, in python it is `pow(val, val, val)` that takes 3 values.
Coding Enthusiast
CC BY-SA 4.0
2020-02-19T17:49:42.270Z
2020-02-19T18:07:47.910Z
2020-02-19T18:07:47.910Z
Coding Enthusiast
<ol>
<li><p>Yes</p></li>
<li><p>Most of crypto-libraries have the <code>verify</code> method. You can pass the compressed public key as an input. BTW, it is possible to recover <code>Y</code> part from compressed public key</p></li>
<li><p>No. For multisig P2SH (and any other type) we (a)calculate the <code>digest</code>, (b)sign this digest with private keys and (c)create the final transaction from all parts. We do not need to use any signatures on step (b) as a source for calculations</p></li>
</ol>

<blockquote>
  <p>Any other thing that I should look when signing a transaction?</p>
</blockquote>

<p><a href="https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx">How to redeem a basic Tx?</a></p>

CC BY-SA 4.0
2020-02-19T17:48:05.367Z
On 2. I am not using any libraries, how can I recover the Y part using just the compressed key?
On 3, what would be this digest?
Allan Romanato
CC BY-SA 4.0
2020-02-19T17:45:20.990Z
2020-02-19T17:45:20.990Z
amaclin
<p>As I could understand, we can recover the R and the S values from any transaction following the ScriptSig where we have DER serialization.</p>

<ol>
<li>Segwit transactions, where the signature will be in the witness section, recovering R and S follow the same steps?</li>
<li>If I use the compressed public key (starting with 0x02 or 0x03) how can I verify the signature, since I don't have the Y coordinate of the public key?</li>
<li>For multi-sig transactions using P2SH as I understand we need to sign with the first key, then get the output transaction with the first signature and sign it with the other key, but using the signature math we use the hash of the message which is the txId, but on segwit the txid will not change after signing since the witness is not counting as part of the hash for txid?</li>
</ol>

<p>Any other thing that I should look when signing a transaction?</p>

<bitcoin-core><wallet><multi-signature><signature>
Segwit Bitcoin Transaction Signing
Allan Romanato
# Segwit Bitcoin Transaction Signing

(Asked by: username_0 on 2020-02-19)

As I could understand, we can recover the R and the S values from any transaction following the ScriptSig where we have DER serialization.

1. Segwit transactions, where the signature will be in the witness section, recovering R and S follow the same steps?
2. If I use the compressed public key (starting with 0x02 or 0x03) how can I verify the signature, since I don't have the Y coordinate of the public key?
3. For multi-sig transactions using P2SH as I understand we need to sign with the first key, then get the output transaction with the first signature and sign it with the other key, but using the signature math we use the hash of the message which is the txId, but on segwit the txid will not change after signing since the witness is not counting as part of the hash for txid?

Any other thing that I should look when signing a transaction?

**Tags:** bitcoin-core, wallet, multi-signature, signature


---

## 2 answers

### Answer by username_1 on 2020-02-19. Score: 1 | Accepted answer

1. In any transaction you'll have the signature inside scriptsig using a push OP to indicate its length and in a SegWit tx you'll have it as a witness item with a CompactInt to indicate its length. After *extracting* the signature it is only a matter of decoding DER.
2. To get the full `(x,y)` coordinates you have to use the elliptic curve equation (`y^2 = x^3 + ax + b`) to compute `y` by only having `x`. [ECDSA x,y coordinate validity verification doesn't seem to work](https://bitcoin.stackexchange.com/q/32634/87716)
3. To sign a transaction, a *modified* serialization is always used as the data to be hashed and then signed not the original transaction (in other words the resulting hash will be different from txid). This is true for all standard scripts such as P2PK, P2PKH, P2SH, P2WPKH, P2WSH,... The only difference is the modification and serialization. In legacy ones (the first 3) the procedure is described in [OP\_CheckSig on bitcoin wiki](https://en.bitcoin.it/wiki/OP_CHECKSIG) and the SegWit ones are defined in [BIP-143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki).

> **Comments:**
> **username_0**: Using this equation is just simple math like y = sqrt(xˆ3+0+7)?  
> **username_1**: Not exactly. `sqrt` is [modular square root](https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm) not a normal square root. A fast way to compute it for bitcoin curve is to find the result of `ModPow(a, (p+1)/4, p)`  
> **username_0**: So it is a normal square root that I have to use right?  
> **username_0**: What is the meaning of this equation `ModPow(a, (p+1)/4, p)`  
> **username_1**: It means find the result of `(a ^ ((p+1)/4)) % p` where `a` is the result of the right side of the equation (y_squared) or `xˆ3+7`. Usually `BigInteger` classes in different languages have `ModPow` methods, in .Net it is `BigInteger.ModPow`, in python it is `pow(val, val, val)` that takes 3 values.  

---

### Answer by username_2 on 2020-02-19. Score: 1

1. Yes
2. Most of crypto-libraries have the `verify` method. You can pass the compressed public key as an input. BTW, it is possible to recover `Y` part from compressed public key
3. No. For multisig P2SH (and any other type) we (a)calculate the `digest`, (b)sign this digest with private keys and (c)create the final transaction from all parts. We do not need to use any signatures on step (b) as a source for calculations

> Any other thing that I should look when signing a transaction?

[How to redeem a basic Tx?](https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx)

> **Comments:**
> **username_0**: On 2. I am not using any libraries, how can I recover the Y part using just the compressed key? On 3, what would be this digest?  

---

