Transaction's number of outputs changed over time for multi-sig transactions

[vertak]

I am writing a program that uses RPC to poll bitcoind for information about blocks, transactions, inputs and outputs and insert them into a database. After testing the output for the transactions within one block (specifically block #308799) I found that the number of outputs for some of the transactions in that block (according to bitcoind) were different from when I had originally inserted that transaction's data into the database. The transactions that threw these errors have the following transaction hashes

3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18
70ab887ea76c1c0fa3e4095f2696c7cb53231f9c8f16e2cbe9bd3c49a1f40dbd
3dff1e7732a45e4a0b568220cdad1aaeba1ba871bcc73767560bb6da6ff48273

if we look at the output data for the first transaction hash listed above, we found it looks like this


+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
| id        | txHash                                                           | type       | dstAddress                         | value     | offset | regSigs |
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+
| 109811502 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig  | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC |  0.000078 |      0 |       1 |
| 109811503 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig   | 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E |  0.000078 |      0 |       1 |
| 109811504 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig   | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC |  0.000078 |      1 |       1 |
| 109811505 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | multisig   |  1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E |  0.000078 |      1 |       1 |
| 109811506 | 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 | pubkeyhash | 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC | 0.0073245 |      2 |       1 |
+-----------+------------------------------------------------------------------+------------+------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+-----------+--------+---------+


Note that they only different in the outputs with the same address only differ in their offset value. However, if we compare this to the info found on blockchain.info and on bitcoind for this transaction, located at

http://blockchain.info/tx/3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18

we find that there are only three transactions. There's still one regular pubkeyhash, but 2 of the multisig outputs have disappeared. The same pattern follows for the other two transactions; the same number of regular type outputs are listed on both my database, bitcoind, and on blockchain.info, but the number of multisig outputs is less on blockchain.info and bitcoind than on my database.


Now that I've given the background on my problem, my question is:

Can someone explain to me what is going on with these multisig outputs? Since I'm using bitcoind as a data source and then putting this data into my database, it seems correct to assume that at one point bitcoind really thought there were 5 outputs for that first transaction hash. My guess that bitcoind went back at a future point in time and updated that transaction's outputs, but I have no idea why or how because I don't understand the technical aspects of a multisig transaction. Any light shed on this would be great as I'll need to make the changes to my data-mining scripts as soon as possible if there is something harmful in keeping the transactions with a greater number of multisig outputs.

[DannyHamilton]

Transaction 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 has 3 outputs.

You can see this in the "output" that you pasted.

Offset 0 is 1 output.
It has a value of 0.000078 BTC
It can be spent with 1 signature.
To spend the output, you can EITHER use the signature from the private key associated with 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC OR you can use the signature from the private key associated with 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E.

Offset 1 is 1 output.
It has a value of 0.000078 BTC
It can be spent with 1 signature.
To spend the output, you can EITHER use the signature from the private key associated with 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC OR you can use the signature from the private key associated with 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E.

Offset 2 is 1 output.
It has a value of 0.0073245 BTC.
It can be spent with 1 signature.
To spend the output, you must use the signature from the private key associated with 1GcFhAQGFZVDAr4jiR2tKwisHcgNUjhGNC.

[DeathAndTaxes]

Can someone explain to me what is going on with these multisig outputs? Since I'm using bitcoind as a data source and then putting this data into my database, it seems correct to assume that at one point bitcoind really thought there were 5 outputs for that first transaction hash.

Tx outputs don't change ... ever.  Not sure why you think the number of output has changed but txid 3a0c283c8574205c2cc95cea0e603bfff9087af2ab0360ebd2e98740a3193a18 has always had and always will have 3 output.  It would not have ever shown any more or less.   The more probably explanation is you incorrectly parsed the txn the first time.