Bitcoin Forum

I vaguely recall years ago, I stumbled upon a topic for a discussion on how Multisig could be scripted such that:

There are 3 keys for 2 of 3 multisig, A, B and C. A is the master key and its signature is required such that the transaction is invalid without its signature. (or something similar)

I was pretty intrigued by the scripting of the redeem script at that time but I lost the link to it. I've been trying to find that topic for the past week but I can't seem to find it anywhere. Can someone direct me to it?

Building a 2-of-(1+(1-of-2)) multisig transaction [i.e A + (B or C)] (https://bitcointalk.org/index.php?topic=1231148.20)

This one?

Very interesting proposal, but a bit dangerous as well. If private key holder A refuses to sign or goes havoc, there is nothing that private key holders B and C can do. With a regular 2 of 3 multisig, that wouldn't be the case.

A user already created a working script apparently:

Isn't that the whole point, though? If A is going to be the master* key, then if A refuses to sign there is nothing B or C can do about it.

Such a set up could be used for example with a business's funds so the manager/boss can, with the help of a single employee, release funds to that employee for some specific task or outgoing, but the employees can't conspire and spend money without the boss's oversight. It is essentially the same as setting up an x-of-y multisig, where the boss holds x-1 keys and the employees collectively hold x-1 keys.

*Probably best to find some other term rather than master key for this, to avoid confusion with master private/public keys. Perhaps mandatory key? Or owner key?

That's what I was thinking: make a 3 out of 4 multisig, A holds 2 keys, B and C each hold 1 key. Although amaclin's solution (https://bitcointalk.org/index.php?topic=1231148.msg12830232#msg12830232) looks impressive, multisig is complicated enough as it is already.

it works but the transaction size would be bigger in comparison because in this multisig setup the signature has to contain 3 signatures (2 from A and one from B/C) whereas before it just needed 2 (1 from A and 1 from B/C).
~72 bytes is a considerable size increase per input too which can't be ignored.

True, but I don't expect someone who uses this to care about paying a few dollar more on transaction fees.

well its not just always about the money though. we are technically discussing the best solutions for a particular problem in this board. ::)

It seems to me that in that case all this can be achieved without a multisig setup as well.

If I am your boss and I can decide that you shouldn't be paid or use company funds, I shouldn't have to rely on party C to decide whether or not the funds to you should be released either. Ultimately, party A makes the final decision, why complicate it.

The employees can still conspire, but they have to trick the boss to fall for it.
The only advantage is that this setup can prevent the boss (party A) to misuse company funds without getting either B or C on his side.
Otherwise, user A has too much power.   

I feel you are missing the point. What I gave was simply an example.

Let's say the boss has allocated funds to a project manager (A) and his subordinates (B and C), and doesn't want any one party to be able to spend on their own, and also wants the manager to have a say in every spending decision.

Let's say I'm a parent (A) and have a joint savings account for my two kids (B and C). It's their money so I shouldn't be able to spend it, but I also want them to have my approval before spending anything and not be able to collaborate to empty the account without me.

Let's say I run a forum (A) and want to put some forum funds in a multi-sig escrow with some other users (B and C). I want my escrow partners to double check all my decisions/transactions before I'm allowed to spend anything, but I also don't want my escrow partners to be able to conspire behind my back to steal the forum funds.

There are plenty of scenarios where this set up may be useful.

Or, "A" could be an "auditor"... "B" and "C" could make individual requests to spend funds and "A" has final sign off on the requisition, but "A" cannot then spend any funds on their own...

Which is essentially what the original thread was about... so that users (ostensibly "buyers" and "sellers") could request funds in the event of a dispute, and the "mediator" could authorise the payment, without "B" and "C" being able to cut them out of the deal... likewise, the "mediator" could not simply steal the funds.

It's certainly an interesting concept...

After reading your reply, i think 3-of-4 could be alternative of what OP looking for where a person have access to 2 private key A and B

It definitely is. This scheme would stand to benefit from Schnorr as well. I was exploring the option whereby it doesn't necessarily have to follow a conventional method.

---

Thank you all for the reply. The purpose of this topic was mainly for me to explore the script used for that specific transaction scheme and not exactly to discuss the viability of the solution. Its great to see the discussion stemmed from it though.

In Iran, it is a common practice to have CEOs in charge of issuing cheques their signatures are to be complemented by one (or two) of the other board members. Actually, bitcoin's legacy n of m multisignature scheme is of much less importance compared to the one discussed here

BTW, I'd suggest a simple script such as:

* OP_IP will pop the <Ceo pubkey> and converts that to a bool, which is not intended. instead it should come first.
* OP_CheckSigVerify makes existence of CEO signature mandatory which begs the question of why even have pubkey1 and 2 involved if the CEO always signs everything specially since there is an OP_IF which we can ignore (passing False to it so that it doesn't execute).

if we want to keep CEO signature mandatory then drop the OP_IF and put the OP_1,..., OP_M right after the OP_CheckSigVerify otherwise if we want to keep it optional then change it to OP_CheckSig and change OP_IF to OP_NoIf so that the result of it is used in it (if we couldn't verify using CEO pubkey, use the multisig).

This would increase the cost of spending any coin in the multi-sig address. You need to pay for block space for each signature that signs a transaction.

The above is especially true if there are many "employees" as the "boss"/"master" key will need to make up 1/2 of the "m" number of keys. If there are 7 employees, the boss would need to sign from 8 keys, and pay for block space for 8 signatures. This will also limit the number of "employee" keys.

A common setup might be that an employee requests to process a transaction and the boss 'signs off' on the transaction. If later down the line, the transaction turns out to be something that should not have happened, the employee can be held accountable, and multiple low level employees can not spend money without permission from their boss.

In line #1 I misplaced the operand, and in line #3 I didn't put the operator:  :D
Obviously I was in a rush when typing this code and the correct version would be:
Besides this, OP_IF comes after OP_Checksigverify which pushes a bool to the stack, so the script works fine as follows:
First it checks CEO's signature and either pushes a 1 (True) or 0 (False) to the stack then this value is popped and OP_IF decides whether to check the multisig condition at all or to give up with a failed script result.

It is exactly what the use-case dictates: CEO signature is mandatory AND 1(n) of m signatures of other stakeholders is needed as well.

you are forgetting the "Verify" part in that OP which means after it performed the first part (CheckSig) it performs a OP_VERIFY which is popping whatever CheckSig pushed to the stack and verifies if it is true so there won't be anything new left on the stack. the signature has to be OP_TRUE/OP_FALSE <CEO signature> followed by <CEO pubkey> OP_CheckSigVerify or it won't work. or just drop the Verify part.

Dropped it as you said: