Multi-signature transactions

[SomeWhere]

Hello.

I'm currently working on a piece of software that needs 2-of-2 signing of Bitcoin transactions.

It's really hard, though, to find information about the workings of multi-signing. I would be grateful for any kind of pointer on:

• which Bitcoin clients provide multi-signature support
• how those clients implement multi-signature support
• which files of these clients contain the relevant code
• how an advanced user can use the multi-signature support
• how an end-user can use the multi-signature support

Ideally, I would like to find a daemon-like Bitcoin client to do the work of creating multi-signature addresses, signing the transactions and broadcasting the transactions for me. I would however also consider implementing multi-signature support into one of the existing Bitcoin clients if their code base as far as signing transactions are concerned is very clean & isolated from the other program logic and I find the necessary information about the exact workings of creating and using multi-signature transactions.

[kjj]

The reference client has supported multisig for a while now.

Search for the rawtransaction API for more information.  See this thread and especially, Gavin's gist.

Here is some PHP that takes an array of keys ($keys) and a number of keys required to spend ($nReq) and creates a P2SH multisig address and redeemScript.  This isn't necessary, since the API can do the same task.  This is just for those times when you want totally offline generation.  Note that the hashing steps after $rs is completed are exactly the same as the hashing done to normal addresses, just with a different magic number.  Also, the sorting step is not necessary, I just do it to make it easier to recover in case the metadata is lost and I'm left with just a bunch of keys.

Code:

<?php

function createmultisig($nReq,$keys,$sortkeys=TRUE){
 if($sortkeys)sort($keys,SORT_STRING);
 if($nReq<2 OR $nReq>16 OR $nReq>count($keys))return FALSE;
 $rs=chr(0x50+$nReq);
 while(list($key,$val)=each($keys)){
  $bpk=hex2bin($val);
  $rs.=chr(strlen($bpk)).$bpk;
 }
 $rs.=chr(0x50+count($keys));
 $rs.=chr(0xae);

 $h=hash("sha256",$rs,TRUE);
 $h2=hash("ripemd160",$h,TRUE);
 $h3="\x05".$h2;
 $h4=hash("sha256",$h3,TRUE);
 $h5=hash("sha256",$h4,TRUE);
 $chk=substr($h5,0,4);
 $addr_bin=$h3.$chk;
 $addr=encodeBase58($addr_bin);
 return array("redeemScript"=>bin2hex($rs),"address"=>$addr);
}
?>

[aminorex]

any idea why the appalling lack of gui support?  this is costing the btc user community thousands every day.

[Mike Hearn]

Multi-signature transactions are not a feature in and of themselves. They're a tool you use to implement features. So asking why end user wallets don't have GUIs for them is the wrong approach. You should be asking, why don't wallets support "two party escrow with coin burning" or whatever you're actually interested in. And the reason would be, it's quite complicated to do well.

Which specific feature do you want? If you spec it out from the users perspective, we can discuss it and it'll become clearer what work needs to be done.

[monsterer]

The reference client has supported multisig for a while now.

'supported' is a bit generous IMO. There is the bare bones tools to create a multi-sig transaction but everything else which would make them usable is sadly lacking.

[kjj]

The reference client has supported multisig for a while now.

'supported' is a bit generous IMO. There is the bare bones tools to create a multi-sig transaction but everything else which would make them usable is sadly lacking.

No, 'supported' is exactly the right word.  The reference client "supports" multisig operations.  The "everything else which would make them usable" is a whole security infrastructure, typically involving a second computer, policies and practices, etc.  This is, naturally, outside of the scope of the client.  At risk of belaboring the metaphor, you can build such an infrastructure on top of bitcoind, because bitcoind 'supports' multisig.

[monsterer]

The reference client has supported multisig for a while now.

'supported' is a bit generous IMO. There is the bare bones tools to create a multi-sig transaction but everything else which would make them usable is sadly lacking.

No, 'supported' is exactly the right word.  The reference client "supports" multisig operations.  The "everything else which would make them usable" is a whole security infrastructure, typically involving a second computer, policies and practices, etc.  This is, naturally, outside of the scope of the client.  At risk of belaboring the metaphor, you can build such an infrastructure on top of bitcoind, because bitcoind 'supports' multisig.

Ignoring any of what you consider to be 'everything else', there is one fundamental thing which is directly related to the normal function of bitcoind which is missing from the current implementation of multi-sig transactions:

* Any way to tell someone has sent you a multi-sig transaction

Without this, you can't build any infrastructure on-top of the current implementation.

Cheers, Paul.

[Gavin Andresen]

* Any way to tell someone has sent you a multi-sig transaction

"Patches welcome."

A watch-only wallet that has a bunch of public keys (and multisig groups of public keys) is a good idea. But first you'd need multi-wallet support.

There is a pull request that adds watch-only addresses, but I think that is the wrong way to go. Mixing up fund that can be spent with funds that cannot be spent (e.g. because they're a multisig escrow you want to watch) is a bad idea, and as soon as we have hierarchical deterministic wallets we'll want watch-only wallets that are derived from a master key (or a set of master keys in the case of multisig) where the local bitcoind doesn't have the private seed for the key.