diff options
| author | odinn <odinn.cyberguerrilla@riseup.net> | 2015-06-13 21:28:36 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-14 04:28:46 +0000 |
| commit | dc7fe1e7fd1e6bf0288c3a283b18a16e0777187f (patch) | |
| tree | 1110849e5714c26ae4fa6a2cfeb565486fc8a4d0 | |
| parent | 435c1b9bff5307be65dcc1a36e8d31c87e99cc74 (diff) | |
| download | pi-bitcoindev-dc7fe1e7fd1e6bf0288c3a283b18a16e0777187f.tar.gz pi-bitcoindev-dc7fe1e7fd1e6bf0288c3a283b18a16e0777187f.zip | |
Re: [Bitcoin-development] User vote in blocksize through fees
| -rw-r--r-- | 82/1b2b233294aec2917aed776ea8a13500717551 | 221 |
1 files changed, 221 insertions, 0 deletions
diff --git a/82/1b2b233294aec2917aed776ea8a13500717551 b/82/1b2b233294aec2917aed776ea8a13500717551 new file mode 100644 index 000000000..e1b8b82bf --- /dev/null +++ b/82/1b2b233294aec2917aed776ea8a13500717551 @@ -0,0 +1,221 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <odinn.cyberguerrilla@riseup.net>) id 1Z3zXK-0001bw-Lx + for bitcoin-development@lists.sourceforge.net; + Sun, 14 Jun 2015 04:28:46 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net + designates 198.252.153.129 as permitted sender) + client-ip=198.252.153.129; + envelope-from=odinn.cyberguerrilla@riseup.net; + helo=mx1.riseup.net; +Received: from mx1.riseup.net ([198.252.153.129]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1Z3zXI-0006uG-3n + for bitcoin-development@lists.sourceforge.net; + Sun, 14 Jun 2015 04:28:46 +0000 +Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) + (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) + (Client CN "*.riseup.net", + Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) + by mx1.riseup.net (Postfix) with ESMTPS id 4026E41D06 + for <bitcoin-development@lists.sourceforge.net>; + Sun, 14 Jun 2015 04:28:38 +0000 (UTC) +Received: from [127.0.0.1] (localhost [127.0.0.1]) + (Authenticated sender: odinn.cyberguerrilla) + with ESMTPSA id ED842400F6 +Message-ID: <557D02F4.7090001@riseup.net> +Date: Sat, 13 Jun 2015 21:28:36 -0700 +From: odinn <odinn.cyberguerrilla@riseup.net> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:31.0) Gecko/20100101 Thunderbird/31.7.0 +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net +References: <COL402-EAS423BB81E15B25CD20B11B10CDBA0@phx.gbl> +In-Reply-To: <COL402-EAS423BB81E15B25CD20B11B10CDBA0@phx.gbl> +Content-Type: text/plain; charset=windows-1252 +X-Virus-Scanned: clamav-milter 0.98.7 at mx1 +X-Virus-Status: Clean +Content-Transfer-Encoding: quoted-printable +X-Spam-Score: -1.5 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, + no trust [198.252.153.129 listed in list.dnswl.org] + -0.0 SPF_HELO_PASS SPF: HELO matches SPF record + -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain + -0.0 SPF_PASS SPF: sender matches SPF record + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid + 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay + lines + -0.1 AWL AWL: Adjusted score from AWL reputation of From: address +X-Headers-End: 1Z3zXI-0006uG-3n +Subject: Re: [Bitcoin-development] User vote in blocksize through fees +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Sun, 14 Jun 2015 04:28:46 -0000 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +A decentralized, distributed application should offer its users +decentralized, distributed method of weighing in on the direction of +how it evolves as well as having an open development model. The +reference to Facebook and Myspace is completely inapplicable here +because the tyranny of such spaces isn't what we have with bitcoin +(fortunately), nor would we want to try to replicate it, ever, in any +way, shape, or form. + +Yes, it does bother (some) people to see the consensus based system +because of the difficulties that can be associated with implementing +it. But that's the way it is. If you don't like consensus based +systems (or decentralized, distributed systems) this is probably the +wrong space for you. + +On 06/13/2015 04:57 PM, Raystonn wrote: +> Adding back the list. Did not intend to remove it. Apologies. +>=20 +> On 13 Jun 2015 4:52 pm, Raystonn <raystonn@hotmail.com> wrote: +>=20 +> Based on my observations, what the majority of Bitcoin users want=20 +> is a system that can carry more transactions per second than any=20 +> existing payment system while retaining most of the security=20 +> offered today. The technicalities on how this is achieved are not=20 +> as important as the end result. If the only user input is to=20 +> technicalities, they will use that to voice their opinions. +>=20 +> On 13 Jun 2015 4:25 pm, Danny Thorpe <danny.thorpe@gmail.com>=20 +> wrote: +>=20 +> I don't recall Facebook or MySpace asking end users to alter the=20 +> parameters of their respective back-end network infrastructure. +>=20 +> How are Bitcoin end users qualified to make an informed decision=20 +> regarding block size limits? And why should they care? +>=20 +> Sure, I want Bitcoin to grow its user base. But to do that, +> Bitcoin has to be accessible to the nontechnical population. +> Asking nontechnical people to make technical decisions leads +> directly to stress and confusion, which most folks find +> off-putting. +>=20 +> And please don't call me Shirley. ;> +>=20 +> On Sat, Jun 13, 2015 at 3:42 PM, Raystonn <raystonn@hotmail.com=20 +> <mailto:raystonn@hotmail.com>> wrote: +>=20 +> Surely you would prefer to actually have users? Bitcoin does not=20 +> exist in a vacuum. Network effect alone is not enough to ensure=20 +> success in the face of competition from alternatives with a much=20 +> better user experience. See Facebook vs MySpace, IE vs Netscape,=20 +> etc. +>=20 +> On 13 Jun 2015 3:20 pm, Danny Thorpe <danny.thorpe@gmail.com=20 +> <mailto:danny.thorpe@gmail.com>> wrote: +>=20 +> Please forgive my ignorance, but why should Bitcoin users have a=20 +> say in block size limits? It's the miners and Bitcoin node=20 +> operators that bear the burden of managing large blocks, no? +>=20 +> Users voting on network parameters sounds like neighbors voting on=20 +> how deep my swimming pool should be. +>=20 +> Thanks, -Danny +>=20 +> On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete@petertodd.org=20 +> <mailto:pete@petertodd.org>> wrote: +>=20 +> Jeff Garzik recently proposed that the upper blocksize limit be=20 +> removed entirely, with a "soft" limit being enforced via miner=20 +> vote, recorded by hashing power. +>=20 +> This mechanism within the protocol for users to have any influence=20 +> over the miner vote. We can add that back by providing a way for=20 +> transactions themselves to set a flag determining whether or not=20 +> they can be included in a block casting a specific vote. +>=20 +> We can simplify Garzik's vote to say that one of the nVersion bits +> either votes for the blocksize to be increased, or decreased, by=20 +> some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can=20 +> use a nVersion bit in transactions themselves, also voting for an=20 +> increase or decrease. Transactions may only be included in blocks=20 +> with an indentical vote, thus providing miners with a monetary=20 +> incentive via fees to vote according to user wishes. +>=20 +> Of course, to cast a "don't care" vote we can either define an=20 +> additional bit, or sign the transaction with both versions. +> Equally we can even have different versions with different fees, +> broadcast via a mechanism such as replace-by-fee. +>=20 +>=20 +> See also John Dillon's proposal for proof-of-stake blocksize=20 +> voting: +>=20 +> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net +/msg02323.html +> +> +>=20 +- -- 'peter'[:-1]@petertodd.org <http://petertodd.org> +> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 +>=20 +> ---------------------------------------------------------------------- +- -------- +> +> +>=20 +_______________________________________________ +> Bitcoin-development mailing list=20 +> Bitcoin-development@lists.sourceforge.net=20 +> <mailto:Bitcoin-development@lists.sourceforge.net>=20 +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>=20 +>=20 +>=20 +>=20 +>=20 +> ---------------------------------------------------------------------- +- -------- +> +> +>=20 +>=20 +>=20 +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net=20 +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>=20 + +- --=20 +http://abis.io ~ +"a protocol concept to enable decentralization +and expansion of a giving economy, and a new social good" +https://keybase.io/odinn +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQEcBAEBAgAGBQJVfQL0AAoJEGxwq/inSG8CRqMH/0l9tHGA8figVGnIBoMgdpVi +uwMGTQTjLUf12/NFS27vT+OLMWqZRvVXvlxDF25N7la+QImhh67LqmQy8fkwGg5T +kJ6MkkFLgy05aqE/X3ywJUifOKmS3Y/RDDUJhrFjjHrsMGoF4ATtVwTpUBLik+kX +G3XRNlInmyB55UEcpyfBg9kfLz8xiy6sBPeaeGnFLCNWTs5TgJ6DTFqhBAAmE8Hw +k0tN6mW3wYS610FFkS2E3+W8O8KGs4oqAYLX/ZQOhX9oKjBvWWI4ppRpSDyBNcxd +A6VAKyU8HCuDHAEwba6gdlUa+yf4qxuZV1KCNENbvtN1CTsJ6oh0OxnEO6dtogo=3D +=3DKZmG +-----END PGP SIGNATURE----- + + |