š
Original date posted:2015-08-07
š Original message:Surely you have some sort of empirical measurement demonstrating the
validity of that statement? That is to say you've established some
technical criteria by which to determine how much centralization pressure
is too much, and shown that Pieter's proposal undercuts expected progress
in that area?
On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler <rryananizer at gmail.com> wrote:
> 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 at 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 at 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 at 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 at lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <
>>>>> gavinandresen at gmail.com> wrote:
>>>>>
>>>>>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <
>>>>>> pieter.wuille at 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 at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/c08c7fc7/attachment-0001.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3ā¦48d0u
2023-06-07 15:45:42
in reply to nevent1qā¦0y0y
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:45:42Event JSON
{
"id": "8ba667ab06d248b9d332bdba60bc5af12f433c7ae4e366895f47de1d6bbeefd0",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686152742,
"kind": 1,
"tags": [
[
"e",
"cf6411bfecea99b0c4ea78e985838b5e3fd62429f4968960ffd260356286401f",
"",
"root"
],
[
"e",
"082a8dc9bcecd66f12a1e5c4b90d54811cc51274118aa67ee50f08f1fdebb285",
"",
"reply"
],
[
"p",
"2c8da20289231989c45f4bd3a7d87e383ce05124a01a5203e07737f00309c1c7"
]
],
"content": "š
Original date posted:2015-08-07\nš Original message:Surely you have some sort of empirical measurement demonstrating the\nvalidity of that statement? That is to say you've established some\ntechnical criteria by which to determine how much centralization pressure\nis too much, and shown that Pieter's proposal undercuts expected progress\nin that area?\n\nOn Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler \u003crryananizer at gmail.com\u003e wrote:\n\n\u003e Clarification...\n\u003e\n\u003e These are not mutually exclusive. We can design an increase to blocksize\n\u003e that increases available space on chain AND follow technological\n\u003e evolution. Peter's latest proposal is way too conservative on that front.\n\u003e\n\u003e And given Peter's assertion that demand is infinite there will still be a\n\u003e an ocean of off chain transactions for the likes of blockstream to address.\n\u003e On Aug 7, 2015 1:57 PM, \"Ryan Butler\" \u003crryananizer at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Who said anything about scaling bitcoin to visa levels now? We're\n\u003e\u003e talking about an increase now that scales into the future at a rate that is\n\u003e\u003e consistent with technological progress.\n\u003e\u003e\n\u003e\u003e Peter himself said \"So, I think the block size should follow\n\u003e\u003e technological evolution...\".\n\u003e\u003e\n\u003e\u003e The blocksize increase proposals have been modeled around this very\n\u003e\u003e thing. It's reasonable to increase the blocksize to a point that a\n\u003e\u003e reasonable person, with reasonable equipment and internet access can run a\n\u003e\u003e node or even a miner with acceptable orphan rates. Most miners are spv\n\u003e\u003e mining anyways. The 8 or even 20 MB limits are within those parameters.\n\u003e\u003e\n\u003e\u003e These are not mutually exclusive. We can design an increase to blocksize\n\u003e\u003e that addresses both demand exceeding the available space AND follow\n\u003e\u003e technological evolution. Peter's latest proposal is way too conservative\n\u003e\u003e on that front.\n\u003e\u003e On Aug 7, 2015 1:25 PM, \"Mark Friedenbach\" \u003cmark at friedenbach.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Please don't put words into Pieter's mouth. I guarantee you everyone\n\u003e\u003e\u003e working on Bitcoin in their heart of hearts would prefer everyone in the\n\u003e\u003e\u003e world being able to use the Bitcoin ledger for whatever purpose, if there\n\u003e\u003e\u003e were no cost.\n\u003e\u003e\u003e\n\u003e\u003e\u003e But like any real world engineering issue, this is a matter of\n\u003e\u003e\u003e tradeoffs. At the extreme it is simply impossible to scale Bitcoin to the\n\u003e\u003e\u003e terrabyte sized blocks that would be necessary to service the entire\n\u003e\u003e\u003e world's financial transactions. Not without sacrificing entirely the\n\u003e\u003e\u003e protection of policy neutrality achieved through decentralization. And as\n\u003e\u003e\u003e that is Bitcoin's only advantage over traditional consensus systems, you\n\u003e\u003e\u003e would have to wonder what the point of such an endeavor would be.\n\u003e\u003e\u003e\n\u003e\u003e\u003e So *somewhere* you have to draw the line, and transactions below that\n\u003e\u003e\u003e level are simply pushed into higher level or off-chain protocols.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The issue, as Pieter and Jorge have been pointing out, is that technical\n\u003e\u003e\u003e discussion over where that line should be has been missing from this debate.\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Interesting position there Peter...you fear more people actually using\n\u003e\u003e\u003e\u003e bitcoin. The less on chain transactions the lower the velocity and the\n\u003e\u003e\u003e\u003e lower the value of the network. I would be careful what you ask for\n\u003e\u003e\u003e\u003e because you end up having nothing left to even root the security of these\n\u003e\u003e\u003e\u003e off chain transactions with and then neither will exist.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Nobody ever said you wouldn't run out of capacity at any size. It's\n\u003e\u003e\u003e\u003e quite the fallacy to draw the conclusion from that statement that block\n\u003e\u003e\u003e\u003e size should remain far below a capacity it can easily maintain which would\n\u003e\u003e\u003e\u003e bring more users/velocity/value to the system. The outcomes of both of\n\u003e\u003e\u003e\u003e those scenarios are asymmetric. A higher block size can support more users\n\u003e\u003e\u003e\u003e and volume.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Raising the blocksize isn't out of fear. It's the realization that we\n\u003e\u003e\u003e\u003e are at a point where we can raise it and support more users and\n\u003e\u003e\u003e\u003e transactions while keeping the downsides to a minimum (centralization etc).\n\u003e\u003e\u003e\u003e On Aug 7, 2015 11:28 AM, \"Pieter Wuille via bitcoin-dev\" \u003c\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen \u003c\n\u003e\u003e\u003e\u003e\u003e gavinandresen at gmail.com\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille \u003c\n\u003e\u003e\u003e\u003e\u003e\u003e pieter.wuille at gmail.com\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e I guess my question (and perhaps that's what Jorge is after): do you\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e feel that blocks should be increased in response to (or for fear of) such a\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e scenario.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e I think there are multiple reasons to raise the maximum block size,\n\u003e\u003e\u003e\u003e\u003e\u003e and yes, fear of Bad Things Happening as we run up against the 1MB limit is\n\u003e\u003e\u003e\u003e\u003e\u003e one of the reasons.\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e I take the opinion of smart engineers who actually do resource\n\u003e\u003e\u003e\u003e\u003e\u003e planning and have seen what happens when networks run out of capacity very\n\u003e\u003e\u003e\u003e\u003e\u003e seriously.\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e This is a fundamental disagreement then. I believe that the demand is\n\u003e\u003e\u003e\u003e\u003e infinite if you don't set a fee minimum (and I don't think we should), and\n\u003e\u003e\u003e\u003e\u003e it just takes time for the market to find a way to fill whatever is\n\u003e\u003e\u003e\u003e\u003e available - the rest goes into off-chain systems anyway. You will run out\n\u003e\u003e\u003e\u003e\u003e of capacity at any size, and acting out of fear of that reality does not\n\u003e\u003e\u003e\u003e\u003e improve the system. Whatever size blocks are actually produced, I believe\n\u003e\u003e\u003e\u003e\u003e the result will either be something people consider too small to be\n\u003e\u003e\u003e\u003e\u003e competitive (\"you mean Bitcoin can only do 24 transactions per second?\"\n\u003e\u003e\u003e\u003e\u003e sounds almost the same as \"you mean Bitcoin can only do 3 transactions per\n\u003e\u003e\u003e\u003e\u003e second?\"), or something that is very centralized in practice, and likely\n\u003e\u003e\u003e\u003e\u003e both.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e And if so, if that is a reason for increase now, won't it be a reason\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e for an increase later as well? It is my impression that your answer is yes,\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e that this is why you want to increase the block size quickly and\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e significantly, but correct me if I'm wrong.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e Sure, it might be a reason for an increase later. Here's my message\n\u003e\u003e\u003e\u003e\u003e\u003e to in-the-future Bitcoin engineers: you should consider raising the\n\u003e\u003e\u003e\u003e\u003e\u003e maximum block size if needed and you think the benefits of doing so (like\n\u003e\u003e\u003e\u003e\u003e\u003e increased adoption or lower transaction fees or increased reliability)\n\u003e\u003e\u003e\u003e\u003e\u003e outweigh the costs (like higher operating costs for full-nodes or the\n\u003e\u003e\u003e\u003e\u003e\u003e disruption caused by ANY consensus rule change).\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e In general that sounds reasonable, but it's a dangerous precedent to\n\u003e\u003e\u003e\u003e\u003e make technical decisions based on a fear of change of economics...\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e --\n\u003e\u003e\u003e\u003e\u003e Pieter\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/c08c7fc7/attachment-0001.html\u003e",
"sig": "734c8bf6a9847d6a3c92c13b09da8f19d3024a2fafacdf21c1193dae582552e6ed317f4575176a28991968dfe5d9c07d845ee84eb5596b47427f42b37dff6901"
}