<unnamed>

Public Key

npub19jx6yq5fyvvcn3zlf0f60kr78q7wq5fy5qd9yqlqwumlqqcfc8rsl7fxhj

Profile Code

nprofile1qqszerdzq2yjxxvfc305h5a8mplrs08q2yj2qxjjq0s8wdlsqvyur3cpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqlfchgw

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:45:42 UTC

- reply

📅 Original date posted:2015-12-09
📝 Original message:I see, thanks for clearing that up, I misread what Gavin stated.
On Wed, Dec 9, 2015 at 12:29 AM, Gregory Maxwell <greg at xiph.org> wrote:
> On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler <rryananizer at gmail.com> wrote:
> >>I agree, but nothing I have advocated creates significant technical
> >>debt. It is also a bad engineering practice to combine functional
> >>changes (especially ones with poorly understood system wide
> >>consequences and low user autonomy) with structural tidying.
> >
> > I don't think I would classify placing things in consensus critical code
> > when it doesn't need to be as "structural tidying". Gavin said "pile on"
> > which you took as implying "a lot", he can correct me, but I believe he
> > meant "add to".
>
> Nothing being discussed would move something from consensus critical
> code to not consensus critical.
>
> What was being discussed was the location of the witness commitment;
> which is consensus critical regardless of where it is placed. Should
> it be placed in an available location which is compatible with the
> existing network, or should the block hashing data structure
> immediately be changed in an incompatible way to accommodate it in
> order to satisfy an ascetic sense of purity and to make fraud proofs
> somewhat smaller?
>
> I argue that the size difference in the fraud proofs is not
> interesting, the disruption to the network in an incompatible upgrade
> is interesting; and that if it really were desirable reorganization to
> move the commitment point could be done as part of a separate change
> that changes only the location of things (and/or other trivial
> adjustments); and that proceeding int this fashion would minimize
> disruption and risk... by making the incompatible changes that will
> force network wide software updates be as small and as simple as
> possible.
>
> >> (especially ones with poorly understood system wide consequences and low
> >> user autonomy)
> >
> > This implies there you have no confidence in the unit tests and
> functional
> > testing around Bitcoin and should not be a reason to avoid refactoring.
> > It's more a reason to increase testing so that you will have confidence
> when
> > you refactor.
>
> I am speaking from our engineering experience in a public,
> world-wide, multi-vendor, multi-version, inter-operable, distributed
> system which is constantly changing and in production contains private
> code, unknown and assorted hardware, mixtures of versions, unreliable
> networks, undisclosed usage patterns, and more sources of complex
> behavior than can be counted-- including complex economic incentives
> and malicious participants.
>
> Even if we knew the complete spectrum of possible states for the
> system the combinatioric explosion makes complete testing infeasible.
>
> Though testing is essential one cannot "unit test" away all the risks
> related to deploying a new behavior in the network.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/21a08ea0/attachment.html>

2023-06-07 17:45:41 UTC

- reply

