Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 834E5475 for ; Fri, 24 Jul 2015 00:23:00 +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 B12E11BF for ; Fri, 24 Jul 2015 00:22:59 +0000 (UTC) Received: from [10.52.6.2] (unknown [101.78.135.131]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NRY01A6AUE7AK30@st11p02im-asmtp001.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 24 Jul 2015 00:22:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-07-24_01:2015-07-22, 2015-07-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1507230316 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and wrapped. Content-type: multipart/alternative; boundary=Apple-Mail-9D7A1662-194B-4B9A-BD30-8E49B7424FDB MIME-version: 1.0 (1.0) From: Jean-Paul Kogelman X-Mailer: iPhone Mail (12H143) In-reply-to: Date: Fri, 24 Jul 2015 08:22:53 +0800 Content-transfer-encoding: 7bit Message-id: <346D4CE0-E00D-4ABB-B131-EFA1416CB20C@me.com> References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai> To: Eric Lombrozo X-Spam-Status: No, score=-3.8 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" Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 00:23:00 -0000 --Apple-Mail-9D7A1662-194B-4B9A-BD30-8E49B7424FDB Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable You are not going to get a fair fee market if your only form of enforcement i= s the threat of exclusion. A more fair fee market will develop if miners start offering quality of serv= ice, preferably at multiple tiers. At that point any interference from a blo= ck size cap will only be detrimental. In fact it will only highlight what th= e cap is actually for; to prevent monster blocks.=20 Add better QoS tools for miners and extend the cap (when possible) and there= 's your fee market. jp > On Jul 24, 2015, at 8:04 AM, Eric Lombrozo via bitcoin-dev wrote: >=20 > I should also add that I think those who claim that fee pressure will scar= e away users and break the industry are *seriously* underestimating human in= genuity in the face of a challenge. We can do this - we can overcome this ob= stacle=A1=ADwe can find good solutions to a fee market. Unless someone can c= ome up with another way to pay for the operation of the network, we NEED to d= o this. What makes anyone think it will be easier to do later rather than no= w? The longer we wait, the lower block rewards get, the larger the deployed i= nfrastructure, the larger our userbase, the HARDER it will be to solve it. W= e should solve it now - we will be much better off for it=A1=ADand so will o= ur users. >=20 >=20 >>> On Jul 23, 2015, at 4:57 PM, Eric Lombrozo wrote: >>>=20 >>>=20 >>> On Jul 23, 2015, at 4:42 PM, Benedict Chan wrote= : >>>=20 >>> Scaling the network will come in the form of a combination of many >>> optimizations. Just because we do not know for sure how to eventually >>> serve 7 billion people does not mean we should make decisions on >>> global validation that impact our ability to serve the current set of >>> users. >>=20 >> Agreed. But I believe the economic and security arguments I gave regardin= g fees and incentives still hold and are largely separate from the scalabili= ty issue. Please correct me if I overlooked something. >>=20 >>=20 >>> Also, blocking a change because it's "more important to address issues >>> such as..." other improvements will further slow down the discussion. >>> I believe an increase will not prevent the development of other >>> improvements that we need - in contrast, the sooner we can get over >>> the limit (which, as you agree, needs to be changed at some point), >>> the sooner we can get back to work. >>=20 >> An increase in block size at this time will exacerbate security concerns a= round nodes relying on other nodes to validate (particularly miners and wall= ets). It=A1=AFs not really a matter of having limited developer resources th= at need to be budgeted, as you seem to suggest. >>=20 >> Regarding developments on properly handling fees, there must exist the ec= onomic need for it before there=A1=AFs an earnest effort to solve it. Increa= sing the block size right now will, in all likelihood, delay this effort. I=A1= =AFd much prefer to first let the fee market evolve because it=A1=AFs a cruc= ial component to the protocol=A1=AFs design and its security model=A1=ADand s= o we can get a better sense for fee economics. Then we might be able to figu= re out better approaches to block size changes in the future that makes sens= e economically=A1=ADperhaps with mechanisms that can dynamically adjust it t= o reflect resource availability and network load. >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-9D7A1662-194B-4B9A-BD30-8E49B7424FDB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You are not going to get a fair fee ma= rket if your only form of enforcement is the threat of exclusion.

A m= ore fair fee market will develop if miners start offering quality of service= , preferably at multiple tiers. At that point any interference from a block s= ize cap will only be detrimental. In fact it will only highlight what the ca= p is actually for; to prevent monster blocks. 

Add better QoS tools for miners and extend the cap (when possible) and ther= e's your fee market.

jp


On Ju= l 24, 2015, at 8:04 AM, Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:

I should also add th= at I think those who claim that fee pressure will scare away users and break= the industry are *seriously* underestimating human ingenuity in the face of= a challenge. We can do this - we can overcome this obstacle=E2=80=A6we can f= ind good solutions to a fee market. Unless someone can come up with another w= ay to pay for the operation of the network, we NEED to do this. What makes a= nyone think it will be easier to do later rather than now? The longer we wai= t, the lower block rewards get, the larger the deployed infrastructure, the l= arger our userbase, the HARDER it will be to solve it. We should solve it no= w - we will be much better off for it=E2=80=A6and so will our users.


On Jul 23, 2015, at 4:57 PM, Eric L= ombrozo <elombrozo@gmai= l.com> wrote:


On Jul 23, 2015, at 4= :42 PM, Benedict Chan <bencxr@fragnetics.com> wrote:

Scaling the network will come in the form of a combinat= ion of many
optimizations. Just because we d= o not know for sure how to eventually
serve= 7 billion people does not mean we should make decisions on
global validation that impact our ability to serve the current s= et of
users.

Agreed. But I b= elieve the economic and security arguments I gave regarding fees and incenti= ves still hold and are largely separate from the scalability issue. Please c= orrect me if I overlooked something.

Also, blocking a change because it's "more important to address issue= s
such as..." other improvements will furth= er slow down the discussion.
I believe an increa= se will not prevent the development of other
= improvements that we need - in contrast, the sooner we can get overthe limit (which, as you agree, needs to be changed a= t some point),
the sooner we can get back t= o work.

An increase in block size at this time will exacerbat= e security concerns around nodes relying on other nodes to validate (particu= larly miners and wallets). It=E2=80=99s not really a matter of having limite= d developer resources that need to be budgeted, as you seem to suggest.

Regarding developments= on properly handling fees, there must exist the economic need for it before= there=E2=80=99s an earnest effort to solve it. Increasing the block size ri= ght now will, in all likelihood, delay this effort. I=E2=80=99d much prefer t= o first let the fee market evolve because it=E2=80=99s a crucial component t= o the protocol=E2=80=99s design and its security model=E2=80=A6and so we can= get a better sense for fee economics. Then we might be able to figure out b= etter approaches to block size changes in the future that makes sense econom= ically=E2=80=A6perhaps with mechanisms that can dynamically adjust it to ref= lect resource availability and network load.
<= /div>
= _______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
htt= ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-9D7A1662-194B-4B9A-BD30-8E49B7424FDB--