From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Version bits proposal
Date: Wed, 27 May 2015 10:35:03 +0100 [thread overview]
Message-ID: <CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDoriDaQ1AjRDFxCT9zCNPQakJd9xRxfWkOJBf4v22hndQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 4025 bytes --]
next prev parent reply other threads:[~2015-05-27 9:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 1:48 Pieter Wuille
2015-05-27 2:31 ` Douglas Roark
2015-05-27 3:46 ` Luke Dashjr
2015-05-27 3:51 ` Jorge Timón
2015-05-27 9:35 ` Tier Nolan [this message]
2015-05-27 10:15 ` Peter Todd
2015-05-27 11:26 ` Tier Nolan
2015-05-27 22:52 ` Sergio Lerner
2015-05-28 1:05 ` Patrick Strateman
2015-05-28 7:51 ` Christian Decker
2015-05-28 8:11 ` Adam Back
2015-06-01 14:50 ` Potter QQ
2015-05-27 10:15 ` Jorge Timón
2015-06-03 20:42 ` Pieter Wuille
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='CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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