From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4FwL-0002yp-D2 for bitcoin-development@lists.sourceforge.net; Sun, 14 Jun 2015 21:59:41 +0000 Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z4FwK-0007es-06 for bitcoin-development@lists.sourceforge.net; Sun, 14 Jun 2015 21:59:41 +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 481F640D42 for ; Sun, 14 Jun 2015 21:59:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 0348842001 Message-ID: <557DF945.1060909@riseup.net> Date: Sun, 14 Jun 2015 14:59:33 -0700 From: odinn 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: <20150612181153.GB19199@muck> <3BB36FC7-9212-42A1-A756-A66929C15D4F@gmail.com> <04527D50-0118-4E74-8226-3E29B29CC7D8@gmail.com> <557D5239.1070105@henricson.se> In-Reply-To: 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.7 (-) 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 SPF_PASS SPF: sender matches SPF record -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 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: 1Z4FwK-0007es-06 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 21:59:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Notionally, I agree with what I see written here by Jeff, and I appreciate the thoughtfulness that went into this short post to list. On 06/14/2015 08:07 AM, Jeff Garzik wrote: > Exactly -- both block size proponents and block size change=20 > conservatives seem to be glossing over this aspect - much to my=20 > dismay. >=20 > Choosing the size limit is choosing the size of a scarce resource.=20 > By fiat. >=20 > It is wrong to think that a "technical consensus" can choose what=20 > is best here. >=20 > The block size limit defines the scope of a resource for which all=20 > fee market actors bid. That, in turn, defines who is in the fee=20 > market and how they behave, what market choices are made. >=20 > It doesn't matter how or why the limit was originally enacted, what > Satoshi meant to do. What matters, economically, is what is. What > the software and our $3B economy & market knows and sees today. (I > think some block size change proponents miss this!) >=20 > The solution lies in transitioning this size limit to the free=20 > market. In the end, the users must choose their desired level of=20 > growth, decentralization, etc. We cannot rely on some dev's idea=20 > of the proper level of fee, proper level of growth, proper level > of decentralization. >=20 > And IMO, a "floating limit with training wheels" is better and=20 > stronger for bitcoin's health from a governance, user choice and=20 > free market perspective than simply "hard fork to 2MB, come back=20 > again in 6 months." >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Sun, Jun 14, 2015 at 6:34 AM, Benjamin=20 > >=20 > wrote: >=20 > "The size limit is an economic policy lever that needs to be=20 > transitioned -away- from software and software developers, to the=20 > free market." >=20 > Exactly right. Bitcoin does not have a free market for fee though,=20 > and literally all the discussion so far has neglected some=20 > fundamental aspect of this, as you described. It's not at all a=20 > "technical" or "engineering" decision. It's the question of how to=20 > potentially re-design a fundamental part of Bitcoin, and the=20 > proposals so far don't address this. What is the price of the=20 > scarce resource of the blockchain and the mechanism to decide on=20 > price, once the subsidy runs out? >=20 > On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson > wrote: >> Jeff, >>=20 >> with all due respect, but I've seen you saying this a few times=20 >> now, that this decision is oh so difficult and important. >>=20 >> But this is not helpful. We all know that. Even I. >>=20 >> Make a suggestion, or stay out of the debate! >>=20 >> Mats >>=20 >> On 06/14/2015 07:36 AM, Jeff Garzik wrote: >>> The choice is very real and on-point. What should the block=20 >>> size > limit >>> be? Why? >>>=20 >>> There is a large consensus that it needs increasing. To what? >>>=20 > By what >>> factor? >>>=20 >>> The size limit literally defines the fee market, the whole=20 >>> damn > thing. If >>> software high priests choose a size limit of 300k, space is > scarce, fees >>> are bid high. If software high priests choose a size limit of > 32mb, space >>> is plentiful, fees are near zero. Market actors take their=20 >>> signals accordingly. Some business models boom, some business=20 >>> models > fail, as a >>> direct result of changing this unintentionally-added >>> speedbump. >>>=20 > Different >>> users value adoption, decentralization etc. differently. >>>=20 >>> The size limit is an economic policy lever that needs to be > transitioned >>> -away- from software and software developers, to the free=20 >>> market. >>>=20 >>> A simple, e.g. hard fork to 2MB or 4MB does not fix higher=20 >>> level > governance >>> problems associated with actors lobbying developers, even if a > cloistered >>> and vetted Technical Advisory Board as has been proposed. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo > > wrote: >>>=20 >>>> I definitely think we need some voting system for > metaconsensus=85but if >>>> we=92re going to seriously consider this we should look at the > problem much >>>> more generally. Using false choices doesn=92t really help,=20 >>>> though ;) >>>>=20 >>>> - Eric Lombrozo >>>>=20 >>>>=20 >>>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik=20 >>>> > wrote: >>>>=20 >>>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo > > >>>> wrote: >>>>=20 >>>>> 2) BIP100 has direct economic consequences=85and >>>>> particularly for > miners. >>>>> It lends itself to much greater corruptibility. >>>>>=20 >>>>>=20 >>>> What is the alternative? Have a Chief Scientist or=20 >>>> Technical > Advisory >>>> Board choose what is a proper fee, what is a proper level of >>>> decentralization, a proper growth factor? >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 > ---------------------------------------------------------------------- - -------- > > >=20 >>=20 >>>=20 >>>=20 >>> _______________________________________________=20 >>> Bitcoin-development mailing list=20 >>> Bitcoin-development@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >>> >>>=20 >>=20 >>=20 >>=20 > ---------------------------------------------------------------------- - -------- > > >=20 _______________________________________________ >> Bitcoin-development mailing list=20 >> Bitcoin-development@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 > ---------------------------------------------------------------------- - -------- > > >=20 _______________________________________________ > Bitcoin-development mailing list=20 > Bitcoin-development@lists.sourceforge.net=20 > =20 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 >=20 >=20 >=20 > -- Jeff Garzik Bitcoin core developer and open source evangelist=20 > BitPay, Inc. https://bitpay.com/ >=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 iQEcBAEBAgAGBQJVfflFAAoJEGxwq/inSG8CrWoIAJOsZHTWqdILE0IYmmE50E/S BcbPJJtjodw1liPVJEybyNUKSgq4Ucw9tuQpMVv3hF8bvug6/6HtxAQCptuIKRSw WigZyvgm79u474YsPULG+2SltMrOFqmA05jTF9vWo0LBSY4xiMXjT4VwVt9xEcFc qHW5OUa1QoFZkaOf/jtY+H3a9w8cHZFlroTkf4MaJkaMo81oSRfWz3Mj8wOz6f8z MSEpvQERzETEcV0SqTBnzsoX8toO1s24a9HejMMfbeD7JAy8EvayFb3G1LNzBNVC 1x/yeLBGnE3Z0P80J0oUR5taLbGJl9+7Hb16rEzxivtZF5FWBdDmvwKBOKJ1Alo=3D =3DubcH -----END PGP SIGNATURE-----