Bitcoin Forum

I want to generate my own mutli-sig addresses using my public keys. How can I do this?  Just walk me thru what it takes to generate a mutli-sig address from public keys and n require value.

Honestly I just need to know how to insert the n required value into the address? I can generate them using the version bytes 0X05.

Here's a tutorial. https://bitcointalk.org/index.php?topic=270204.msg2892129#msg2892129

The bitcoin scripts are pretty simple, but making sure you're doing the right thing can be challenging -- for instance, you can create multi-sig script for receiving the money, but most tools don't display and validate the script properly.  You'll have to make sure you do that part correctly, too.  Luckily, if you do it wrong, the network likely won't propagate it (just don't mine it yourself!).

If you want to use P2SH, you would hash the output script and construct the address string using 0x05 instead of 0x00 as you would for a normal address.  But this is irrelevant if you're manually creating transactions, since the network never sees that prefix byte -- it's only an identifier for the address strings that are passed around between humans, but are not included in the actual scripts inserted into the blockchain.  

But if you're doing a lot of one-off multi-sig transactions, and not necessarily interacting with others (for now, maybe you just want to protect your own money with this tool you're creating), then I would recommend using vanilla multi-sig without P2SH.  This will make it easier to find your money if you later need to search the blockchain for multi-sig addresses that are relevant to your wallets (P2SH will hide those details).  A full-featured multi-sig solution (like Armory will hopefully do soon) will use multiple wallets with meta-data and a structured key selection that makes P2SH safe in this respect.  Until then, you can use plain multisig scripts which are standard up to 3-of-3.

Finally, I recommend you do all your testing on testnet.  Everything is identical, except if you do use P2SH, use the following prefix bytes for generating address strings:

   Regular Addresses = '\x6f'
   P2SH Addresses = '\xc4'

---

Onto the fun part -- this can all be done with armoryengine.  And the latest version of armoryengine also recognizes and displays P2SH addresses (on the "testing" branch), though it doesn't quite know what to do with multisig scripts.  Nonetheless, you can manually put together the pieces using https://bitcoinarmory.com/developers/python-scripting/ as a guide.

If I was going to do it, I would use regular multisig: I would probably use Armory GUI to create a transaction sending X coins to a regular address, but don't send it yet, create an unsigned transaction.  Then go hex-diving into that transaction and replace the TxOut script (and var_int preceeding it) with the multisig script.  In fact, you can create the script with my untested function pubkeylist_to_multisig_script(pubKeyList, Mreq) (https://github.com/etotheipi/BitcoinArmory/blob/torrentdl/armoryengine/ArmoryUtils.py#L1320).  Though, it's a very simple script:


If you're doing 2-of-3, get the three public keys, and put the binary forms of them into a list, something like:

Now remove the var_int and script from the recipient txout (don't mess with the change output!), and put this varInt and script in there.  Unless I missed something, this should be a valid transaction.  You should be able to sign and broadcast it (you might even be able to do it with Armory as if it was an offline transaction, though it also might choke on the form of the receipient "address" -- let me know!).  

Spending it, is more challenging with the available tools, but it can be done.  The gist of it is that you will create the spending transaction, using as an input the unspent multi-sig (or P2SH) TxOut.  You will create the TxIn script using the standard form


You will need the code here (https://github.com/etotheipi/BitcoinArmory/blob/torrentdl/armoryengine/Transaction.py#L1485) to produce the hash that needs to be signed for OP_CHECKSIG/OP_CHECKMULTSIG.  You will sign that hash with each of 2 of the 3 private keys, and put an empty string (OP_0?) in the other location (they need to be in same order as the keys in the TxOut script).  That should be a valid spend script.

Of course, I probably missed all sorts of small details, but it's late, so I'll have to defer discussion of those details until later.  Hopefully that's at least enough to get you started.

Order matters.

Run out all 6 permutations to see if one matches.  (I always sort mine.)

redeemScript is pretty much straight forward:

* push the number of signatures required to spend (that's normally one byte opcode: value = 0x50 + the number)

* push a public key -  and do it N times, once for each key

* push N (normally one byte: 0x50 + N)

* append opcode 0xae (whatever it does - at this stage nobody cares)

to make an address out of such a script, just hash the entire redeemScript with rimpd160(sha256(script)) - this will give you 20 bytes.
to create the actual text address use a regular bitcoin's 20-bytes to base58 address "translation", with the 4 checksum bytes.
the version byte is different -I believe it's 5 for the real net (unlike 0 for regular addresses)

now, this part (generating a multisig address) - this is very simple.
but when you get to spending coins from it - then a real fun starts :)
whoever invented this system must had been a masochist ;)

It's an opcode from the script - means "push the next 0x21 bytes to the stack, as a new top element".
https://en.bitcoin.it/wiki/Script#Constants
If you had uncompressed public key (e.g. from some old wallet) - this would have been 0x41

I'm afraid it will still ask you for values which need for providing you will find quite ridiculous, concerning that this was supposed to be a function of a wallet... like: the private key :)

That actually might be the only wallet ever created, which needs to be provided with a private key from outside in order to sign a transaction - making it an extremely clever idea :)

Smallest to largest.

The point is that ABC gives a different redeemscript (and thus a different hash) than ACB, or any of the other 4 permutations.  I think I suggested that the RPC command to create a multisig p2sh address should sort the keys (with an optional flag to not sort them), but I don't know if it was ever done or not.

But if you are testing your code against the address created by bitcoind, you need to match whatever ordering bitcoind is using, or you may get a different (but possibly totally valid and usable) address.


There are a bunch of opcodes that mean "push a new stack object made of this literal number of bytes which immediately follow".

In this case, the stack object is an encoded public key.  Public keys are encoded as follows:

0x02 (1 byte) - {pubkey.x} (32 bytes) (y value is implied and has even parity)
0x03 (1 byte) - {pubkey.x} (32 bytes) (y value is implied and has odd parity)
0x04 (1 byte) - {pubkey.x} (32 bytes) - {pubkey.y} (32 bytes) *

1 byte + 32 bytes = 33 bytes, which is 0x21 in hex, and the opcode map was created in a way that 0x21 is the opcode that means push 0x21 bytes.

If you are always using compressed pubkeys, you can probably get away with just using the literal 0x21 here, but for a more extensible script, you should probably write a generic cscript_pushobject function that is robust.

* Please don't ever use this one.

anyway, if you ever get to actually spending coins from multisig addresses, here is what you'd like to know.

* while using "signrawtransaction" API, don't worry about the txid+vout param - the function requires you to specify it, but put there whatever you want and it will still work
* unfortunately (at least for multisig) this function requires you to specify the actual signing private key (that also needs to be in your wallet, BTW). at least I didn't manage to use it without giving it a private key, along with the request.

and abstracting from the bitcoin-qt:
* in the actual signed transaction, at the beginning of each sigscript there must be OP_FALSE opcode, which is supposedly a workaround for some bug
* the order of the actual signatures must match (follow) the order of the public keys from the p2sh script. if you change their order, it won't verify.

besides these few details it actually seems to work quite nice.

Take care when generating the redeemscript to use the right varint in case you're given an uncompressed key.


Edit: Added recursive function to decode the redeemscript.

So is it true the uncompressed keys must be used? I'm also trying to reproduce what bitcoind's multisig implementation does, and am getting a different output address using compressed keys.

As others said, check the order of your keys. It matters - different order will output a different address.

I'm doing a simple 2-of-2, tried both permutations. 

To make sure I didn't understand the previous 50 tutorials I've read, here's the hex bytes I'm hashing:

ripemd-160(sha256("2<pubk1><pubk2>2<OP_CHECKMULTSIG>"))

I'm pretty sure this is the step that's goofing it up, everything else is similar to standard addresses.

Make a couple of bogus privkeys, use bitcoind to generate the 2-of-2 address, and use your script to generate it.  Post the keys, the redeemscripts (both of them) and the two resulting p2sh addresses.

Pubkey1:
0287f9169e265380a87cfd717ec543683f572db8b5a6d06231ff59c43429063ae4
Pubkey2:
0343947d178f20b8267488e488442650c27e1e9956c824077f646d6ce13a285d84

Bitcoind's answer:
"address" : "36m2bHwsUnkpGsZgVAEmeJRf2CeViDm6RV",
"redeemScript" : "52210287f9169e265380a87cfd717ec543683f572db8b5a6d06231ff59c43429063ae4210343947 d178f20b8267488e488442650c27e1e9956c824077f646d6ce13a285d8452ae"

My computation:
"address" : "35vpjKamX1LnkgjZ2aauj1XQWPRCkqRjsE",
"redeemScript"   "52210287f9169e265380a87cfd717ec543683f572db8b5a6d06231ff59c43429063ae4210343947 d178f20b8267488e488442650c27e1e9956c824077f646d6ce13a285d8452ae"

Nevermind I got it. I didn't understand that "2" actually means "0x52" in opcodes, etc. Piotr much love to you for your explanation.