From: Tom Zander <tomz@freedommail•ch>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)
Date: Tue, 04 Apr 2017 13:16:08 +0200 [thread overview]
Message-ID: <4095148.TDyWagoPAR@strawberry> (raw)
In-Reply-To: <PU5yHaeZtxR5ManpM0q7ZIN1pElEorBfO09u7ZIC-h81mQizYCZ5qNv89Tb2ZLNHbCktmV65q2Xkm1K3UckvVZLOWBMW7-riWYRY4HtFe1A=@protonmail.com>
On Monday, 3 April 2017 11:06:02 CEST Sancho Panza wrote:
> ==Specification==
>
> To be elaborated.
Please do elaborate :)
The meat of the proposal is missing.
> It is thought that only cosmetic changes are needed to generalize from
> only soft forks to 'soft or hard forks', and to add the additional
> per-bit parameters 'threshold' and 'windowsize'
I agree that the type of forks are rather irrelevant to the voting
mechanism. As we remember that BIP109 used a voting bit too.
The per-bit (lets call that per-proposal) parameter threshold and windowsize
are a different matter though, based on the next paragraph you wrote;
> The design of the state machine is envisioned to remain unchanged.
The entire point of BIP9 is to allow nodes that do not know about an upgrade
to still have a functional state machine. But I don’t see how you can have a
state machine if the two basic variables that drive it are not specified.
Now, to be clear, I am a big fan of making the window size and the threshold
more flexible.
But in my opinion we would not be able to have a state machine without those
variables in the actual BIP because old nodes would miss the data to
transition to certain states.
Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse
the CSV one). Maybe we can come up with 3 default sets of properties and
when a proposal starts to use bit 11 it behaves differently than if it uses
22.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
next prev parent reply other threads:[~2017-04-04 11:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 9:06 Sancho Panza
2017-04-04 11:16 ` Tom Zander [this message]
2017-04-04 16:41 ` Sancho Panza
2017-04-04 16:49 ` Sancho Panza
2017-04-04 18:01 ` Luke Dashjr
2017-04-04 19:28 ` Sancho Panza
2017-04-05 10:08 ` Tom Zander
2017-04-05 14:09 ` Thomas Kerin
2017-04-08 21:58 ` Sancho Panza
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=4095148.TDyWagoPAR@strawberry \
--to=tomz@freedommail$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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