Information in this post has been taken from Blockchain Intelligence Group’s internal white paper.

 

Summary

  • Public block explorers do not correctly parse and display all transaction data.
  • Some multisig scripts are not decoded properly even by the most used public block explorer.
  • Blockchain Intelligence Group (B.I.G.) takes data integrity seriously, we routinely  make sure that even edge-cases are taken care of.
  • B.I.G. parses and displays data that our industry peers deem unparsable.

 

During the course of my work at Blockchain Intelligence Group I routinely run different analyses on the Bitcoin blockchain. In order to minimize errors i frequently compare our data versus that of public blockchain explorers. At one point I was looking into multi-signature transactions, and I discovered something interesting.

Multisig addresses

For those who are not familiar with multisig transactions, I will first present a quick multisig summary here. A multisig transaction is one in which the funds are sent to a special multisig address (also called P2SH – Pay to Script Hash). The difference between a simple and a multisig address is the number of signatures it takes to redeem an output. With simple addresses (P2PKH – Pay To PubKey Hash), the signature required to redeem an output previously sent to that address is the one of the address itself.

Multisig addresses can have a number of signatories required to redeem an output. When creating a multisig address we can specify the number of signatures required (we can look this up in our bitcoin wallet by typing help addmultisigaddress into the console of the debug window). We also specify all the addresses that can sign for outputs sent to this newly created multisig address. So we have n signatures required and m number of addresses eligible to sign, that’s why often you see the “ n out of m” phrase associated with multisignature addresses.

To see a concrete example:
I have created a vanity address for testnet:
mszmickWFyopFyiKsMEnKeC1SE9kT7zGUr

bitcoin­cli validateaddress mszmickWFyopFyiKsMEnKeC1SE9kT7zGUr
{
"isvalid": true,
"address": "mszmickWFyopFyiKsMEnKeC1SE9kT7zGUr",
"scriptPubKey": "76a91488e453d86039f7dbf1eb3b2a49accea7f18ddc3088ac",
"ismine": true,
"iswatchonly": false,
"isscript": false,
"pubkey":
"0471929763b040a40ac47c5cf932d922086a675c82f1f3b9e9cd50b9bc8034efe627f55702340e365a56dc457a563b3c31baaad7c8565b4a431ad7b26a28e19580",
"iscompressed": false,
"account": ""
}

 

In order to create a multisig address we need the pubkey of the signatories. Here i will create a two out of two multisig address, i will specify that in the addmultisigaddress command

bitcoin­cli addmultisigaddress 2
'["0471929763b040a40ac47c5cf932d922086a675c82f1f3b9e9cd50b9bc8034efe627f55702340e365a56dc457a563b3c31baaad7c8565b4a431ad7b26a28e19580","04242bcb346507f16750e04a42b0f4a95d68fc5126c2b901ba5d477c7f04a094b5dfaaccdc205dd5a1cd5e0ab586b6e8febcd6238065bfefd1fafa3495b20d42e2"]'
2MyqK2oRHw8kpYSqTtuKsuqNg1ba6fH2mUQ

That is a multisig address on the testnet, on the mainnet multisig addresses start with a “3”.

Now i can give that multisig address to anyone and funds can be sent to it, but in order to spend any money out of that address, two signatures will be required. We can view this as a savings account of a married couple, where both spouses need to sign to withdraw any money.

Back to the issue at hand: the discovery

So visually, this is what a multisig transaction looks like:

When presenting this to our clients we show the receiving multisig address, and the eligible signatories, as well as number of signatures required:

It has come to our attention that (most) public block explorers simply specify the signatories and the number of signatures required. They do not show or keep track of the multisig address itself.

Let’s look at a particular transaction, the hash is : bea1e7ae7ecdc502215717f30d62a12085bb2866d8db730dfb626b60c337534c

Bitcoin core (v0.13.0.0) decodes this transaction as follows:

