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 <jeanpaulkogelman@me.com>
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: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
	<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
	<CADm_WcbnQQGZoQ92twfUvbzqGwu__xLn+BYOkHPZY_YT1pFrbA@mail.gmail.com>
	<CAPWm=eW8RgrG1CMEAMN4GeiMjZecFvNtZB_Y4rZNeofWSD0=Wg@mail.gmail.com>
	<CADm_WcYCUHs9Qe_T6WJOCUSK6stXYD8v6z5JcGHfRMURoOSFTA@mail.gmail.com>
	<CABm2gDq3JyZx0QCRDbcNSLSOBKdpi4h_7VN1XL8N42U38+eBAA@mail.gmail.com>
	<55B113AF.40500@thinlink.com>
	<CABsx9T1MTc-GmuQyFN1vaFK=CDWV_L214Pi9nR6jLMouQQD0fw@mail.gmail.com>
	<C5A70F53-4779-457A-A06A-686877706F89@gmail.com>
	<CADL_X_exckh5T2BfzPEp26fPR3TD69QarwroDEdS_9wtnKbf+g@mail.gmail.com>
	<6F436293-9E2B-461C-B105-FC4CF9EBFC69@gmail.com>
	<CADL_X_fs3-Zj-9nHu5HXCS=kNFUTJkrUR_8SL+d+M4ziwB66Jw@mail.gmail.com>
	<CABm2gDqFe+_g5Mk=tXCD94x74pu6SiL+XHhMM-T3bBw78m3Mow@mail.gmail.com>
	<D161F6BB-BFB1-4B9F-B024-D60A170F393C@gmail.com>
	<CALqmWPC8PdSPS3chhnjBaTixrvvg0VrEaXzd3OvbXifkMs0DUw@mail.gmail.com>
	<42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai> <l.com@mac.com>
	<D472C05D-7164-4ED1-B571-94415AD8E60F@gmail.com>
	<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 <jeanpaulkogelman@me.com>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list


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 <bitcoin-d=
ev@lists.linuxfoundation.org> 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 <elombrozo@gmail.com> wrote:
>>=20
>>=20
>>> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman <jeanpaulkogelman@me.com=
> 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