Good morning Luke,
Considering the proposal as a whole, I think, it's a little imperfect.
The main problem, is that the end goal is activation, but what the opcode
rewards is signalling.
Consider a miner who signals only if the number of non-signalling blocks in
this retargeting time > 5% of 2016. Such a miner would still effectively block
a softfork activation, while still has a chance (albeit reduced) of winning the
transaction fees of the block-signalling-opcode, in proportion to the number of
miners not signaling for a softfork or using a similar algorithm.
What we should reward should be activation.
How about an opcode which requires this stack (stack top at right)
<signature> <publickeyhash> <versionbit>
1. If the <versionbit> given is in state FAILED, then it checks if the given
<signature> matches the given <publickeyhash>.
2. If the <versionbit> given is in state LOCKED_IN or ACTIVE, it checks if the
given <signature> matches the block's coinbase transaction signature.
This creates an output which is refundable to the owner, if the softfork fails
to activate, but which may be claimed by miners, if the softfork activates.
I don't know enough yet about Bitcoin's codebase to know if the above spec is
actually workable.
But basically, I think we should create an assurance contract for activation of
a softfork.
--
Also, this invites an inverse logic:
1. If the <versionbit> given is in state LOCKED_IN or ACTIVE, then it checks if
the given <signature> matches the given <publickeyhash>.
2. If the <versionbit> given is in state FAILED, it checks if the given
<signature> matches the block's coinbase transaction signature.
I think, your proposal allows an economic actor to pay fees if the miner is
explicitly not signaling. This is supposed to allow a vote against a particular
softfork.
Thus, it should also be possible to allow to vote against a softfork.
But in any case, I think, it's better to pay on activation or failure to
activate, rather than mere signalling, as signalling is not the goal.
Activation, or rejection of activation, is the goal.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
