<p>ok, this looks like a multisig activity. Quickly de-analyzing. To sign the previous transaction, this script was used:</p>

<p>TX_IN[0] Script Sig (uchar[])
483045022100DCD533F206756C83757BD0738905799DD0C7F505C22C567641B1B35573A9B24B02204C3773F60752EA67809AA32EB0A07C0F16BCFE073C99E84C8C30A328FA14874C0121031C9BFFF835236F589BA409B364A9D2C392971C053CDFBBAC9CCDD9F30EABB15B </p>

<blockquote>
<pre><code>48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45:   length of R + S
02: OP_INT_0x02:      type tag indicating INTEGER
21: OP_LENGTH_0x21:   this is SIG R
    00DCD533F206756C:83757BD073890579
    9DD0C7F505C22C56:7641B1B35573A9B2
    4B
02: OP_INT_0x02:      type tag indicating INTEGER
20: OP_LENGTH_0x20:   this is SIG S
    4C3773F60752EA67:809AA32EB0A07C0F
    16BCFE073C99E84C:8C30A328FA14874C
01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
#########################################################
### procedure to strictly check DER-encoded signature ###
#########################################################
Minimum and maximum size constraints                        - ok
scriptsig always starts with 0x30                           - ok
length 138 chars is less than actual sig length (142 chars) - ok
       (hex 0x45, decimal 69, 138 chars)
length of R coordinate (66) &gt;= 0                            - ok
length of S coordinate (64) &gt;= 0                            - ok
S-Value is within scriptsig boundaries                      - ok
Make sure the R &amp; S length covers the entire signature      - ok
S-value must be smaller than N/2                            - ok
strictly check DER-encoded signature                        - ok
#########################################################
21: OP_DATA_0x21:     type tag indicating LENGTH
03: OP_INT_0x03
    1C9BFFF835236F58:9BA409B364A9D2C3
    92971C053CDFBBAC:9CCDD9F30EABB15B
</code></pre>
</blockquote>

<p>This terminates the Public Key (X9.63 COMPRESSED form), and the corresponding bitcoin address seems to be:    19r8BDjwdmMUYecGX73CAnRCwHoynaeSXi
This address starts with a "1", so no multisig address...</p>

<p>and </p>

<pre><code>TX_OUT COUNT, hex=01, decimal=1
TX_OUT[0]
 TX_OUT[0] Value: hex=404B4C0000000000, --&gt; bitcoin=0.05000000
 TX_OUT[0] PK_Script Length hex=47, dec=71
 TX_OUT[0] pk_script (uchar[])
  51210351EFB6E91A31221652105D032A2508275F374CEA63939AD72F1B1E02F477DA7821004F0331742BBC917BA2056A3B8A857EA47EC088DD10475EA311302112C9D24A7152AE
    51: OP_1, OP_TRUE
    21: OP_Data21 (= decimal 33)
        0351EFB6E91A3122:1652105D032A2508
        275F374CEA63939A:D72F1B1E02F477DA
        78
        bitcoin address:   1NdB761LmTmrJixxp93nz7pEiCx5cKPW44
    21: OP_Data21 (= decimal 33)
        004F0331742BBC91:7BA2056A3B8A857E
        A47EC088DD10475E:A311302112C9D24A
        71
    52: OP_Data52 (= decimal 82)
    AE: OP_CHECKMULTISIG
</code></pre>

<p>This is normally the redeem script Hex codes: 
    
It is supposed to be a 1 out of 2 multisig tx, and usually you would ripemd160(sha256()) this, and get a "type 3" bitcoin address. 
However: the second part after OP_DATA21 does not start with "02" or "03", instead with "004f..." - so no "real address". 
Why the blockchin.info doesn't show correctly is due to the fact, that indeed the redeemscript hash is expected. </p>

<p>Looks like a manually assembled tx, with the redeemscript hex codes, instead of it's ripemd(sha256()) hash. </p>

<p>Follow up question: as it is in the blockchain, it has been a valid tx, then where are the funds? :-) I tried to hexdump it, but doesn' make sense... burnt?</p>

CC BY-SA 3.0
2017-04-10T14:49:37.223Z
2017-04-10T14:49:37.223Z
pebwindkraft
<p>Example hash of transaction: 70c15eb4cc3890960dbe1ae0cf13eedaeaef04d8e4820398fb4e991b23528f03
BlockExplorer shows only 1st address of two. One address is sending address and second is signing address? or two addresses are signing addresses and no sending address? If is second case, how resolve sending address? </p>

CC BY-SA 3.0
2017-01-13T19:39:31.883Z
There is no such thing in Bitcoin as a 'sending address'. There is the list of "scripts which the sent coins were previously encumbered with". Some of these may or may not have identifiable addresses, but these are in no way an indication of who the sender is, and unless you're building a debug/explorer like site, not something you should ever care about.
Pieter Wuille
CC BY-SA 3.0
2017-01-13T20:31:31.863Z
It seems (I think) this problem occurs in input script, but from output script (I they are one of several standards) I can get address, for example from OP_CHECKSIG script, but how is with multisig?
AndrzejB
CC BY-SA 3.0
2017-01-13T21:51:29.133Z
Not every transaction output has a corresponding address.
Pieter Wuille
<multi-signature>
How to get sending address of MultiSig transaction?
AndrzejB
# How to get sending address of MultiSig transaction?

(Asked by: username_0 on 2017-01-13)

Example hash of transaction: 70c15eb4cc3890960dbe1ae0cf13eedaeaef04d8e4820398fb4e991b23528f03
BlockExplorer shows only 1st address of two. One address is sending address and second is signing address? or two addresses are signing addresses and no sending address? If is second case, how resolve sending address?

**Tags:** multi-signature

> **Comments:**
> **username_1**: There is no such thing in Bitcoin as a 'sending address'. There is the list of "scripts which the sent coins were previously encumbered with". Some of these may or may not have identifiable addresses, but these are in no way an indication of who the sender is, and unless you're building a debug/explorer like site, not something you should ever care about.  
> **username_0**: It seems (I think) this problem occurs in input script, but from output script (I they are one of several standards) I can get address, for example from OP_CHECKSIG script, but how is with multisig?  
> **username_1**: Not every transaction output has a corresponding address.  

---

## 1 answers

### Answer by username_2 on 2017-04-10. Score: 1

ok, this looks like a multisig activity. Quickly de-analyzing. To sign the previous transaction, this script was used:

TX\_IN[0] Script Sig (uchar[])
483045022100DCD533F206756C83757BD0738905799DD0C7F505C22C567641B1B35573A9B24B02204C3773F60752EA67809AA32EB0A07C0F16BCFE073C99E84C8C30A328FA14874C0121031C9BFFF835236F589BA409B364A9D2C392971C053CDFBBAC9CCDD9F30EABB15B

> ```
> 48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
> 30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
> 45: OP_LENGTH_0x45:   length of R + S
> 02: OP_INT_0x02:      type tag indicating INTEGER
> 21: OP_LENGTH_0x21:   this is SIG R
>     00DCD533F206756C:83757BD073890579
>     9DD0C7F505C22C56:7641B1B35573A9B2
>     4B
> 02: OP_INT_0x02:      type tag indicating INTEGER
> 20: OP_LENGTH_0x20:   this is SIG S
>     4C3773F60752EA67:809AA32EB0A07C0F
>     16BCFE073C99E84C:8C30A328FA14874C
> 01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
> #########################################################
> ### procedure to strictly check DER-encoded signature ###
> #########################################################
> Minimum and maximum size constraints                        - ok
> scriptsig always starts with 0x30                           - ok
> length 138 chars is less than actual sig length (142 chars) - ok
>        (hex 0x45, decimal 69, 138 chars)
> length of R coordinate (66) >= 0                            - ok
> length of S coordinate (64) >= 0                            - ok
> S-Value is within scriptsig boundaries                      - ok
> Make sure the R & S length covers the entire signature      - ok
> S-value must be smaller than N/2                            - ok
> strictly check DER-encoded signature                        - ok
> #########################################################
> 21: OP_DATA_0x21:     type tag indicating LENGTH
> 03: OP_INT_0x03
>     1C9BFFF835236F58:9BA409B364A9D2C3
>     92971C053CDFBBAC:9CCDD9F30EABB15B
>
> ```

This terminates the Public Key (X9.63 COMPRESSED form), and the corresponding bitcoin address seems to be: 19r8BDjwdmMUYecGX73CAnRCwHoynaeSXi
This address starts with a "1", so no multisig address...

and

```
TX_OUT COUNT, hex=01, decimal=1
TX_OUT[0]
 TX_OUT[0] Value: hex=404B4C0000000000, --> bitcoin=0.05000000
 TX_OUT[0] PK_Script Length hex=47, dec=71
 TX_OUT[0] pk_script (uchar[])
  51210351EFB6E91A31221652105D032A2508275F374CEA63939AD72F1B1E02F477DA7821004F0331742BBC917BA2056A3B8A857EA47EC088DD10475EA311302112C9D24A7152AE
    51: OP_1, OP_TRUE
    21: OP_Data21 (= decimal 33)
        0351EFB6E91A3122:1652105D032A2508
        275F374CEA63939A:D72F1B1E02F477DA
        78
        bitcoin address:   1NdB761LmTmrJixxp93nz7pEiCx5cKPW44
    21: OP_Data21 (= decimal 33)
        004F0331742BBC91:7BA2056A3B8A857E
        A47EC088DD10475E:A311302112C9D24A
        71
    52: OP_Data52 (= decimal 82)
    AE: OP_CHECKMULTISIG

```

This is normally the redeem script Hex codes:
It is supposed to be a 1 out of 2 multisig tx, and usually you would ripemd160(sha256()) this, and get a "type 3" bitcoin address.
However: the second part after OP\_DATA21 does not start with "02" or "03", instead with "004f..." - so no "real address".
Why the blockchin.info doesn't show correctly is due to the fact, that indeed the redeemscript hash is expected.

Looks like a manually assembled tx, with the redeemscript hex codes, instead of it's ripemd(sha256()) hash.

Follow up question: as it is in the blockchain, it has been a valid tx, then where are the funds? :-) I tried to hexdump it, but doesn' make sense... burnt?


---

