alp alp [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-02-03 to 2017-02-08
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev, Pre-BIP
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:56:06

- reply

📅 Original date posted:2017-02-08
📝 Original message:>Only the majority needs to consent, though what is considered a majority
varies depending on the context (95%, 75%, 51%). Nowhere does it say
"everyone needs to agree".
There's a pretty huge gap between 90% and nearly 100%. 90% excluding 10%
only 7 times results in only 48% of the original base.
>If a small dissenting minority can block all forward progress then bitcoin
is no longer interesting.
Your definition of forward may be different than other users.
>Is that really the bitcoin that you want to be a part of?
Yes, I chose Bitcoin because it relies on a strictly held consensus
mechanism and not one that changes on the whims of the majority. We have
tens of dozens of political currencies for that.
>When the 1MB cap was implemented it was stated specifically that we could
increase it when we needed it. The white paper even talks about scaling to
huge capacity. Not sure where you got the idea that we all agreed to stay
at 1MB forever, I certainly didn't. It was never stated or implied that we
could change the coin cap later(please cite if I'm mistaken).
The community has not agreed that it is needed at this time. Perhaps they
will change their mind at some point in the future. We have also learned a
great deal since the publication of the initial whitepaper, such as the
unstable state without a backlog or subsidy. Fortunately, participation in
this system is voluntary, and you are free to leave at any time.
This seems to be venturing quite off topic, and perhaps would be better
suited for the bitcoin-discuss list.
On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson <andrew.johnson83 at gmail.com>
wrote:
> If a small dissenting minority can block all forward progress then bitcoin
> is no longer interesting. What an incredibly simple attack vector...
>
> No need to break any cryptography, find a bug to exploit, build tens of
> millions of dollars in mining hardware, spend lots of bitcoin on fees to
> flood the network, or be clever or expend any valuable resources in any
> way, shape, or form.
>
> Just convince(or pay, if you do want to expend some resources) a few
> people(or make up a few online personas) to staunchly refuse to accept
> anything at all and the entire system is stuck in 2013(when we first
> started widely discussing a blocksize increase seriously).
>
> Is that really the bitcoin that you want to be a part of?
>
> When the 1MB cap was implemented it was stated specifically that we could
> increase it when we needed it. The white paper even talks about scaling to
> huge capacity. Not sure where you got the idea that we all agreed to stay
> at 1MB forever, I certainly didn't. It was never stated or implied that we
> could change the coin cap later(please cite if I'm mistaken).
>
>
> On Feb 8, 2017 12:16 PM, "alp alp" <alp.bitcoin at gmail.com> wrote:
>
> Doing nothing is the rules we all agreed to. If those rules are to be
> changed,nearly everyone will need to consent. The same rule applies to the
> cap, we all agreed to 21m, and if someone wants to change that, nearly
> everyone would need to agree.
>
>
> On Feb 8, 2017 10:28 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
> wrote:
>
> It is when you're talking about making a choice and 6.3x more people
> prefer something else. Doing nothing is a choice as well.
>
> Put another way, if 10% supported increasing the 21M coin cap and 63% were
> against, would you seriously consider doing it?
>
> On Feb 8, 2017 9:57 AM, "alp alp" <alp.bitcoin at gmail.com> wrote:
>
>> 10% is not a tiny minority.
>>
>> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
>> wrote:
>>
>>> You're never going to reach 100% agreement, and stifling the network
>>> literally forever to please a tiny minority is daft.
>>>
>>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> 10% say literally never. That seems like a significant
>>> disenfranchisement and lack of consensus.
>>>
>>> On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at dashjr.org> wrote:
>>>>
>>>>> On Monday, February 06, 2017 6:19:43 PM you wrote:
>>>>> > >My BIP draft didn't make progress because the community opposes any
>>>>> block
>>>>> > >size increase hardfork ever.
>>>>> >
>>>>> > Luke, how do you know the community opposes that? Specifically, how
>>>>> did you
>>>>> > come to this conclusion?
>>>>>
>>>>> http://www.strawpoll.me/12228388/r
>>>>
>>>>
>>>> That poll shows 63% of votes want a larger than 1 MB block by this
>>>> summer. How do you go from that to "the community opposes any block
>>>> increase ever"? It shows the exact opposite of that.
>>>>
>>>>
>>>>> > >Your version doesn't address the current block size
>>>>> > >issues (ie, the blocks being too large).
>>>>> >
>>>>> > Why do you think blocks are "too large"? Please cite some evidence.
>>>>> I've
>>>>> > asked this before and you ignored it, but an answer would be helpful
>>>>> to the
>>>>> > discussion.
>>>>>
>>>>> Full node count is far below the safe minimum of 85% of economic
>>>>> activity.
>>>>>
>>>>
>>>> Is this causing a problem now? If so, what?
>>>>
>>>>
>>>>> Typically reasons given for people not using full nodes themselves
>>>>> come down
>>>>> to the high resource requirements caused by the block size.
>>>>
>>>>
>>>> The reason people stop running nodes is because there's no incentive to
>>>> counteract the resource costs. Attempting to solve this by making blocks
>>>> *smaller* is like curing a disease by killing the patient. (Incentivizing
>>>> full node operation would fix that problem.)
>>>>
>>>> - t.k.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20170208/672a9a83/attachment-0001.html>

2023-06-07 17:56:05

- reply

📅 Original date posted:2017-02-08
📝 Original message:Doing nothing is the rules we all agreed to. If those rules are to be
changed,nearly everyone will need to consent. The same rule applies to the
cap, we all agreed to 21m, and if someone wants to change that, nearly
everyone would need to agree.
On Feb 8, 2017 10:28 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
wrote:
It is when you're talking about making a choice and 6.3x more people prefer
something else. Doing nothing is a choice as well.
Put another way, if 10% supported increasing the 21M coin cap and 63% were
against, would you seriously consider doing it?
On Feb 8, 2017 9:57 AM, "alp alp" <alp.bitcoin at gmail.com> wrote:
> 10% is not a tiny minority.
>
> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
> wrote:
>
>> You're never going to reach 100% agreement, and stifling the network
>> literally forever to please a tiny minority is daft.
>>
>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 10% say literally never. That seems like a significant
>> disenfranchisement and lack of consensus.
>>
>> On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at dashjr.org> wrote:
>>>
>>>> On Monday, February 06, 2017 6:19:43 PM you wrote:
>>>> > >My BIP draft didn't make progress because the community opposes any
>>>> block
>>>> > >size increase hardfork ever.
>>>> >
>>>> > Luke, how do you know the community opposes that? Specifically, how
>>>> did you
>>>> > come to this conclusion?
>>>>
>>>> http://www.strawpoll.me/12228388/r
>>>
>>>
>>> That poll shows 63% of votes want a larger than 1 MB block by this
>>> summer. How do you go from that to "the community opposes any block
>>> increase ever"? It shows the exact opposite of that.
>>>
>>>
>>>> > >Your version doesn't address the current block size
>>>> > >issues (ie, the blocks being too large).
>>>> >
>>>> > Why do you think blocks are "too large"? Please cite some evidence.
>>>> I've
>>>> > asked this before and you ignored it, but an answer would be helpful
>>>> to the
>>>> > discussion.
>>>>
>>>> Full node count is far below the safe minimum of 85% of economic
>>>> activity.
>>>>
>>>
>>> Is this causing a problem now? If so, what?
>>>
>>>
>>>> Typically reasons given for people not using full nodes themselves come
>>>> down
>>>> to the high resource requirements caused by the block size.
>>>
>>>
>>> The reason people stop running nodes is because there's no incentive to
>>> counteract the resource costs. Attempting to solve this by making blocks
>>> *smaller* is like curing a disease by killing the patient. (Incentivizing
>>> full node operation would fix that problem.)
>>>
>>> - t.k.
>>>
>>>
>>> _______________________________________________
>>> 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/20170208/fe125147/attachment-0001.html>

2023-06-07 17:56:04

- reply

📅 Original date posted:2017-02-08
📝 Original message:10% is not a tiny minority.
On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com> wrote:
> You're never going to reach 100% agreement, and stifling the network
> literally forever to please a tiny minority is daft.
>
> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
> 10% say literally never. That seems like a significant disenfranchisement
> and lack of consensus.
>
> On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at dashjr.org> wrote:
>>
>>> On Monday, February 06, 2017 6:19:43 PM you wrote:
>>> > >My BIP draft didn't make progress because the community opposes any
>>> block
>>> > >size increase hardfork ever.
>>> >
>>> > Luke, how do you know the community opposes that? Specifically, how
>>> did you
>>> > come to this conclusion?
>>>
>>> http://www.strawpoll.me/12228388/r
>>
>>
>> That poll shows 63% of votes want a larger than 1 MB block by this
>> summer. How do you go from that to "the community opposes any block
>> increase ever"? It shows the exact opposite of that.
>>
>>
>>> > >Your version doesn't address the current block size
>>> > >issues (ie, the blocks being too large).
>>> >
>>> > Why do you think blocks are "too large"? Please cite some evidence.
>>> I've
>>> > asked this before and you ignored it, but an answer would be helpful
>>> to the
>>> > discussion.
>>>
>>> Full node count is far below the safe minimum of 85% of economic
>>> activity.
>>>
>>
>> Is this causing a problem now? If so, what?
>>
>>
>>> Typically reasons given for people not using full nodes themselves come
>>> down
>>> to the high resource requirements caused by the block size.
>>
>>
>> The reason people stop running nodes is because there's no incentive to
>> counteract the resource costs. Attempting to solve this by making blocks
>> *smaller* is like curing a disease by killing the patient. (Incentivizing
>> full node operation would fix that problem.)
>>
>> - t.k.
>>
>>
>> _______________________________________________
>> 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/20170208/b9d35e07/attachment-0001.html>

2023-06-07 17:56:03

- reply

📅 Original date posted:2017-02-08
📝 Original message:10% say literally never. That seems like a significant disenfranchisement
and lack of consensus.
On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Monday, February 06, 2017 6:19:43 PM you wrote:
>> > >My BIP draft didn't make progress because the community opposes any
>> block
>> > >size increase hardfork ever.
>> >
>> > Luke, how do you know the community opposes that? Specifically, how did
>> you
>> > come to this conclusion?
>>
>> http://www.strawpoll.me/12228388/r
>
>
> That poll shows 63% of votes want a larger than 1 MB block by this summer.
> How do you go from that to "the community opposes any block increase ever"?
> It shows the exact opposite of that.
>
>
>> > >Your version doesn't address the current block size
>> > >issues (ie, the blocks being too large).
>> >
>> > Why do you think blocks are "too large"? Please cite some evidence. I've
>> > asked this before and you ignored it, but an answer would be helpful to
>> the
>> > discussion.
>>
>> Full node count is far below the safe minimum of 85% of economic activity.
>>
>
> Is this causing a problem now? If so, what?
>
>
>> Typically reasons given for people not using full nodes themselves come
>> down
>> to the high resource requirements caused by the block size.
>
>
> The reason people stop running nodes is because there's no incentive to
> counteract the resource costs. Attempting to solve this by making blocks
> *smaller* is like curing a disease by killing the patient. (Incentivizing
> full node operation would fix that problem.)
>
> - t.k.
>
>
> _______________________________________________
> 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/20170208/18d9cda5/attachment.html>

2023-06-07 17:55:56

- reply

📅 Original date posted:2017-02-03
📝 Original message:These are non-answers. Someone must decide. Someone must decide what kind
of company counts (e.g. does a dark market seller count as a business?
Does some guy who sells $10/year worth of goods using Bitcoin count the
same as large companies like Coinbase/BitPay/Blockstream). Someone must
decide which websites are checked for votes or addresses. Someone must
decide if a rogue employee made a transaction on behalf of the company or
not.
Registering domain names is trivial and can be automated if the incentives
were needed for it.
You mention developers who have commit access. This excludes the vast
majority of developers. You also don't mention which repositories count.
Do the developers of bcoin count or not?
These questions all would need to be answered before any kind of proposal
like this can be taken seriously. Without these kinds of answers, this
proposal is far from complete.
On Fri, Feb 3, 2017 at 12:20 PM, t. khan <teekhan42 at gmail.com> wrote:
> Most of these are answered in the BIP, but for clarity:
>
> >Who decides on which companies are eligible?
> Preferably no one decides. The company would have to exist prior to the
> vote, and would need a public-facing website. In the event of contested
> votes (meaning someone finds evidence of a fake company), the admin could
> investigate and post results.
>
> >Is there some kind of centralized database that one registers?
> No.
>
> >Who administers this?
> I don't know. I'm happy to volunteer, if no one else wants to be
> responsible for it. The only task would be adding the confirmed votes to
> each respective BIP. From there, everything's public and can be confirmed
> by everyone.
>
> >What is to stop someone from creating a million fake companies to sway
> the voting?
> The logistics of doing that prevent it. But let's say 10 fake companies
> ... first, you'd need to register ten domain names, host and customize the
> website, all before the vote and in a way that no one would notice.
>
> >How does a company make it's vote?
> Someone at the company sends a very small transaction to the BIP's vote
> address. Someone at the company then posts what the vote was and its
> transaction ID on the company's blog/twitter, etc., and then emails the URL
> to the administrator.
>
> >How does one verify that the person voting on behalf of a company is
> actually the correct person?
> They post it on their company blog.
>
> On Fri, Feb 3, 2017 at 11:19 AM, alp alp via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This proposal seems hopelessly broken.
>>
>> Who decides on which companies are eligible? Is there some kind of
>> centralized database that one registers? Who administers this? What is to
>> stop someone from creating a million fake companies to sway the voting?
>> How does a company make it's vote? How does one verify that the person
>> voting on behalf of a company is actually the correct person?
>>
>>
>>
>> On Thu, Feb 2, 2017 at 7:32 PM, Dave Scotese via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> There are two ideas here for "on-chain" voting, both of which require
>>> changes to the software. I agree with David that on-chain solutions
>>> complicate things. Both proposals can be effected without any software
>>> changes:
>>>
>>> Those who wish to use proof of stake can provide a service for making
>>> vanity addresses containing some indicator of the proposal to be supported
>>> - 1bigblock or 12mbblk or whatever - based on a supporter-provided secret
>>> key, and then supporters can move their bitcoin into their own vanity
>>> address and then whoever wants to can create a website to display the
>>> matching addresses and explain that this is the financial power in the
>>> hands of supporters and how to add your "financial power vote."
>>>
>>> Those who simply want to "buy votes" can use their funds in marketing
>>> efforts to promote the proposal they support.
>>>
>>> This second method, of course, can be abused. The first actually
>>> requires people to control bitcoin in order to represent support. Counting
>>> actual, real people is still a technology in its infancy, and I don't think
>>> I want to see it progress much. People are not units, but individuals, and
>>> their value only becomes correlated to their net worth after they've been
>>> alive for many years, and even then, some of the best people have died
>>> paupers. If bitcoin-discuss got more traffic, I think this discussion would
>>> be better had on that list.
>>>
>>> notplato
>>>
>>> On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Strongly disagree with buying "votes", or portraying open standards as a
>>>> voting process. Also, this depends on address reuse, so it's
>>>> fundamentally
>>>> flawed in design.
>>>>
>>>> Some way for people to express their support weighed by coins (without
>>>> losing/spending them), and possibly weighed by running a full node,
>>>> might
>>>> still be desirable. The most straightforward way to do this is to
>>>> support
>>>> message signatures somehow (ideally without using the same pubkey as
>>>> spending), and some [inherently unreliable, but perhaps useful if the
>>>> community "colludes" to not-cheat] way to sign with ones' full node.
>>>>
>>>> Note also that the BIP process already has BIP Comments for leaving
>>>> textual
>>>> opinions on the BIP unrelated to stake. See BIP 2 for details on that.
>>>>
>>>> Luke
>>>>
>>>>
>>>> On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:
>>>> > Please comment on this work-in-progress BIP.
>>>> >
>>>> > Thanks,
>>>> >
>>>> > - t.k.
>>>> >
>>>> > ----------------------
>>>> > BIP: ?
>>>> > Layer: Process
>>>> > Title: Community Consensus Voting System
>>>> > Author: t.khan <teekhan42 at gmail.com>
>>>> > Comments-Summary: No comments yet.
>>>> > Comments-URI: TBD
>>>> > Status: Draft
>>>> > Type: Standards Track
>>>> > Created: 2017-02-02
>>>> > License: BSD-2
>>>> > Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an
>>>> example, don’t
>>>> > send to this!)
>>>> >
>>>> > Abstract
>>>> > Community Consensus Voting System (CCVS) will allow developers to
>>>> measure
>>>> > support for BIPs prior to implementation.
>>>> >
>>>> > Motivation
>>>> > We currently have no way of measuring consensus for potential changes
>>>> to
>>>> > the Bitcoin protocol. This is especially problematic for controversial
>>>> > changes such as the max block size limit. As a result, we have many
>>>> > proposed solutions but no clear direction.
>>>> >
>>>> > Also, due to our lack of ability to measure consensus, there is a
>>>> general
>>>> > feeling among many in the community that developers aren’t listening
>>>> to
>>>> > their concerns. This is a valid complaint, as it’s not possible to
>>>> listen
>>>> > to thousands of voices all shouting different things in a crowded
>>>> > room—basically the situation in the Bitcoin community today.
>>>> >
>>>> > The CCVS will allow the general public, miners, companies using
>>>> Bitcoin,
>>>> > and developers to vote for their preferred BIP in a way that’s public
>>>> and
>>>> > relatively difficult (expensive) to manipulate.
>>>> >
>>>> > Specification
>>>> > Each competing BIP will be assigned a unique bitcoin address which is
>>>> added
>>>> > to each header. Anyone who wanted to vote would cast their ballot by
>>>> > sending a small amount (0.0001 btc) to their preferred BIP's address.
>>>> Each
>>>> > transaction counts as 1 vote.
>>>> >
>>>> > Confirmed Vote Multiplier:
>>>> > Mining Pools, companies using Bitcoin, and Core
>>>> maintainers/contributors
>>>> > are allowed one confirmed vote each. A confirmed vote is worth
>>>> 10,000x a
>>>> > regular vote.
>>>> >
>>>> > For example:
>>>> >
>>>> > Slush Pool casts a vote for their preferred BIP and then states
>>>> publicly
>>>> > (on their blog) their vote and the transaction ID and emails the URL
>>>> to the
>>>> > admin of this system. In the final tally, this vote will count as
>>>> 10,000
>>>> > votes.
>>>> >
>>>> > Coinbase, Antpool, BitPay, BitFury, etc., all do the same.
>>>> >
>>>> > Confirmed votes would be added to a new section in each respective
>>>> BIP as a
>>>> > public record.
>>>> >
>>>> > Voting would run for a pre-defined period, ending when a particular
>>>> block
>>>> > number is mined.
>>>> >
>>>> >
>>>> > Rationale
>>>> > Confirmed Vote Multiplier - The purpose of this is twofold; it gives a
>>>> > larger voice to organizations and the people who will have to do the
>>>> work
>>>> > to implement whatever BIP the community prefers, and it will negate
>>>> the
>>>> > effect of anyone trying to skew the results by voting repeatedly.
>>>> >
>>>> > Definitions
>>>> > Miner: any individual or organization that has mined at least one
>>>> valid
>>>> > block in the last 2016 blocks.
>>>> >
>>>> > Company using Bitcoin: any organization using Bitcoin for financial,
>>>> asset
>>>> > or other purposes, with either under development and released
>>>> solutions.
>>>> >
>>>> > Developer: any individual who has or had commit access, and any
>>>> individual
>>>> > who has authored a BIP
>>>> >
>>>> > Unresolved Issues
>>>> > Node voting: It would be desirable for any full node running an
>>>> up-to-date
>>>> > blockchain to also be able to vote with a multiplier (e.g. 100x). But
>>>> as
>>>> > this would require code changes, it is outside the scope of this BIP.
>>>> >
>>>> > Copyright
>>>> > This BIP is licensed under the BSD 2-clause license.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>>
>>> --
>>> I like to provide some work at no charge to prove my value. Do you need
>>> a techie?
>>> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
>>> <http://www.memeracing.net> (in alpha).
>>> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
>>> which now accepts Bitcoin.
>>> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
>>> "He ought to find it more profitable to play by the rules" - Satoshi
>>> Nakamoto
>>>
>>> _______________________________________________
>>> 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/20170203/6273c7f4/attachment-0001.html>

2023-06-07 17:55:55

- reply

📅 Original date posted:2017-02-03
📝 Original message:This proposal seems hopelessly broken.
Who decides on which companies are eligible? Is there some kind of
centralized database that one registers? Who administers this? What is to
stop someone from creating a million fake companies to sway the voting?
How does a company make it's vote? How does one verify that the person
voting on behalf of a company is actually the correct person?
On Thu, Feb 2, 2017 at 7:32 PM, Dave Scotese via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There are two ideas here for "on-chain" voting, both of which require
> changes to the software. I agree with David that on-chain solutions
> complicate things. Both proposals can be effected without any software
> changes:
>
> Those who wish to use proof of stake can provide a service for making
> vanity addresses containing some indicator of the proposal to be supported
> - 1bigblock or 12mbblk or whatever - based on a supporter-provided secret
> key, and then supporters can move their bitcoin into their own vanity
> address and then whoever wants to can create a website to display the
> matching addresses and explain that this is the financial power in the
> hands of supporters and how to add your "financial power vote."
>
> Those who simply want to "buy votes" can use their funds in marketing
> efforts to promote the proposal they support.
>
> This second method, of course, can be abused. The first actually requires
> people to control bitcoin in order to represent support. Counting actual,
> real people is still a technology in its infancy, and I don't think I want
> to see it progress much. People are not units, but individuals, and their
> value only becomes correlated to their net worth after they've been alive
> for many years, and even then, some of the best people have died paupers.
> If bitcoin-discuss got more traffic, I think this discussion would be
> better had on that list.
>
> notplato
>
> On Thu, Feb 2, 2017 at 4:24 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Strongly disagree with buying "votes", or portraying open standards as a
>> voting process. Also, this depends on address reuse, so it's fundamentally
>> flawed in design.
>>
>> Some way for people to express their support weighed by coins (without
>> losing/spending them), and possibly weighed by running a full node, might
>> still be desirable. The most straightforward way to do this is to support
>> message signatures somehow (ideally without using the same pubkey as
>> spending), and some [inherently unreliable, but perhaps useful if the
>> community "colludes" to not-cheat] way to sign with ones' full node.
>>
>> Note also that the BIP process already has BIP Comments for leaving
>> textual
>> opinions on the BIP unrelated to stake. See BIP 2 for details on that.
>>
>> Luke
>>
>>
>> On Thursday, February 02, 2017 7:39:51 PM t. khan via bitcoin-dev wrote:
>> > Please comment on this work-in-progress BIP.
>> >
>> > Thanks,
>> >
>> > - t.k.
>> >
>> > ----------------------
>> > BIP: ?
>> > Layer: Process
>> > Title: Community Consensus Voting System
>> > Author: t.khan <teekhan42 at gmail.com>
>> > Comments-Summary: No comments yet.
>> > Comments-URI: TBD
>> > Status: Draft
>> > Type: Standards Track
>> > Created: 2017-02-02
>> > License: BSD-2
>> > Voting Address: 3CoFA3JiK5wxe9ze2HoDGDTmZvkE5Uuwh8 (just an example,
>> don’t
>> > send to this!)
>> >
>> > Abstract
>> > Community Consensus Voting System (CCVS) will allow developers to
>> measure
>> > support for BIPs prior to implementation.
>> >
>> > Motivation
>> > We currently have no way of measuring consensus for potential changes to
>> > the Bitcoin protocol. This is especially problematic for controversial
>> > changes such as the max block size limit. As a result, we have many
>> > proposed solutions but no clear direction.
>> >
>> > Also, due to our lack of ability to measure consensus, there is a
>> general
>> > feeling among many in the community that developers aren’t listening to
>> > their concerns. This is a valid complaint, as it’s not possible to
>> listen
>> > to thousands of voices all shouting different things in a crowded
>> > room—basically the situation in the Bitcoin community today.
>> >
>> > The CCVS will allow the general public, miners, companies using Bitcoin,
>> > and developers to vote for their preferred BIP in a way that’s public
>> and
>> > relatively difficult (expensive) to manipulate.
>> >
>> > Specification
>> > Each competing BIP will be assigned a unique bitcoin address which is
>> added
>> > to each header. Anyone who wanted to vote would cast their ballot by
>> > sending a small amount (0.0001 btc) to their preferred BIP's address.
>> Each
>> > transaction counts as 1 vote.
>> >
>> > Confirmed Vote Multiplier:
>> > Mining Pools, companies using Bitcoin, and Core maintainers/contributors
>> > are allowed one confirmed vote each. A confirmed vote is worth 10,000x a
>> > regular vote.
>> >
>> > For example:
>> >
>> > Slush Pool casts a vote for their preferred BIP and then states publicly
>> > (on their blog) their vote and the transaction ID and emails the URL to
>> the
>> > admin of this system. In the final tally, this vote will count as 10,000
>> > votes.
>> >
>> > Coinbase, Antpool, BitPay, BitFury, etc., all do the same.
>> >
>> > Confirmed votes would be added to a new section in each respective BIP
>> as a
>> > public record.
>> >
>> > Voting would run for a pre-defined period, ending when a particular
>> block
>> > number is mined.
>> >
>> >
>> > Rationale
>> > Confirmed Vote Multiplier - The purpose of this is twofold; it gives a
>> > larger voice to organizations and the people who will have to do the
>> work
>> > to implement whatever BIP the community prefers, and it will negate the
>> > effect of anyone trying to skew the results by voting repeatedly.
>> >
>> > Definitions
>> > Miner: any individual or organization that has mined at least one valid
>> > block in the last 2016 blocks.
>> >
>> > Company using Bitcoin: any organization using Bitcoin for financial,
>> asset
>> > or other purposes, with either under development and released solutions.
>> >
>> > Developer: any individual who has or had commit access, and any
>> individual
>> > who has authored a BIP
>> >
>> > Unresolved Issues
>> > Node voting: It would be desirable for any full node running an
>> up-to-date
>> > blockchain to also be able to vote with a multiplier (e.g. 100x). But as
>> > this would require code changes, it is outside the scope of this BIP.
>> >
>> > Copyright
>> > This BIP is licensed under the BSD 2-clause license.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> 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/20170203/1e9eea61/attachment.html>