{
    "txid": "bea1e7ae7ecdc502215717f30d62a12085bb2866d8db730dfb626b60c337534c",
    "hash": "bea1e7ae7ecdc502215717f30d62a12085bb2866d8db730dfb626b60c337534c",
    "size": 452,
    "vsize": 452,
    "version": 1,
    "locktime": 0,
    "vin": [
    {
        "txid": "d70d50cd4b13416cccef9140fb0c361faa55e2d9227c987b899bea68ec5e4d3e",
        "vout": 3,
            "scriptSig": {
            "asm": "3045022100887794dd3df3fd862f163cfbd6a975c01ce765d801098cbc2d64408d5428de49022010a121ec0e4dab397c8730fc55bf9aaa60a6886e5b168f8cdef33d1897f885b2[ALL] 04398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2",
            "hex": "483045022100887794dd3df3fd862f163cfbd6a975c01ce765d801098cbc2d64408d5428de49022010a121ec0e4dab397c8730fc55bf9aaa60a6886e5b168f8cdef33d1897f885b2014104398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2"
            },
        "sequence": 4294967295
    }
    ],
    "vout": [
        {
            "value": 0.00005757,
            "n": 0,
            "scriptPubKey": {
                "asm": "1 04398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2 0250504b2d4245544120506565722d506565722d6e6574776f726b206265746121 02553432353135362e313232342020202020202020202020202020202020202020 3 OP_CHECKMULTISIG",
                "hex": "514104398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2210250504b2d4245544120506565722d506565722d6e6574776f726b2062657461212102553432353135362e31323234202020202020202020202020202020202020202053ae",
                "reqSigs": 1,
                "type": "multisig",
                "addresses": [
                    "1TestLVFK8DsRYFQkDDwvfsPHqUqWPBe7",
                    "1H16KgZg3wHgApvHvZkSocxN6ibzNT9Cc7",
                    "1N31mRc4tiGumXdRmb1Bzk9BoG4Bc7Ctbi"
                ]
            }
        },
    {
        "value": 0.00000000,
        "n": 1,
        "scriptPubKey": {
            "asm": "OP_RETURN 5400447b22636d64223a224249222c227469746c65223a22303831392d6e6577222c22656d61696c223a2264736473406464222c22766572223a312c2261757468223a2230227d",
            "hex": "6a475400447b22636d64223a224249222c227469746c65223a22303831392d6e6577222c22656d61696c223a2264736473406464222c22766572223a312c2261757468223a2230227d",
            "type": "nulldata"
        }
    },
    {
        "value": 0.00710616,
        "n": 2,
        "scriptPubKey": {
            "asm": "OP_DUP OP_HASH160 050a6ef3e0c54c20c304f604bf97c412e662832f OP_EQUALVERIFY OP_CHECKSIG",
            "hex": "76a914050a6ef3e0c54c20c304f604bf97c412e662832f88ac",
            "reqSigs": 1,
            "type": "pubkeyhash",
            "addresses": [
                "1TestLVFK8DsRYFQkDDwvfsPHqUqWPBe7"
            ]
        }
    }
    ]
}

We see that the n=0 output is a multisig output.

Decoding the script we get:

decodescript 514104398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2210250504b2d4245544120506565722d506565722d6e6574776f726b2062657461212102553432353135362e31323234202020202020202020202020202020202020202053ae
{
 "asm": "1 04398184a2cef0d7b73ed7a3a1d4ad16296c3c6986bed0bd72775060aae9891979eaea1efb28d7eb1da3304ec38a98b42086e3be2ceba82b0e932128ec422a6fc2 0250504b2d4245544120506565722d506565722d6e6574776f726b206265746121 02553432353135362e313232342020202020202020202020202020202020202020 3
 OP_CHECKMULTISIG",
 "reqSigs": 1,
 "type": "multisig",
 "addresses": [
     "1TestLVFK8DsRYFQkDDwvfsPHqUqWPBe7",
     "1H16KgZg3wHgApvHvZkSocxN6ibzNT9Cc7",
     "1N31mRc4tiGumXdRmb1Bzk9BoG4Bc7Ctbi"
 ],
 "p2sh": "3KQYMMqMBTv8254UqwmaLzW5NDT879KzK8"
}

 

We have the three signatories, we have the required number of signatures and, we also have the p2sh address. That is what a block explorer should display.
Here’s what actually gets displayed by our industry peers:

Blockchain.info displays “unable to decode output address (screen-shot taken Jan 31 2017)

Blockexplorer.com displays “unparsed address” (screen-shot taken Jan 31 2017)

BTC.com displays “unable to decode output address” (screen-shot taken Jan 31 2017)

smartbit.com.au shows the three signatories, but not the multisig address (screen-shot taken Jan 31 2017)

Blockr.io displays the three signatories and it identifies the output as multisig, but the multisig address is not displayed  (screen-shot taken Jan 31 2017)

This is how Blockchain Intelligence Group displays the transaction. We show the multisig adress, then we show all the signatories, and finally we identify the number of signatures required.

Checking the address balance and transaction history

Not decoding a multisig address properly is a big deal because if you do not identify the  address, then you can not see what transactions it has been involved in and that’s not a good thing for a multitude of reasons. Checking our example address on different block explorers yields the following results.

Blocktrail.com has no record of transactions for the address (Screen-shot taken Jan 12 2017)

 

 


smartbit.com.au has no record of transactions for the address (Screen-shot taken Jan 12 2017)


blockr.io has no record of transactions for the address (Screen-shot taken Jan 12 2017)


blockexplorer.com has no record of transactions for the address (Screen-shot taken Jan 12 2017)


blockchain.info has no record of transactions for the address (Screen-shot taken Jan 12 2017)

Blockchain Intelligence Group

This is what blockchain Intelligence Group displays:

As we can see we display both transactions involving the address in question.

Conclusion

The transaction presented here may be a special case, but there are more of them out there. In our view if the reference client Bitcoin Core can parse the script, a public block explorer should be able to do it as well. Blockchain Intelligence Group takes every possible effort to have complete and accurate blockchain data. Some of our clients are law enforcement agencies and we would not want to provide data that is incomplete or inaccurate to them or any of our clients.
We presented a transaction in this post that is not properly parsed by our industry peers. Our software handles the transaction correctly. We are publishing our findings in the hope that our peers extend the effort to alleviate the issue and together as an industry as a whole we can better.