From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E53F25A7 for ; Fri, 24 Jul 2015 00:49:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from st11p02im-asmtp002.me.com (st11p02im-asmtp002.me.com [17.172.220.114]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 264B9149 for ; Fri, 24 Jul 2015 00:49:25 +0000 (UTC) Received: from [10.52.6.2] (unknown [101.78.135.131]) by st11p02im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NRY011JSVM96B40@st11p02im-asmtp002.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 24 Jul 2015 00:49:24 +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-1507240006 Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and wrapped. Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (1.0) From: Jean-Paul Kogelman X-Mailer: iPhone Mail (12H143) In-reply-to: <55FFBC8F-A3C9-4109-89C7-AC359FBBD478@me.com> Date: Fri, 24 Jul 2015 08:49:20 +0800 Content-transfer-encoding: quoted-printable Message-id: <4734381C-2000-4D9B-9099-DDE3D38D64A3@me.com> References: <55B113AF.40500@thinlink.com> <6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com> <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai> <346D4CE0-E00D-4ABB-B131-EFA1416CB20C@me.com> <29363BE6-72A7-4D06-A974-C52BA12FD8BD@gmail.com> <55FFBC8F-A3C9-4109-89C7-AC359FBBD478@me.com> To: Jean-Paul Kogelman X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,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:49:29 -0000 And it's obvious how a size cap would interfere with such a QoS scheme. Mine= rs wouldn't be able to deliver the below guarantees if they have to start ex= cluding transactions. > On Jul 24, 2015, at 8:45 AM, Jean-Paul Kogelman via bitcoin-dev wrote: >=20 > Quality of service as in: >=20 >> X satoshi / kb =3D included in block currently worked on; >=20 >> Y satoshi / kb =3D included in next block; >=20 >> Z satoshi / kb =3D included in block after that, etc. >=20 > Block count starts when transaction is first seen. Miners can set X, Y, Z.= =20 >=20 > Market develops when miners start setting different values and adding more= transactions to blocks as opposed to other miners with higher settings.=20 >=20 > It basically comes down to the miners themselves if they want a healthy fe= e market. If they stick to their guns, their influence on the fees will be p= roportional to their hashing power. >=20 > jp >=20 >> On Jul 24, 2015, at 8:32 AM, Eric Lombrozo wrote: >>=20 >>=20 >>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman wrote: >>>=20 >>> You are not going to get a fair fee market if your only form of enforcem= ent is the threat of exclusion. >>>=20 >>> A more fair fee market will develop if miners start offering quality of s= ervice, preferably at multiple tiers. At that point any interference from a b= lock size cap will only be detrimental. In fact it will only highlight what t= he cap is actually for; to prevent monster blocks. >>>=20 >>> Add better QoS tools for miners and extend the cap (when possible) and t= here's your fee market. >>>=20 >>> jp >>=20 >> Not sure what you mean by QoS here. Either your transaction is included o= r it isn=A1=AFt. It=A1=AFs not like you can upgrade to a master suite with a= view or anything. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev