[Bitcoin-development] Version bits proposal

Tier Nolan tier.nolan at gmail.com
Wed May 27 09:35:03 UTC 2015


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 at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150527/cd5723c3/attachment.html>


More information about the bitcoin-dev mailing list