Oliver Petruzel [ARCHIVE] on Nostr: š Original date posted:2015-09-03 š Original message:I agree with Simon's ...
š
Original date posted:2015-09-03
š Original message:I agree with Simon's sentiments for question #1, and was actually going to
pose the same question. Non-votes seem like they may poison the well
mathematically, and counting them anyway seems to encourage a lack of
participation at a time when miners really need to be very much involved.
Since we're handing them even more control over the ecosystem with this
BIP, it would be nice to ensure they (all miners) seriously consider their
impact and role on a regular basis.
I'm curious why we couldn't/shouldn't simply drop the non-votes. (There may
be a great reason that I can't think of, but it's eluding me... LOL)
That said, I don't see any issue with counting votes from outside of the
range as the maximum/minimum accordingly (Simon's question #2). In fact,
such votes would be very interesting (worthy of further discussion) if they
begin to lean heavily in either direction.
V/r,
Oliver
On Sep 3, 2015 3:41 PM, "Simon Liu via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Jeff,
>
> Thoughts on this part of the proposal:
>
> "Absent/invalid votes are counted as votes for the current hardLimit.
> Out of range votes are counted as the nearest in-range value."
>
> 1. Why should an absent vote be considered a vote for the status quo? A
> non-voter should have zero impact on the result.
>
> 2. Why should out of range votes be counted? They're an invalid vote, a
> spoiled ballot as such, and thus it would be better if they were discarded.
>
> Regards,
> Simon
>
>
> On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
> > BIP 100 initial public
> > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >
> > Emphasis on "initial" This is a starting point for the usual open
> > source feedback/iteration cycle, not an endpoint that Must Be This Way.
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/1ab14fff/attachment.html>
š Original message:I agree with Simon's sentiments for question #1, and was actually going to
pose the same question. Non-votes seem like they may poison the well
mathematically, and counting them anyway seems to encourage a lack of
participation at a time when miners really need to be very much involved.
Since we're handing them even more control over the ecosystem with this
BIP, it would be nice to ensure they (all miners) seriously consider their
impact and role on a regular basis.
I'm curious why we couldn't/shouldn't simply drop the non-votes. (There may
be a great reason that I can't think of, but it's eluding me... LOL)
That said, I don't see any issue with counting votes from outside of the
range as the maximum/minimum accordingly (Simon's question #2). In fact,
such votes would be very interesting (worthy of further discussion) if they
begin to lean heavily in either direction.
V/r,
Oliver
On Sep 3, 2015 3:41 PM, "Simon Liu via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Jeff,
>
> Thoughts on this part of the proposal:
>
> "Absent/invalid votes are counted as votes for the current hardLimit.
> Out of range votes are counted as the nearest in-range value."
>
> 1. Why should an absent vote be considered a vote for the status quo? A
> non-voter should have zero impact on the result.
>
> 2. Why should out of range votes be counted? They're an invalid vote, a
> spoiled ballot as such, and thus it would be better if they were discarded.
>
> Regards,
> Simon
>
>
> On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
> > BIP 100 initial public
> > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >
> > Emphasis on "initial" This is a starting point for the usual open
> > source feedback/iteration cycle, not an endpoint that Must Be This Way.
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/1ab14fff/attachment.html>