Re: [bitcoin-dev] Fees and the block-finding process

From: Ryan Butler <rryananizer@gmail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Fees and the block-finding process
Date: Fri, 7 Aug 2015 12:47:22 -0500	[thread overview]
Message-ID: <CAF_2MyUtrBUnR6EN-mOOnDa+Xh9=2coo9GaUcaeHCREqfP7jxA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@mail.gmail.com>

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

Interesting position there Peter...you fear more people actually using
bitcoin.  The less on chain transactions the lower the velocity and the
lower the value of the network.  I would be careful what you ask for
because you end up having nothing left to even root the security of these
off chain transactions with and then neither will exist.

Nobody ever said you wouldn't run out of capacity at any size.  It's quite
the fallacy to draw the conclusion from that statement that block size
should remain far below a capacity it can easily maintain which would bring
more users/velocity/value to the system.  The outcomes of both of those
scenarios are asymmetric.  A higher block size can support more users and
volume.

Raising the blocksize isn't out of fear.  It's the realization that we are
at a point where we can raise it and support more users and transactions
while keeping the downsides to a minimum (centralization etc).
On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen@gmail•com>
> wrote:
>
>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille@gmail•com>
>> wrote:
>>
>>> I guess my question (and perhaps that's what Jorge is after): do you
>>> feel that blocks should be increased in response to (or for fear of) such a
>>> scenario.
>>>
>>
>> I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>
> This is a fundamental disagreement then. I believe that the demand is
> infinite if you don't set a fee minimum (and I don't think we should), and
> it just takes time for the market to find a way to fill whatever is
> available - the rest goes into off-chain systems anyway. You will run out
> of capacity at any size, and acting out of fear of that reality does not
> improve the system. Whatever size blocks are actually produced, I believe
> the result will either be something people consider too small to be
> competitive ("you mean Bitcoin can only do 24 transactions per second?"
> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
> second?"), or something that is very centralized in practice, and likely
> both.
>
>
>> And if so, if that is a reason for increase now, won't it be a reason for
>>> an increase later as well? It is my impression that your answer is yes,
>>> that this is why you want to increase the block size quickly and
>>> significantly, but correct me if I'm wrong.
>>>
>>
>> Sure, it might be a reason for an increase later. Here's my message to
>> in-the-future Bitcoin engineers:  you should consider raising the maximum
>> block size if needed and you think the benefits of doing so (like increased
>> adoption or lower transaction fees or increased reliability) outweigh the
>> costs (like higher operating costs for full-nodes or the disruption caused
>> by ANY consensus rule change).
>>
>
> In general that sounds reasonable, but it's a dangerous precedent to make
> technical decisions based on a fear of change of economics...
>
> --
> Pieter
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5255 bytes --]