Return-Path: <jeanpaulkogelman@me.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D041C414 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 30 Jul 2015 04:07:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 718787C for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 30 Jul 2015 04:07:38 +0000 (UTC) Received: from [10.0.1.9] (S0106b8c75dcca39e.vc.shawcable.net [24.84.203.85]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NSA015P98SMN000@st11p02im-asmtp001.me.com> for bitcoin-dev@lists.linuxfoundation.org; Thu, 30 Jul 2015 04:07:37 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-30_03:2015-07-29, 2015-07-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1507300074 Content-type: multipart/alternative; boundary=Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74 MIME-version: 1.0 (1.0) From: Jean-Paul Kogelman <jeanpaulkogelman@me.com> X-Mailer: iPhone Mail (12H143) In-reply-to: <CAF_2MyVAXg9788gatEQ-t4=8rJxXdkf9DA45uF5_gksDUM6b=A@mail.gmail.com> Date: Wed, 29 Jul 2015 21:07:33 -0700 Content-transfer-encoding: 7bit Message-id: <A03FDB78-074B-4334-B56A-71593F4D7985@me.com> References: <CADZB0_ZgDMhVgCUh2PTAPDL7k_W8QGt_HLYdkwv_qQ5xEMn8HA@mail.gmail.com> <543015348.4948849.1438178962054.JavaMail.yahoo@mail.yahoo.com> <COL131-DS3F7339BCCA36BEFD1755ACD8C0@phx.gbl> <55B959A2.9020402@sky-ip.org> <CAF_2MyVAXg9788gatEQ-t4=8rJxXdkf9DA45uF5_gksDUM6b=A@mail.gmail.com> To: Ryan Butler <rryananizer@gmail.com> X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "bitcoin-dev@lists.linuxfoundation.org" <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] =?utf-8?q?R=C4=83spuns=3A_Personal_opinion_on_the_f?= =?utf-8?q?ee_market_from_a_worried_local_trader?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Thu, 30 Jul 2015 04:07:39 -0000 --Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jul 29, 2015, at 8:41 PM, Ryan Butler via bitcoin-dev <bitcoin-dev@list= s.linuxfoundation.org> wrote: >=20 > Does an unlimited blocksize imply the lack of a fee market? Isn't every m= iner able to set their minimum accepted fee or transaction acceptance algori= thm? >=20 Yes, miners can set this, and giving them more fine grained control over thi= s (with sane defaults) will have a far bigger impact on establishing a prope= r fee market than depending on capacity (that nobody has any control over).=20= Allowing miners to set up some sort of tiered offering that delays transacti= ons and maybe even have their tiers tie into the exchange rate to keep the c= osts constant over time. I'm sure something like this has probably already been discussed before and I= 'm curious what the objections are to such a thing? jp= --Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div><br></div><div><br>On Jul 29, 2015, at= 8:41 PM, Ryan Butler via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@list= s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<= br><br></div><blockquote type=3D"cite"><div><p dir=3D"ltr">Does an unlimited= blocksize imply the lack of a fee market? Isn't every miner able to s= et their minimum accepted fee or transaction acceptance algorithm?</p></div>= </blockquote><br><div>Yes, miners can set this, and giving them more fine gr= ained control over this (with sane defaults) will have a far bigger impact o= n establishing a proper fee market than depending on capacity (that nobody h= as any control over). </div><div><br></div><div>Allowing miners to set u= p some sort of tiered offering that delays transactions and maybe even have t= heir tiers tie into the exchange rate to keep the costs constant over time.<= /div><div><br></div><div>I'm sure something like this has probably already b= een discussed before and I'm curious what the objections are to such a thing= ?</div><div><br></div><div>jp</div></body></html>= --Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74--