Topic: MultiSig Handling + Script Parsing (Read 1529 times)

Basically you need 2 out of 3 private keys to spend the coins (instead of having just 1 private key).
There's many useful applications such as family use (what if I die,see above ), business use (not trusting just one CEO to solely control all the money) and other uses.

But how is this working? I am really confused!  Can you explain a little more about how this works?
Msig way is better as it more safer, right?
Kindly,
       Muhammed Zakhir

1) Standard way:
I ask you: please, give me some btc to address 1Kekf9GdQWUqEkBL7RuRwLZLkNiESEEoHD
You send some btc there
I can not share my private key with my wife and son - one of them will lost it or steal money
I die
The btc lost forever

2) Msig way
I create msig 2-of-3 address { mypub, wifepub, sonpub }
I ask you: please, send me some btc to address 3xxxxxxyyyyyyyyyzzzzzzaaaaabbbbccc
You send some btc there
Any two of my family can use these funds. My wife and my son are safe in case of my death.
If I lose my private key - funds are also safe - my wife and son are able to sweep them to another address

The way we tend to talk about this is quite confusing: Nowadays when we talk about multisig, we normally mean "multisig with P2SH". "Plain" multisig was possible before P2SH was implemented, but for the reasons DeathAndTaxes gives it wasn't used very much.


TBF there's been quite a lot happening recently, but it often involves some user interface challenges as well as a decent amount of Bitcoin scripting ability. I think we'll see it grow quite fast, because when somebody does crack the usability problems, not only can people copy their solution, the spread of their implementation also helps educate the users, which helps the next person to come along and implement it. In some ways two-factor authentication is a similar problem; It helps with a lot of serious long-standing web security problems, but it's only now really breaking into the mainstream. If you're the first person to implement it for a particular group of users you have to not only solve the UI problems, you also have to educate the users about it. Once you've done that, you make things far easier for the next guy.

iiiinnteresting....

the way P2SH makes multisig work is how
I always thought it did work...

sounds like this is the sensible way
to do it then as I barely understand
the explanation of the old way.

So, is this the reason why there
hasn't been a lot of multisig implementation
so far?

There is no address.  The output isn't an address the output is a script.  It is the method "b" I showed above.  For example THIS IS an old fashion multisig script

please send me some funds.  I would imagine 99% of users couldn't figure it out if they wanted to.


Here is an example on the blockchain: https://blockchain.info/tx/14237b92d26850730ffab1bfb138121e487ddde444734ef195eb7928102bc939

The first output is a multisig script output.

What would be the difference between that and me setting up a MultiSig Address the old-fashioned way and then giving you that address to send to?

Simple version is that it allows you to encumber an output with the hash of a script.   This means the sender just has the ability to just "send to an address"  and the receiver can have the script associated with that address be anything.

As an example:
Lets say I wanted you to pay me by sending funds to me that would be secured by a 2-of-3 multisig sig script.  Sounds complicated huh? 

All you do is send funds to this address 31vqFj21siCMUso7KcmRVGMvFyaVbXZXhP.  It is that easy.  You don't need to do anything different other than "pay an address".

Behind the scenes when your client decodes this address it will find that it contains a scriptHash (029ceacd493bac104217f4da1a0b8c13a18110e4) and create an output which has the following PkScript:

OP_HASH160 029ceacd493bac104217f4da1a0b8c13a18110e4 OP_EQUAL

This says restrict the redemption of this output to a script which hashes to 029ceacd493bac104217f4da1a0b8c13a18110e4.  You don't need to worry about if the script is Standard, validating it, trying to figure out how to make a custom tx to fund this script.  You just "send some coins" to the 31vqFj21siCMUso7KcmRVGMvFyaVbXZXhP.

The following isn't necessary for the sender (you to know) but how it works is I created a 2-of-3 multisig script.

In hex it is:

It you take a HASH-160 of the script you get 029ceacd493bac104217f4da1a0b8c13a18110e4 and if you encode that with Base58Checked you get 31vqFj21siCMUso7KcmRVGMvFyaVbXZXhP.

You aren't required to use P2SH for complex scripts but tell me which one is easier for you as the sender to do:
a) send 1 BTC to 31vqFj21siCMUso7KcmRVGMvFyaVbXZXhP

or

b) Please pay me by sending a custom tx.  Set one of the outputs to be 1 BTC with a PubKeyScript of  522102d83bba35a8022c247b645eed6f81ac41b7c1580de550e7e82c75ad63ee9ac2fe2103aeb68 1df5ac19e449a872b9e9347f1db5a0394d2ec5caf2a9c143f86e232b0d82103d728ad6757d4784e ffea04d47baafa216cf474866c2d4dc99b1e8e3eb936e73153ae.  Make sure you manually compute the other outputs.  Sorry no client helps you do this so fire up bitcoind (or bitcoin-qt w/server=1) and use the createrawtransaction RPC call.   You will need to manually pick your inputs from the unspent set so you might also want to take a look at listunspent and you will neeed to sign and submit the custom tx using signrawtransaction and sendrawtransaction.  Don't worry you can use help on each of these to figure out the custom syntax.

Now imagine this is a business can you imagine asking thousands of customers to do "b"?

what are the essentials of P2SH?  Whats cool about it , why is it important?

JF

Indeed.  Too bad Satoshi didn't think of it from the very beginning.  There is no reason that anything else other than P2SH is needed.   All outputs could simply be hashes of scripts.  As it stands now there are scripts both in the input and output side of the transaction.

Thanks for taking the time to reply DeathAndTaxes.

What you've explained here clears up a great deal.  I was thinking with a mindset towards native multsig, which, it is interesting to know, is clearly not the standard.  P2SH, as you state, is preferred and much more widely implemented.


This is a clever mechanism and should greatly simplify my codebase.  Cheers!

There is no such thing as a "balance" so when a wallet shows you have a balance of "X" it means the wallet contains the private keys necessary to redeem one or more unspent outputs which have a combined value of "X".

In the case of multisig, if you do not have the required number of keys then you can't redeem the output therefore the reported balance does not change.  It doesn't give you "partial credit" to your balance.  You can either redeem (spend) an output or you can't.  If you have less than the required number of keys the bitcoin-core wallet will not show that as spendable (even if you may have the other required keys in another wallet). The wallet has no "scope" beyond what it directly at the current time can "spend".  The reported balance reflects that scope.

In the future wallets maybe should be "smart" in that they can report when output is detected that the wallet can partially sign.  This should be tracked separately from the spendable balance to avoid confusion and possible malicious use.

One thing which will make your job more difficult is that there is "native multisig" (the actual script is recorded in the txn output) and there is P2SH (where the output contains only the hash of the script).  Native multisig is older but it is unlikely that it will be used significantly in the future.   P2SH is more common and easier for the sender.  Native multisig isn't invalid but it is hard to use (no wallet supports you sending money to a multisig script outside of clunky command line procedure calls.  With P2SH the sender doesn't know or care what the script it.  The recipient provides him an address which is an encoded form of the scriptHash and he "sends coins" to that address.  Unless you have a copy of the redeemScript you will not know what the conditions of the script are.

 

I'm working on a few projects and I'm interested in a generic approach to parsing multisig transactions via coin daemon RPC calls.  Might someone be able to recommend any resources for the following?

---
multisig transaction handling and/or multisig script processing such that a call, for example, to `bitcoind getrawransaction 1` could be extrapolated into "Addresses A, B and C have X unspent transaction output available to them via a 2-of-3 m-of-n multisig transaction".
---

Essentially, I am interested in how a blockchain explorer, for example, could deal with multi-sig transactions properly.  Simple (non-multisig) transactions are easy enough to parse from rpc calls, but I am still grappling with exactly how to do the same for multi-sig transactions.  Are there any multi-sig script parsing libraries (ideally in ruby) anyone might be able to recommend?

I'm also not exactly sure what makes sense in terms of address accounting for multisig transactions.  If I have several m-of-n unspent outputs available to me via a certain address, simply adding those output amounts to my address balance (and also to the address balances of the other n-1 folks) doesn't seem right, since it would mean double, triple, etc. counting the same coins.  On the other hand, adding 1/n to the address balance also doesn't seem sensible.  Does anyone have experience with this?  I would be curious to hear some options that folks have considered for displaying this information.

Take, for example, one of Gavin's multisig tests as visible through blockchain.info:

Code:

https://blockchain.info/address/3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC

A novice or relatively non-techincal user would likely have a difficult time figuring out what is going on with multisig transactions from these interfaces alone.

It seems clear that multisig is going to play a key role in helping to provide security and peace of mind for both technical and nontechnical coin-holders alike.  I look forward to learning more and to helping support multisig transactions across the projects on which I am currently tinkering.