Besides this, OP_IF comes after OP_Checksigverify which pushes a bool to the stack,
or just drop the Verify part.Code:
OP_Checksig
OP_IF
n... m op_CheckMultiSig
OP_ENDIF
Op_Verify
Topic: Multisig with a twist (Read 386 times)
Besides this, OP_IF comes after OP_Checksigverify which pushes a bool to the stack,
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 Code:
OP_Checksigverify
OP_IF
1... m
OP_ENDIF
* OP_IP will pop the
* 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).
Obviously I was in a rush when typing this code and the correct version would be:
Code:
OP_Checksigverify
OP_IF
1... m op_CheckMultiSig
OP_ENDIF
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.
Very interesting proposal, but a bit dangerous as well. If private key holder A refuses to sign...
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?
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
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.
Snip
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.
Code:
OP_Checksigverify
OP_IF
1... m
OP_ENDIF
* OP_IP will pop the
* 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).
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:
BTW, I'd suggest a simple script such as:
Code:
OP_Checksigverify
OP_IF
1... m
OP_ENDIF
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.
Very interesting proposal, but a bit dangerous as well. If private key holder A refuses to sign...
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?
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
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...
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...
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.
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.
Snip
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.
~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.
~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. That's what I was thinking: make a 3 out of 4 multisig, A holds 2 keys, B and C each hold 1 key.
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.
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.
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 looks impressive, multisig is complicated enough as it is already. Very interesting proposal, but a bit dangerous as well. If private key holder A refuses to sign...
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?
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:
A user already created a working script apparently:
1. take 3 pubkeys
2. create a redeem script
3. hash it and receive p2sh address 3xxxxx
4. fund this address
5. create raw transaction spending this address
6. sign it with ( and ) or ( and )
7. create scriptSig for your raw transaction
8. voila!
2. create a redeem script
Code:
OP_CHECKSIGVERIFY OP_1 OP_2 OP_CHECKMULTISIG
3. hash it and receive p2sh address 3xxxxx
4. fund this address
5. create raw transaction spending this address
6. sign it with (
7. create scriptSig for your raw transaction
Code:
OP_0
8. voila!
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?
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?
Jump to: