display received payments for unspendable multisig addresses #1928

It seems to me that the usefulness of multisig addresses are severely limited if the current client implementation doesn't support showing received payments to a multisig address unless one has all the keys imported into their wallet.

I understand why it may be considered dangerous to show received payments if they aren't spendable (the wallet doesn't have all the required keys for the multisig address) but at the same time that is exactly the point of using multisig addresses.

It seems any rpc calls dealing with transactions (listsince, listtransactions, etc) should at least have an extra option to show transactions sent to multisig addresses that have been added with addmultisigaddress (ismine: true) even if all the keys haven't been imported into the wallet.

Not all multisig additions are equal. An address you can spend with the help of the computer in your pocket isn't the same as an escrow held by a potentially hostile counterparty. We need some way of distinguishing these cases.

it seems the only current way to watch for incoming multisig transactions without having all the keys in the wallet is:

1. wait for -blocknotify
2. call getblock
3. iterate over the transactions array and call getrawtransaction
4. iterate over the outputs in getrawtransaction to see if it has an address you care about

Yes, that's essentially what the wallet code does for transactions it cares about.

Note that 3) can be done with one "batch" RPC call, so it's not as inefficient as you might think.

What is your use case where you might be getting payments on multisig addresses where you don't control all of the keys and aren't told via some way other than the blockchain the transaction ID of a new, incoming payment? The use cases I can think of all involve negotiation between the people who hold the keys, and I assume that the transaction id would be included in that negotiation (in which case you use getrawtransaction/signrawtransaction to spend).

The multi-device wallet will definitely require a new type of 'ismine' key, where it IS yours, but one of the private keys is on another device that you own (and when that is implemented I assume listtransactions/etc will show those payments).

I would like to use multisig addresses for customer deposits. I was planning on having the server that watches for incoming deposits have one key and then there would be at least one other key stored elsewhere that would be needed to process withdrawals. In this type of scenario you control all the keys, but they aren't in one place. What would be the use of multisig addresses if all the keys are in one wallet?

In my scenario you could ask a customer for a transaction id, but it does make it more complicated than just asking them to make a deposit to a bitcoin address as normally is done.

Thanks for pointing out the batch rpc calls, I didn't think of that. I think the best thing to do would be to add a new flag to addmultisigaddress that will set the new ismine flag that you are talking about to true and then listtransactions, listsince, etc will show them

Perhaps we could use a multisig issue label? There appears to be much to do in the area of a higher-level API to deal with multisig transactions.

Is there any progress on that?

My use case for this would be, that my service would manage users wallet and make transaction drafts for him, and his job would be signing them with his private key that my server doesn't know. @gavinandresen ?

While at it, it would be very nice to have a RPC command like "sendfrom" which could draft a transaction from given address to given addresses. Right now if the multisig address received several transactions, you have to handle the calculations yourself, and bitcoin client already solved that for plain addresses.

This can be done using the watch-only functionality in 0.10+: Add the multisig address with importaddress.