From: David Vorick <david.vorick@gmail•com>
To: "t. khan" <teekhan42@gmail•com>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System
Date: Thu, 2 Feb 2017 18:19:39 -0500 [thread overview]
Message-ID: <CAFVRnyqGp9S8HDbHD4Byv26w1afcAorP0JxFq3awMunw6bG=eQ@mail.gmail.com> (raw)
In-Reply-To: <CAGCNRJqNg9-aYG62OxTz5RJyx+JJkx-kt2odooZWs92f5teZiw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
I like the idea of having some way for developers to show that they've
given an idea legitimate consideration, as I feel some proposals are often
considered much more in depth before rejection than the proposer realizes,
however I don't think any sort of on-chain system really makes sense. It
complicates things a lot, adds code, incentives, etc. when really all you
care about is some sort of indication of consideration, support, or
rejection.
I also prefer to think of Bitcoin as a system of vetos rather than a system
of approvals. A lot of times changes will be small, highly technical, and
have no visible impact to your every day user. These types of changes don't
really need support outside the devs. Furthermore, I frankly don't give a
crap if we proposal has support from 85% of the participants if there is a
legitimate technical, social, or political reason that it is a bad idea.
And finally, I don't think it should cost money or political power to raise
an objection. A 13yo who has never been seen before should be able to raise
an objection if they indeed have a legitimate objection. Involving money is
almost certainly going to shut down important valid opinions.
And again, I mostly agree with the motivation. It would be good if it were
easier to figure out who had considered a proposal and what their
objections or praises were. But I would like to see that without any
systemization around what is required to pass or fail a proposal, and with
no barrier to entry (such as voting or sending coins or having a recognized
name like 'Bitfury') to provide an opinion.
[-- Attachment #2: Type: text/html, Size: 1944 bytes --]
next prev parent reply other threads:[~2017-02-02 23:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 19:39 t. khan
2017-02-02 23:19 ` David Vorick [this message]
2017-02-03 0:24 ` Luke Dashjr
2017-02-03 1:32 ` Dave Scotese
2017-02-03 16:19 ` alp alp
2017-02-03 18:20 ` t. khan
2017-02-03 19:22 ` alp alp
2017-02-04 21:23 ` t. khan
2017-02-04 0:57 ` Chris Priest
2017-02-11 15:57 ` Staf Verhaegen
2017-02-14 12:33 ` Peter Todd
2017-02-04 22:02 ` t. khan
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='CAFVRnyqGp9S8HDbHD4Byv26w1afcAorP0JxFq3awMunw6bG=eQ@mail.gmail.com' \
--to=david.vorick@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=teekhan42@gmail$(echo .)com \
/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