-
Notifications
You must be signed in to change notification settings - Fork 35.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
display received payments for unspendable multisig addresses #1928
Comments
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:
|
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 |
Perhaps we could use a |
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 |
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 withaddmultisigaddress
(ismine: true) even if all the keys haven't been imported into the wallet.The text was updated successfully, but these errors were encountered: