public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ryan Butler <rryananizer@gmail•com>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
Date: Fri, 7 Aug 2015 14:07:28 -0500	[thread overview]
Message-ID: <CAF_2MyUqf3Qf7aj6DXy81AycD7EoyZTMsHKih1yfvAmy1BS+wA@mail.gmail.com> (raw)
In-Reply-To: <CAF_2MyVoL7_7jPZX-aftfcjV59nCP1q5bOK-Xyn8JoqyqysXLg@mail.gmail.com>

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

Clarification...

These are not mutually exclusive.  We can design an increase to blocksize
that increases available space on chain AND follow technological
evolution.  Peter's latest proposal is way too conservative on that front.

And given Peter's assertion that demand is infinite there will still be a
an ocean of off chain transactions for the likes of blockstream to address.
On Aug 7, 2015 1:57 PM, "Ryan Butler" <rryananizer@gmail•com> wrote:

> Who said anything about scaling bitcoin to visa levels now?  We're talking
> about an increase now that scales into the future at a rate that is
> consistent with technological progress.
>
> Peter himself said "So, I think the block size should follow technological
> evolution...".
>
> The blocksize increase proposals have been modeled around this very
> thing.  It's reasonable to increase the blocksize to a point that a
> reasonable person, with reasonable equipment and internet access can run a
> node or even a miner with acceptable orphan rates.  Most miners are spv
> mining anyways.  The 8 or even 20 MB limits are within those parameters.
>
> These are not mutually exclusive.  We can design an increase to blocksize
> that addresses both demand exceeding the available space AND follow
> technological evolution.  Peter's latest proposal is way too conservative
> on that front.
> On Aug 7, 2015 1:25 PM, "Mark Friedenbach" <mark@friedenbach•org> wrote:
>
>> Please don't put words into Pieter's mouth. I guarantee you everyone
>> working on Bitcoin in their heart of hearts would prefer everyone in the
>> world being able to use the Bitcoin ledger for whatever purpose, if there
>> were no cost.
>>
>> But like any real world engineering issue, this is a matter of tradeoffs.
>> At the extreme it is simply impossible to scale Bitcoin to the terrabyte
>> sized blocks that would be necessary to service the entire world's
>> financial transactions. Not without sacrificing entirely the protection of
>> policy neutrality achieved through decentralization. And as that is
>> Bitcoin's only advantage over traditional consensus systems, you would have
>> to wonder what the point of such an endeavor would be.
>>
>> So *somewhere* you have to draw the line, and transactions below that
>> level are simply pushed into higher level or off-chain protocols.
>>
>> The issue, as Pieter and Jorge have been pointing out, is that technical
>> discussion over where that line should be has been missing from this debate.
>>
>> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>

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

  reply	other threads:[~2015-08-07 19:07 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 14:57 Gavin Andresen
2015-08-07 15:16 ` Pieter Wuille
2015-08-07 15:55   ` Gavin Andresen
2015-08-07 16:28     ` Pieter Wuille
2015-08-07 17:47       ` Ryan Butler
2015-08-07 18:25         ` Mark Friedenbach
2015-08-07 18:57           ` Ryan Butler
2015-08-07 19:07             ` Ryan Butler [this message]
2015-08-07 19:15               ` Mark Friedenbach
2015-08-07 20:17                 ` Ryan Butler
2015-08-07 20:33                   ` Dave Hudson
2015-08-07 18:17       ` jl2012
2015-08-07 18:35         ` Bryan Bishop
2015-08-07 18:36         ` Simon Liu
2015-08-11 23:20       ` Elliot Olds
2015-08-07 17:33     ` Jorge Timón
2015-08-07 22:12       ` Thomas Zander
2015-08-07 23:06         ` Adam Back
2015-08-08 22:45           ` Dave Scotese
2015-08-08 23:05             ` Alex Morcos
2015-08-09  5:52               ` Hector Chu
2015-08-09 10:32               ` Thomas Zander
2015-08-09 10:42             ` Thomas Zander
2015-08-09 20:43               ` Dave Scotese
2015-08-11 17:03                 ` Jorge Timón
2015-08-10 11:55       ` Jorge Timón
2015-08-10 12:33         ` Btc Drak
2015-08-10 13:03           ` Jorge Timón
2015-08-10 22:13         ` Thomas Zander
2015-08-11 17:47           ` Jorge Timón
2015-08-11 18:46             ` Michael Naber
2015-08-11 18:48               ` Mark Friedenbach
2015-08-11 18:55                 ` Michael Naber
2015-08-11 19:45                   ` Jorge Timón
2015-08-11 21:31                     ` Michael Naber
2015-08-11 18:51               ` Bryan Bishop
2015-08-11 18:59                 ` Michael Naber
2015-08-11 19:27               ` Jorge Timón
2015-08-11 19:37                 ` Michael Naber
2015-08-11 19:51                   ` Pieter Wuille
2015-08-11 21:18                     ` Michael Naber
2015-08-11 21:23                       ` Adam Back
2015-08-11 21:30                         ` Angel Leon
2015-08-11 21:32                           ` Pieter Wuille
2015-08-11 21:34                           ` Adam Back
2015-08-11 21:39                             ` Michael Naber
2015-08-12  6:10                               ` Venzen Khaosan
2015-08-11 22:06                             ` Angel Leon
2015-08-11 21:35                         ` Michael Naber
2015-08-11 21:51                           ` Pieter Wuille
2015-08-12  3:35                             ` Elliot Olds
2015-08-12  4:47                               ` Venzen Khaosan
2015-08-14 21:47                                 ` Elliot Olds
2015-08-12  0:56                         ` Tom Harding
2015-08-12  1:18                       ` Eric Voskuil
2015-08-12  8:10                     ` Thomas Zander
2015-08-12  9:00                       ` Jorge Timón
2015-08-12  9:25                         ` Thomas Zander
2015-08-11 19:53                   ` Jorge Timón
2015-08-11 20:56                     ` Michael Naber
2015-08-12  7:54                 ` Thomas Zander
2015-08-12  8:01             ` Thomas Zander
     [not found]             ` <1679272.aDpruqxXDP@coldstorage>
2015-08-12  8:51               ` Jorge Timón
2015-08-12  9:23                 ` Thomas Zander
2015-08-12  9:45                   ` Jorge Timón
2015-08-12 16:24                     ` Thomas Zander
2015-08-17 14:49                     ` BitMinter operator
2015-08-17 15:01                       ` Peter Todd
2015-08-10 14:12       ` Gavin Andresen
2015-08-10 14:24         ` Alex Morcos
2015-08-10 22:12           ` Thomas Zander
2015-08-10 14:34         ` Pieter Wuille
2015-08-10 22:04           ` Thomas Zander
2015-08-20 14:40           ` Will Madden
2015-08-10 14:55         ` Jorge Timón
2015-08-10 22:09           ` Thomas Zander
2015-08-10 22:52             ` Pieter Wuille
2015-08-10 23:11               ` Pieter Wuille
2015-08-11  5:34               ` Thomas Zander
2015-08-11  6:03                 ` Mark Friedenbach
2015-08-11  6:31                   ` Thomas Zander
2015-08-11  7:08                     ` Mark Friedenbach
2015-08-11  8:38                       ` Thomas Zander
2015-08-11  9:14                         ` Angel Leon
2015-08-11 19:00                           ` Mark Friedenbach
2015-08-11 19:26                             ` Michael Naber
2015-08-11 20:12                               ` Adam Back
2015-08-12  0:32                           ` odinn
2015-08-11 11:10                       ` Thomas Zander
2015-08-12  0:18                       ` odinn
2015-08-07 21:30   ` Jim Phillips
2015-08-07 18:22 ` Anthony Towns
2015-08-07 18:36 ` Peter R
2015-08-12  1:56 Corey Haddad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAF_2MyUqf3Qf7aj6DXy81AycD7EoyZTMsHKih1yfvAmy1BS+wA@mail.gmail.com \
    --to=rryananizer@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=mark@friedenbach$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox