Re: [bitcoin-dev] Bitcoin Core and hard forks

From: Eric Lombrozo <elombrozo@gmail•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
Date: Thu, 23 Jul 2015 18:55:25 -0700	[thread overview]
Message-ID: <83982C1D-4FE6-4A5C-BC93-BFBD9756F3D2@gmail.com> (raw)
In-Reply-To: <9AC88C7C-4BA4-4DF2-913F-9DC6874BD19D@me.com>

[-- Attachment #1: Type: text/plain, Size: 4677 bytes --]

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’s one of the most revolutionary aspects of this technology…it accomplishes something we’ve 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’t need to design top-down for it.

> On Jul 23, 2015, at 6:42 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
> 
> 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).
> 
> In any event, I think that trying out a solution that is both simple and involves the least number of parties necessary is preferable.
> 
> Have miners set their tiers, have users select the level of quality they want, ignore the block size.
> 
> 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.
> 
> jp
> 
>> On Jul 24, 2015, at 9:28 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>> 
>> I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote.
>> 
>>> On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman <jeanpaulkogelman@me•com> wrote:
>>> 
>>> 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.
>>> 
>>> jp
>>> 
>>>> On Jul 24, 2015, at 9:08 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>>> 
>>>> 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’s possible to enforce the guarantees.
>>>> 
>>>> Negotiating directly with miners via smart contracts seems difficult at best.
>>>> 
>>>> 
>>>>> On Jul 23, 2015, at 6:03 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>> 
>>>>> Doesn't matter.
>>>>> 
>>>>> 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.
>>>>> 
>>>>> jp
>>>>> 
>>>>> 
>>>>>> On Jul 24, 2015, at 8:53 AM, Peter Todd <pete@petertodd•org> wrote:
>>>>>> 
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA256
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>> As mining is a random, poisson process, obviously giving guarantees without a majority of hashing power isn't possible.
>>>>>> 
>>>>>> 
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> 
>>>>>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsYyK
>>>>>> AAoJEMCF8hzn9Lnc47AH/28WlecQLb37CiJpcvXO9tC4zqYEodurtB9nBHTSJrug
>>>>>> VIEXZW53pSTdd3vv2qpGIlHxuYP8QmDSATztwQLuN6XWEszz7TO8MXBfLxKqZyGu
>>>>>> i83WqSGjMAfwqjl0xR1G7PJgt4+E+0vaAFZc98vLCgZnedbiXRVtTGjhofG1jjTc
>>>>>> DFMwMZHP0eqWTwtWwqUvnA7PTFHxdqoJruY/t1KceN+JDbBCJWMxBDswU64FXcVH
>>>>>> 0ecsk9nhLMyylBX/2v4HjCXyayocH8jQ+FpLSP0xxERyS+f1npFX9cxFMq24uXqn
>>>>>> PcnZfLfaSJ6gMbmhbYG5wYDKN3u732j7dLzSJnMW6jk=
>>>>>> =LY1+
>>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists•linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]