Topic: Multi-signature address never receives bitcoins - page 2. (Read 5114 times)

Keep in mind Bitcoin actually goes a bit further than that: bitcoind will only add a multi-sig transaction output to your wallet if you have all the keys, instead of only enough keys.

I ran into this with my timestamper, which would create 1-of-2 multisig outputs where the other key was actually invalid and was only there to timestamp data. The code that actually implements this is in script.cpp:


   case TX_MULTISIG:
    {
        // Only consider transactions "mine" if we own ALL the
        // keys involved. multi-signature transactions that are
        // partially owned (somebody else has a key that can spend
        // them) enable spend-out-from-under-you attacks, especially
        // in shared-wallet situations.
        vector keys(vSolutions.begin()+1, vSolutions.begin()+vSolutions.size()-1);
        return HaveKeys(keys, keystore) == keys.size();
    }


As a quick hack I changed changed the last line (IIRC) to only require that I had enough of the keys to spend the txout. You can do that too if you just want to test some multisig-using code out, just remember that you'll need to do a fair bit more than that to make it robust against attacks. FWIW my timestamper never ran into the problems mentioned above, but someone certainly could have caused it some trouble if they tried.

Remember too that this only applies to bare CHECKMULTISIG txouts; P2SH is different. For a P2SH-using txout the scriptPubKey is just a hash of the real script, so bitcoin has no idea what the actual scriptPubKey is, and hence whether or not you have the keys required to spend the txout.

However for real-world applications this is never a problem because you know the scriptPubKey - they're funds you know you have access too. I wrote a patch that adds the RPC command "addredeemscript" to bitcoind to make it possible to add a P2SH redeemscript to your wallet. It's not merged yet (and may never be) but if you are working on the right application it might be useful to you: http://github.com/petertodd/bitcoin/ (github is down right now, but the branch name is "rpc-addredeemscript" or something)

Again, remember that you may mess up your wallet experimenting with the above hacks, so don't use it on anything other than testnet for now.

Also, if you're working on some code, use P2SH rather than bare CHECKMULTISIG scriptPubKeys - it's possible the later will be made non-standard in the future to discourage people from putting data in the UTXO set.

Thanks, I feared as much from browsing the code.

No -- because it's not trivial.

But this is already the case - if I have both private keys in the wallet, then the balance is displayed by bitcoind. But I'm asking whether a trivial code change would allow me to work with partially controlled multi-sig addresses?

If, and only if, you control all keys involved in a multisig transaction.

Otherwise, such a transaction may be considered "partially controlled" and not really part of your "fully controlled" balance.  bitcoind cannot prove that you can spend a multisig.

Is it trivial for me to modify my build of bitcoind to consider multi-sig addresses in the balance calculations?

So, listsinceblock, gettransactions, listaccounts (and the rest of the commands which return transaction info) commands would consider multi-sig addresses?

Here's is an outline of how one such external tool might work:

http://praesto.airdns.org:63853/issues/5

A tiny little part of the problem goes away, sure.  But not the whole thing.

What would be needed is a general means to monitor specific scriptPubKeys.  There has been a lot of discussion on that topic over the last few months.  Check the mailing list and IRC logs to see why it isn't a simple change to make.

The thing is, if bitcoind would simply include multi-sig transactions in the balance of each account, this entire problem goes away doesn't it?

This is true, but the primary job of bitcoind is to parse the blockchain, so having to use another parser seems... wasteful.

Multisig addresses are not useful as-is.  External tools of some sort are required.

The reference implementation could be improved to be sure, but it will never be able to be the whole infrastructure for multisig.

As jgarzik notes, there are tools available already that are suitable for infrequent multisig usage.

This is a fair criticism, and no, average users cannot be expected to parse the block chain.

Average users can, however, watch a specific address on blockchain/block explorer.

I was talking about using the bitcoind client. Are you suggesting that bitcoin users should manually parse the blockchain to determine if their funds arrived?

Multisig addresses are fully visible in blocks, just like regular addresses.

You can only do that if you have the transaction ID. If someone simply sends you some bitcoins without the transaction ID, you're buggered.

You can check whether the transaction was included in a block.

Even that tool you posted still suffers from the same problem: *no one can tell that bitcoins were sent to them on a multi-sig address*.

In fact, they write:


Time passes. How much time? Are they sure the coins actually arrived?

IMO, all this could be solved simply by allowing the balance to include multi-sig addresses.

Cheers, Paul.

The tools for multisig are admittedly poor, at the moment.

Multi-sig introduces an interesting concept:  bitcoins that you might be able to spend.  Therefore, your balance only shows bitcoins when you control 100% of the private keys.

Right now, you need to take a few extra steps.  Some tools outside bitcoind exist to help with multisig, but in general, additional work is needed in this area.

Well, without being able to see the balance of an multi-sig account you completely rule out several use cases which could help secure bitcoins for merchants who are in charge of bitcoins on behalf of other users. No one can send bitcoins for you to secure if you can't tell when they've arrived.

To me it would make perfect sense to have a visible balance on a multi-sig address and not be able to spend it (without being multi-signed). That's the whole point of them in the first place.


But how do you even know when they've arrived at an address in order to spend them?

Cheers, Paul.

Correct. It doesn't make sense to show as part of your balance coins which you have no idea if you can spend them or not.

They can still be spent, manually.

The idea is that for now you use them manually. In the future yet undeveloped functionality would replace the private key for the other siginers in your wallet with some instructions that tells the client how it can go about getting the required signature(s).

Such signers have to exist, first, before you can worry about figuring out how to interface them... thus the start with manual use.