user323: An ECDSA algorithm when signing a given messages produces a pair of outputs, r and s. How, given a sigStr from a Tx can one extract r and s? Are they just concatenated byte arrays of a specific length, or is there more to it?

user21130: R and S are visible in each of the tx inputs.
You can see them already extracted on this site. I also provide the Z value.
https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e
See the bitcoin protocol specification for more info about the byte order.
https://en.bitcoin.it/wiki/Protocol_specification#tx
Below is an example of a TX input hex,

4830450220657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c022100ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e0141049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa

Now separated to make it easier to read,

48


3045


0220
(The Hex 20 says the next 32 bytes are the R value)


657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c


0221 (The hex 21 says the next 33 bytes are the S value)


00ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e


0141 (The hex 41 says the next 65 bytes are the public key)


049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa


user85: If you want, you can pay $100 for the standard, ANSI X9.62. Or, you can cheat and look at RFC3278, section 8.2. It is in DER format consisting of a SEQUENCE of two INTEGERs. The first INTEGER is r, the second s.
If you look at this transaction you can see that one of the signatures is:

3045 0220
316eb3cad8b66fcf1494a6e6f9542c3555addbf337f04b62bf4758483fdc881d
022100
bf46d26cef45d998a2cb5d2d0b8342d70973fa7c3c37ae72234696524b2bc812
01

If we parse that as DER, we get:
 0:d=0  hl=2 l= 69 cons: SEQUENCE          
 2:d=1  hl=2 l= 32 prim: INTEGER :316EB3CAD8B66FCF1494A6E6F9542C3555ADDBF337F04B62BF4758483FDC881D
36:d=1  hl=2 l= 33 prim: INTEGER :BF46D26CEF45D998A2CB5D2D0B8342D70973FA7C3C37AE72234696524B2BC812

You can also peek at the OpenSSL source code, file ecdsa/ecs_asn1.c:
ASN1_SEQUENCE(ECDSA_SIG) = {
        ASN1_SIMPLE(ECDSA_SIG, r, CBIGNUM),
        ASN1_SIMPLE(ECDSA_SIG, s, CBIGNUM)
} ASN1_SEQUENCE_END(ECDSA_SIG)


323: <p><a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA">An ECDSA algorithm</a> when signing a given messages produces a pair of outputs, <a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm">r and s</a>. How, given a sigStr from a Tx can one extract r and s? Are they just concatenated byte arrays of a specific length, or is there more to it?</p>
 21130: <p>R and S are visible in each of the tx inputs.
You can see them already extracted on this site. I also provide the Z value.</p>
<p><a href="https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e" rel="nofollow noreferrer">https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e</a></p>
<p>See the bitcoin protocol specification for more info about the byte order.
<a href="https://en.bitcoin.it/wiki/Protocol_specification#tx" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Protocol_specification#tx</a></p>
<p>Below is an example of a TX input hex,</p>
<blockquote>
<p>4830450220657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c022100ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e0141049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa</p>
</blockquote>
<p>Now separated to make it easier to read,</p>
<blockquote>
<p>48</p>
</blockquote>
<blockquote>
<p>3045</p>
</blockquote>
<blockquote>
<p>0220
(The Hex 20 says the next 32 bytes are the R value)</p>
</blockquote>
<blockquote>
<p>657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c</p>
</blockquote>
<blockquote>
<p>0221 (The hex 21 says the next 33 bytes are the S value)</p>
</blockquote>
<blockquote>
<p>00ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e</p>
</blockquote>
<blockquote>
<p>0141 (The hex 41 says the next 65 bytes are the public key)</p>
</blockquote>
<blockquote>
<p>049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa</p>
</blockquote>
 85: <p>If you want, you can pay $100 for the standard, <a href="http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.62:2005" rel="nofollow noreferrer">ANSI X9.62</a>. Or, you can cheat and look at <a href="https://www.rfc-editor.org/rfc/rfc3278#section-8.2" rel="nofollow noreferrer">RFC3278, section 8.2</a>. It is in DER format consisting of a SEQUENCE of two INTEGERs. The first INTEGER is <code>r</code>, the second <code>s</code>.</p>
<p>If you look at <a href="http://blockexplorer.com/rawtx/d2b04f28dfe36bbd7f6228519725f4560b6d7eef0eb9c1b1d4c718f2ba4548f5" rel="nofollow noreferrer">this transaction</a> you can see that one of the signatures is:</p>
<blockquote>
<p>3045 0220<br>
316eb3cad8b66fcf1494a6e6f9542c3555addbf337f04b62bf4758483fdc881d<br>
022100<br>
bf46d26cef45d998a2cb5d2d0b8342d70973fa7c3c37ae72234696524b2bc812<br>
01</p>
</blockquote>
<p>If we parse that as DER, we get:</p>
<pre><code> 0:d=0  hl=2 l= 69 cons: SEQUENCE          
 2:d=1  hl=2 l= 32 prim: INTEGER :316EB3CAD8B66FCF1494A6E6F9542C3555ADDBF337F04B62BF4758483FDC881D
36:d=1  hl=2 l= 33 prim: INTEGER :BF46D26CEF45D998A2CB5D2D0B8342D70973FA7C3C37AE72234696524B2BC812
</code></pre>
<p>You can also peek at the OpenSSL source code, file <code>ecdsa/ecs_asn1.c</code>:</p>
<pre><code>ASN1_SEQUENCE(ECDSA_SIG) = {
        ASN1_SIMPLE(ECDSA_SIG, r, CBIGNUM),
        ASN1_SIMPLE(ECDSA_SIG, s, CBIGNUM)
} ASN1_SEQUENCE_END(ECDSA_SIG)
</code></pre>
