How to get sending address of MultiSig transaction?

Question

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?

Answer 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?