How to get sending address of MultiSig transaction?
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) &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



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, --&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


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?