I think it would be better to have the deadlines set as block counts.  That eliminates the need to use the median time mechanism.

The deadline could be matched to a "start-line".  The definition would then be something like

BIP 105
Start block: 325000
End block: 350000
Activation: 750 of 1000
Implication: 950 of 1000
Bit: 9

This would allow creation of a simple table of known BIPs.  It also keeps multiple users of the bit as strictly separate.

The alternative to the start time is that it is set equal to the deadline or implication time of the previous user of the bit.

Was the intention to change the 95% rule.  You need 750 of the last 1000 to activate and then must wait at least 1000 for implication?


On Wed, May 27, 2015 at 4:51 AM, Jorge Timón <jtimon@jtimon.cc> wrote:

It would also help to see the actual code changes required, which I'm sure will be much shorter than the explanation itself.

On May 27, 2015 5:47 AM, "Luke Dashjr" <luke@dashjr.org> wrote:
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
> Feel free to comment. As the gist does not support notifying participants
> of new comments, I would suggest using the mailing list instead.

I suggest adding a section describing how this interacts with and changes GBT.

Currently, the client tells the server what the highest block version it
supports is, and the server indicates a block version to use in its template,
as well as optional instructions for the client to forcefully use this version
despite its own maximum version number. Making the version a bitfield
contradicts the increment-only assumption of this design, and since GBT
clients are not aware of overall network consensus state, reused bits can
easily become confused. I suggest, therefore, that GBT clients should indicate
(instead of a maximum supported version number) a list of softforks by
identifier keyword, and the GBT server respond with a template indicating:
- An object of softfork keywords to bit values, that the server will accept.
- The version number, as presently conveyed, indicating the preferred softfork
flags.

Does this sound reasonable, and/or am I missing anything else?

Luke

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

------------------------------------------------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development