From: John Dillon <john.dillon892@googlemail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
Date: Fri, 28 Jun 2013 10:25:28 +0000 [thread overview]
Message-ID: <CAPaL=UUYOQQiLO4pn_83_VRihebq-n3892pxpar2mH_9fXYh0w@mail.gmail.com> (raw)
In-Reply-To: <CAKaEYhL2YY6wWnUYJuwWo2czHq7hRiYsQouR1B64oE31ZEochg@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> Thinking about this a little more, I guess it does not hurt to build some
> kind of voting system into the clients. But I think it's more useful for
> straw polls. For example a bug fix 100% of people should agree on. A
> protocol optimization perhaps 80% would agree on. A protocol change that
> redistributes wealth or incentives perhaps only 60% will agree on.
>
> At this point in time it's far too easy to deliver contentious changes into
> the hands of the general population. I think that fortunately we're blessed
> with a very strong dev team, but the fundamental philosophy of bitcoin is to
> not put too much trust in single point, but rather, to distribute and
> diversify trust to the edges.
I disagree entirely. Your example of "straw polls" for bug fixes and
features is precisely what the current method of rough consensus and
running code, an IETF expression, handles just fine.
What the method does not handle effectively are issues that are
fundementally political rather than technical in nature. Blocksize is
precisely the latter because while the tradeoffs are technical in
nature the fundemental issue at hand is what do we want Bitcoin to be?
Who are we going to allow to participate?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJRzWR7AAoJEEWCsU4mNhiPEYsIAME+VvS4vfE0PdOMv3vHWGSH
HwUJdtKPold4+p0jhPBKSMbgnpMvXsZezMIIxj8xehnblnVuUdyakibXAdgVNLvp
a6SCw+W/VnopYCw151zZ4FQS92KQuSbX+XmYTQy32oqZIXtBmTE1fydw5q6YhoXb
gCCygPRyLTIQxLZAxqqRrQ0nsSE5ID5kDcr+xRsmCvfIKrzoOCbYL+nXPCB4Zzgu
Gs7Lfa0yfTrUlQmoDseyoWrVuhfYuFNesTAs3z6imMTdHqZh8Z+a+gmC+G9qFO1h
y7hOmzW4oz7hH4R2F6M+UpV6rKdwMaNYwrDw5eHClDgGYNfjjVduQ/YMQnbjyAc=
=5mhd
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2013-06-28 10:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 4:09 [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting John Dillon
[not found] ` <CAFBxzACPpLd1gmoAzxviU2rLPry=cGNQhEZvYV=q_PLRQQ5wXw@mail.gmail.com>
2013-06-10 4:59 ` John Dillon
2013-06-10 5:30 ` Peter Todd
2013-06-10 6:34 ` Daniel Lidstrom
2013-06-10 8:14 ` Melvin Carvalho
2013-06-10 8:26 ` John Dillon
2013-06-10 8:39 ` Melvin Carvalho
2013-06-10 8:35 ` Pieter Wuille
2013-06-10 12:30 ` Melvin Carvalho
2013-06-10 16:46 ` Mark Friedenbach
2013-06-10 17:25 ` Alan Reiner
2013-06-10 17:43 ` Peter Todd
2013-06-15 18:28 ` John Dillon
2013-06-22 12:05 ` Melvin Carvalho
2013-06-28 10:25 ` John Dillon [this message]
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='CAPaL=UUYOQQiLO4pn_83_VRihebq-n3892pxpar2mH_9fXYh0w@mail.gmail.com' \
--to=john.dillon892@googlemail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=melvincarvalho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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