Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_BC3ED210-0B23-47C7-9CBC-728E3FDF1D93";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <9AC88C7C-4BA4-4DF2-913F-9DC6874BD19D@me.com>
Date: Thu, 23 Jul 2015 18:55:25 -0700
Message-Id: <83982C1D-4FE6-4A5C-BC93-BFBD9756F3D2@gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@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>
	<4734381C-2000-4D9B-9099-DDE3D38D64A3@me.com>
	<DEF9C610-2FBC-40C1-9AFA-9E91903C7F96@petertodd.org>
	<DFA3CCE4-52F7-4D63-8982-2EB133AB6EAA@me.com>
	<B8F9DE4B-A8AA-490D-991B-11C28B2AA527@gmail.com>
	<D7EE14EC-B36D-43F2-8CEC-B63443FBBCA8@me.com>
	<0E15E07E-E21C-4541-869A-3C34CBA35774@gmail.com>
	<9AC88C7C-4BA4-4DF2-913F-9DC6874BD19D@me.com>
To: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Cc: Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list


--Apple-Mail=_BC3ED210-0B23-47C7-9CBC-728E3FDF1D93
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree that the fewer the necessary parties the better - however, some =
entities are much better positioned to offer certain services on the =
network than others - and the fact we can trustlessly negotiate smart =
contracts with them is one of the most significant developments in the =
cryptospace - it=E2=80=99s one of the most revolutionary aspects of this =
technology=E2=80=A6it accomplishes something we=E2=80=99ve never really =
been able to do before.

Notice that third parties can encapsulate complex tasks and provide a =
far simpler interface. Crypto contracts provide the incentives for them =
to do this. And by having competition and transparency, these services =
automatically get optimized via human ingenuity. We don=E2=80=99t need =
to design top-down for it.

> On Jul 23, 2015, at 6:42 PM, Jean-Paul Kogelman =
<jeanpaulkogelman@me.com> wrote:
>=20
> Miners could include their fee tiers in the coinbase, but this is =
obviously open to manipulation, with little recourse (unless they are a =
pool and miners move away because of it).
>=20
> In any event, I think that trying out a solution that is both simple =
and involves the least number of parties necessary is preferable.
>=20
> Have miners set their tiers, have users select the level of quality =
they want, ignore the block size.
>=20
> Miners will adapt their tiers depending on how many transactions =
actually end up in them. If for example they set the first tier to be $1 =
to be included in the current block and no user chooses that level of =
service, they've obviously priced themselves out of the market. The =
opposite is also true; if a tier is popular they can choose to increase =
the cost of that tier.
>=20
> jp
>=20
>> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>>=20
>> I suppose you can use a timelocked output that is spendable by anyone =
you could go somewhat in this direction=E2=80=A6the thing is it still =
means the wallet must make fee estimations rather than being able to get =
a quick quote.
>>=20
>>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman =
<jeanpaulkogelman@me.com> wrote:
>>>=20
>>> I think implicit QoS is far simpler to implement, requires less =
parties and is closer to what Bitcoin started out as: a peer-to-peer =
digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer =
system.
>>>=20
>>> jp
>>>=20
>>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>>>>=20
>>>> By using third parties separate from individual miners that do =
bidding on your behalf you get a mechanism that allows QoS guarantees =
and shifting the complexity and risk from the wallet with little =
computational resources to a service with abundance of them. Using =
timelocked contracts it=E2=80=99s possible to enforce the guarantees.
>>>>=20
>>>> Negotiating directly with miners via smart contracts seems =
difficult at best.
>>>>=20
>>>>=20
>>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>=20
>>>>> Doesn't matter.
>>>>>=20
>>>>> It's not going to be perfect given the block time variance among =
other factors but it's far more workable than guessing whether or not =
your transaction is going to end up in a block at all.
>>>>>=20
>>>>> jp
>>>>>=20
>>>>>=20
>>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd.org> =
wrote:
>>>>>>=20
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via =
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>>>=20
>>>>>>> And it's obvious how a size cap would interfere with such a QoS =
scheme.
>>>>>>> Miners wouldn't be able to deliver the below guarantees if they =
have to
>>>>>>> start excluding transactions.
>>>>>>=20
>>>>>> As mining is a random, poisson process, obviously giving =
guarantees without a majority of hashing power isn't possible.
>>>>>>=20
>>>>>>=20
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>>=20
>>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=3D
>>>>>> =3DLY1+
>>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20


--Apple-Mail=_BC3ED210-0B23-47C7-9CBC-728E3FDF1D93
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVsZsNAAoJEJNAI64YFENU+/IP/AzcHHlZG7H+gZVzbMYZckWl
Sywl9Giu78ELNo1BYkfVbKH0b76FaqvRxWxg9i4S7NYFmrQR5XFMAunq7jVokXab
uOXNIm3BL79m9zSxSUlNaZ894aa2NIHV2ENfx302Jg5Rksl6UdfzkQUCPE6T/jRE
I7aqz0k5Yw3IBz1xV4+Wl9jWFiF0YwIc/G/seQn6JzNuK4lmi3c2NPEUMMlUeVpt
y8rpdRmmWkAxTfVbr3mCGwMysvsw7I2SNX9uHqBM4lMd4zIEGxmVvuTejCbtXFui
fXgBqKeqc3QIM1kUzIYq8kzqYi1Gp/UHmr4TrUSDp61U0lsRmq5y6yZEFQv0JDeR
XVOfYjWQm3Vh1LT7jjuEedIk+0fhPhDzikATY3B4/aoRzeWUeT6Hk7fSS5izDSJI
YEVWYL++GYQQP8aZOdYpJWT2k7xb/4B81soPSnZDv3mdbMfcGzps5/VwPwSw3Baa
dXDRU1kphUfws11K1oJj7c82c2GXe9uxmbf54QHusOPK0JRN9Qkjf5m1oPoXE4l/
U9ujRZFQR6nL/uclpIyqWH5x+sMBXeVaDGXv3c2by8oWv94Q26Vzx8iJ0wtFZoq7
sq8mgonZF7GWYA8tlz4lKxRf0IwcQ8stqPmaEPxgQbxEnz5azjZDVYSzmCCG2u92
MP2BC5EwCgAoAwp3wyt+
=/fLi
-----END PGP SIGNATURE-----

--Apple-Mail=_BC3ED210-0B23-47C7-9CBC-728E3FDF1D93--