📅 Original date posted:2015-12-09
📝 Original message:>I agree, but nothing I have advocated creates significant technical
>debt. It is also a bad engineering practice to combine functional
>changes (especially ones with poorly understood system wide
>consequences and low user autonomy) with structural tidying.
I don't think I would classify placing things in consensus critical code
when it doesn't need to be as "structural tidying". Gavin said "pile on"
which you took as implying "a lot", he can correct me, but I believe he
meant "add to".
> (especially ones with poorly understood system wide consequences and low
user autonomy)
This implies there you have no confidence in the unit tests and functional
testing around Bitcoin and should not be a reason to avoid refactoring.
It's more a reason to increase testing so that you will have confidence
when you refactor.
Also I don't think Martin Fowler would agree with you...
"Refactoring should be done in conjunction with adding new features."
"Always leave the code better than when you found it."
"Often you start working on adding new functionality and you realize the
existing structures don't play well with what you're about to do.
In this situation it usually pays to begin by refactoring the existing code
into the shape you now know is the right shape for what you're about to do."
-Martin Fowler
On Tue, Dec 8, 2015 at 7:31 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > Create a 1-megabyte transaction, with all of it's inputs spending
> > segwitness-spending SIGHASH_ALL inputs.
> >
> > Because the segwitness inputs are smaller in the block, you can fit more
> of
> > them into 1 megabyte. Each will hash very close to one megabyte of data.
>
> Witness size comes out of the 1MB at a factor of 0.25. It is not
> possible to make a block which has signatures with the full 1MB of
> data under the sighash while also having signatures externally. So
> every byte moved into the witness and thus only counted as 25% comes
> out of the data being hashed and is hashed nInputs (*checksigs) less
> times.
>
> > I think it is a huge mistake not to "design for success" (see
> > http://gavinandresen.ninja/designing-for-success ).
>
> We are designing for success; including the success of being able to
> adapt and cope with uncertainty-- which is the most critical kind of
> success we can have in a world where nothing is and can be
> predictable.
>
> > I think it is a huge mistake to pile on technical debt in
> consensus-critical
> > code. I think we should be working harder to make things simpler, not
> more
> > complex, whenever possible.
>
> I agree, but nothing I have advocated creates significant technical
> debt. It is also a bad engineering practice to combine functional
> changes (especially ones with poorly understood system wide
> consequences and low user autonomy) with structural tidying.
>
> > And I think there are pretty big self-inflicted current problems because
> > worries about theoretical future problems have prevented us from coming
> to
> > consensus on simple solutions.
>
> That isn't my perspective. I believe we've suffered delays because of
> a strong desire to be inclusive and hear out all ideas, and not
> forestall market adoption, even for ideas that eschewed pragmatism and
> tried to build for forever in a single step and which in our hear of
> hearts we knew were not the right path today. It's time to move past
> that and get back on track with the progress can make and have been
> making, in terms of capacity as well as many other areas. I think that
> is designing for success.
> _______________________________________________
> 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/20151208/ac78b75c/attachment.html>

2023-06-07 17:33:35 UTC

- reply

📅 Original date posted:2015-08-07
📝 Original message:Peter's proposal undercuts matching blocksize growth to technological
progress not limiting centralization pressure. They are somewhat related,
but I want to be clear on what I originally stated. I would also point out
that Peter's proposal lacks this technical criteria as well.
That being said, I think designing any growth rates on theoretical
centralization pressure is not sensible and Peter's proposal rightly
excludes it and attempts instead for a very gradual increase over time
attempting to match blocksize growth that is consistent with technological
bandwidth growth. The problem is that it ignores the last 6 years (we are
already "behind") and underestimates bandwidth and storage growth. (See
Nielsen's law which states 50% and has held for 30 years).
Peter seems to be of the belief that since bitcoin will never be able to
handle all the world's transactions we should instead "...decrease the need
for trust required in off-chain systems...". This is akin to basing all
the world's transactions on a small settlement layer, much like balancing a
pyramid upside down it will topple.
I'm of the belief that the "reasonable node" test is a simple enough test
to maintain decentralization.
A raspberry pie 2 node on reasonable Internet connection with a reasonable
hard drive can run a node with 8 or 20mb blocks easily.
As Peter's proposal indicates, "If over time, this growth factor is beyond
what the actual technology offers, the intention should be to soft fork a
tighter limit." I wholeheartedly agree, which is why we should plan to be
ahead of the curve...not behind it.
On Aug 7, 2015 2:15 PM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
> 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/21260f13/attachment.html>

2023-06-07 17:33:33 UTC

- reply

📅 Original date posted:2015-08-07
📝 Original message: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/0b5d3fa2/attachment.html>

2023-06-07 17:33:33 UTC

- reply

📅 Original date posted:2015-08-07
📝 Original message: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/33b2af03/attachment-0001.html>

2023-06-07 17:33:32 UTC

- reply

📅 Original date posted:2015-08-07
📝 Original message: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/e608eb78/attachment.html>

2023-06-07 15:45:42 UTC

- reply

2023-06-07 15:45:41 UTC

- reply

2023-06-07 15:45:41 UTC

- reply

2023-06-07 15:45:40 UTC

- reply

2023-06-07 15:44:08 UTC

- reply

📅 Original date posted:2015-07-30
📝 Original message:I shouldn't have said unlimited, i should have said a greater blocksize
limit such as 8mb.
Anyways, why is that the assumption? If a miner can do so, and do so
profitably, isn't that just competition? Isn't that what we want? If a
miner can mine low transaction fees at a profit then don't they deserve to
have their spot? Surely if they do so unprofitably they quickly find
themselves out of business? Besides, if a miner mines low fee transactions
by breaking rank, how does this affect another miner EXCEPT for the
additional blocksize load. I would maintain this is just competition
amongst miners gentlemen. And it's a good thing.
Right now things are distorted because most income comes from the coinbase,
but as transaction fees start to constitute the majority of income this
idea seems to have more importance.
On Jul 29, 2015 11:00 PM, "Adam Back" <adam at cypherspace.org> wrote:
> On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Does an unlimited blocksize imply the lack of a fee market? Isn't every
> > miner able to set their minimum accepted fee or transaction acceptance
> > algorithm?
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system. It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it. It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/f665c813/attachment-0001.html>

2023-06-07 15:44:06 UTC

- reply

📅 Original date posted:2015-07-30
📝 Original message:Does an unlimited blocksize imply the lack of a fee market? Isn't every
miner able to set their minimum accepted fee or transaction acceptance
algorithm?
On Jul 29, 2015 5:54 PM, "s7r via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We could care less about you selling your bitcoins or moving to
> something else.
>
> What we care more is keeping bitcoin a successful project which offers
> clear benefits to the world. I agree a fee market is good and needed,
> and transactions shouldn't be free ever, but users should also be able
> to transact fast and relatively cheap, as opposite to the competition,
> or at least with the same costs, so people won't move to something else.
>
> The more people use bitcoin, the more demand we have on the market for
> BTC, the higher BTC/FIAT rate will be, more people will become
> interested in mining and so on. Bitcoin is not a rich-only-private-club,
> it's an open, global, decentralized payment network. The less people use
> it... I guess you figured it out.
>
> So we could care less that you will go away in case the fee market won't
> become absurd or too expensive to use for most users. Having some
> offchain solution for small transactions would be a good idea, but this
> doesn't mean we should make small transactions impossible due to absurd
> fees.
>
> On 7/29/2015 8:47 PM, Raystonn . via bitcoin-dev wrote:
> >> When a category of users would get priced out because of the fee
> > market, they would be free to use any altcoin they want.
> >
> > I believe that pretty well sums up where we’re headed if transaction
> > rate is artificially limited, whether that be by maximum block size
> > limit or something else. A fee market will necessarily include more
> > than just Bitcoin. The reality is it’s very easy to trade value across
> > different blockchains, and thus a fee market will bleed value from
> > Bitcoin and give it to alternative blockchains. If Bitcoin’s blocks are
> > at maximum capacity, people will exchange for something that allows them
> > to transact with a lesser fee, then make the desired payment. This adds
> > value to the alternative blockchain and removes it from Bitcoin.
> >
> > Anyone thinking the fee market can be restrained to Bitcoin alone is
> > mistaken.
> >
> >
> > *From:* Vali Zero via bitcoin-dev
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > *Sent:* Wednesday, July 29, 2015 7:09 AM
> > *To:* bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > *Subject:* [bitcoin-dev] Răspuns: Personal opinion on the fee market
> > from a worried local trader
> >
> > I am disappointed that you did not understand my point of view. Let me
> > rephrase it for you,
> >
> > People tipping, buying 0.99$ products and gamblers that need Bitcoin
> > transactions *more* than the rest of the people will afford the fees
> > that establish the equilibrium between demand and supply of Bitcoin
> > transactions. The people are free to use they money for whatever they
> > like, but you should understand that Bitcoin transactions are not free.
> >
> > I was merely attempting to point out that spammers and gamblers would be
> > the first ones that would go away. They would be free to spam or gamble,
> > but they would have to pay for it.
> >
> > When a category of users would get priced out because of the fee market,
> > they would be free to use any altcoin they want.
> >
> > Please understand that not everyone will leave. The more important
> > players will remain, those that need it the most. The other players are
> > free to use whatever altcoin they wish.
> >
> >
> > În Miercuri, 29 Iulie 2015 16:47:57, Angel Leon <gubatron at gmail.com> a
> > scris:
> >
> >
> > "the gamblers and perhaps people transacting very low amounts. The
> > people that actually need Bitcoin would remain."
> >
> > so people tipping, buying $0.99 products, and gamblers actually don't
> > need Bitcoin.
> > Who are you to say what people need to use money for?
> > This statement goes against the freedom of decentralization and
> > financial freedom Bitcoin should be able to provide.
> >
> > It's an open network and it will be used as most users see fit, and that
> > requires a blocksize increase wether you like it or not, it's simple
> > physics, other time wait times will become unbearable for those not
> > willing to pay the high fees, if people leave, then it only mean
> > bitcoins isn't useful, and if bitcoin isn't useful, it's worthless.
> >
> >
> >
> > http://twitter.com/gubatron
> >
> > On Wed, Jul 29, 2015 at 9:27 AM, Vali Zero via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > Hello,
> >
> > I have been reading an argument saying that paying higher fees would
> > scare Bitcoin users and they would stop using it, preferring bank
> > transfers or other payment methods. This does not make sense for me.
> > If some users leave, then demand for bitcoin transactions goes down
> > and so do the fees. The others remain.
> >
> > Fee market means that an equilibrium is found between the demand for
> > bitcoin transactions and the available supply (given by the block
> > size). The fee is the price that finds this equilibrium.
> >
> > If a fee market starts to exist, the first ones to leave are the
> > spammers, probably followed by the gamblers and perhaps people
> > transacting very low amounts. The people that actually need Bitcoin
> > would remain.
> >
> > Please allow this fee market to form...
> >
> > In the absence of a functioning fee market, I will refuse to run
> > Bitcoin code that increases the block size and will do my best to
> > tell everyone I know not to upgrade towards running such code. If
> > Bitcoin succombs to the free stuff army, I will sell all the coins
> > and leave. Nothing is for free.
> >
> > I apologize for any exagerations, but I just felt strongly towards
> > expressing my opinion here. I'm only a local Bitcoin trader,
> > computer engineer, with a reasonable understanding of free markets.
> > And I'm running only one full node.
> >
> > Kind regards,
> > Valentin
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > <mailto: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/20150729/5460df74/attachment-0001.html>