From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: Block signal enforcement via tx fees
Date: Sun, 14 May 2017 08:18:18 -0400 [thread overview]
Message-ID: <cTHMdT2aRie-f8IcK-95pSeLVd1aAuCrpLsN4lmuFITiOgnAb-pK_A9x1lKASZlWIS0VsOSJn3f-IJGCmnY_dBtiRmcr2TcT_uD2gWNdZSw=@protonmail.com> (raw)
In-Reply-To: <201705121922.57445.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2824 bytes --]
prev parent reply other threads:[~2017-05-14 12:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 19:22 Luke Dashjr
2017-05-12 22:17 ` ZmnSCPxj
2017-05-12 22:22 ` Peter Todd
2017-05-13 0:49 ` Luke Dashjr
2017-05-13 3:26 ` Eric Voskuil
2017-05-13 3:54 ` ZmnSCPxj
2017-05-13 5:36 ` Eric Voskuil
2017-05-13 5:45 ` Luke Dashjr
2017-05-13 6:43 ` Eric Voskuil
2017-05-13 12:48 ` Peter Todd
2017-05-13 16:42 ` Luke Dashjr
2017-05-13 4:23 ` Russell O'Connor
2017-05-13 5:26 ` Luke Dashjr
2017-05-13 17:11 ` Russell O'Connor
2017-05-15 1:14 ` Rusty Russell
2017-05-20 5:05 ` Anthony Towns
2017-05-14 12:18 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='cTHMdT2aRie-f8IcK-95pSeLVd1aAuCrpLsN4lmuFITiOgnAb-pK_A9x1lKASZlWIS0VsOSJn3f-IJGCmnY_dBtiRmcr2TcT_uD2gWNdZSw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox