Increase maximum signatures for OP_FEDERATION OP_CHECKMULTISIG/VERIFY #492
Conversation
| if (nKeysCount < 0 || nKeysCount > 20) | ||
| return SetError(ScriptError.PubkeyCount); | ||
|
|
||
| nOpCount += nKeysCount; |
There was a problem hiding this comment.
@zeptin , do you know why the key count is added to the opcode count? Do we need this?
There was a problem hiding this comment.
Basically this is a consensus rule; there can only be a maximum of 201 non-push opcodes in any given script. If this was to be changed then I think we need to look at subclassing ScriptEvaluationContext so that per-network versions can be injected.
https://bitcoin.stackexchange.com/questions/38230/maximum-number-of-op-codes-in-script
| return SetError(ScriptError.OpCount); | ||
| if (this.Network.Federations != null && lastOpcode?.Code == OpcodeType.OP_FEDERATION) | ||
| { | ||
| if (nKeysCount < 0 || nKeysCount > 150) |
There was a problem hiding this comment.
@zeptin, I realise that 150 signatures may have a significant impact. Perhaps we should agree on some smaller maximum number.
quantumagi
changed the title
|
As far as I remember we wanted to work around that with system smart contracts, so what's the motivation behind this PR? |
|
@noescape00, @zeptin , thank you for the valuable feedback. This (draft) PR demonstrates how we can increase the number of allowed signatures. I would see this as a shorter term solution. System contracts can, for now, give us the ability to modify the list of multi-sig members without necessarily replacing the redeem script itself with a smart contract. If you are suggesting that we skip this step then we are perhaps looking at something that will take a bit longer with a more complicated switch-over. On the flip-side we have to look at how we justify that complexity (= risk). Note that the recently added OP_FEDERATION opcode allows us to dynamically push the multisig public keys onto the OP_CHECKMULTISIG evaluation stack instead of relying on hard-coded public keys in the redeem script. Those public keys are now sourced from the current federation and can just as easily be sourced from a simple system contract instead. A more dramatic change will involve changing the redeem script and a process including transferral of funds between old and new multisig addresses. |
This PR increases the maximum number of signatures associated with OP_CHECKMULTISIG/VERIFY opcodes.
We may also need to give some thought to how the nodes will be affected by evaluating a large number of signatures.