Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-30 📝 Original message:On Thu, Jul 30, 2015 at ...
📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > and a number of the people most intimately familiar with the inner
> workings of the system (some of whom are in this thread) think that given
> what we now today about the Bitcoin network, increasing block size
> externalizes costs in dangerous ways. Remember that total cost includes not
> just equipment costs but also things like block propagation latency and
> specifically identified security risks. Some of these security risks were
> only appreciated relatively recently and were completely unknown in 2009.
>
> I would like (and have been asking) those people to take the time to
> quantify those costs and write up those risks in a careful way.
>
> I believe the costs and risks of 8MB blocks are minimal, and that the
> benefits of supporting more transaction FAR outweigh those costs and risks,
> but it is hard to have a rational conversation about that when even simple
> questions like 'what is s reasonable cost to run a full node' are met with
> silence.
>
I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal
(even assuming miners actually produce 8 MB blocks). There are very few use
cases that Bitcoin on-chain can support with a small extra factor. I think
the market will grow to adapt to whatever is offered anyway.
Bitcoin's advantage over other systems does not lie in scalability.
Well-designed centralized systems can trivially compete with Bitcoin's
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in
network peers, miners, and those who influence or control the system.
Wanting to increase the scale of the system is in conflict with all of
those. Attempting to buy time with a fast increase is not wanting to face
that reality, and treating the system as something whose scale trumps all
other concerns. A long term scalability plan should aim on decreasing the
need for trust required in off-chain systems, rather than increasing the
need for trust in Bitcoin.
Making controversial changes to the network, and not wanting to face the
reality that block chain space is a finite resource - whether enforced by a
consensus rule or by miner's capacity to process transactions - is a huge
treat to Bitcoin's usefulness in the long term.
I think the risks of trying to make a controversial change to the network
FAR outweighs the benefits of a small constant factor that "kicks the can
down the road".
Let's scale the block size gradually over time, according to technological
growth.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/fcd26023/attachment.html>;
📝 Original message:On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
> >
> > and a number of the people most intimately familiar with the inner
> workings of the system (some of whom are in this thread) think that given
> what we now today about the Bitcoin network, increasing block size
> externalizes costs in dangerous ways. Remember that total cost includes not
> just equipment costs but also things like block propagation latency and
> specifically identified security risks. Some of these security risks were
> only appreciated relatively recently and were completely unknown in 2009.
>
> I would like (and have been asking) those people to take the time to
> quantify those costs and write up those risks in a careful way.
>
> I believe the costs and risks of 8MB blocks are minimal, and that the
> benefits of supporting more transaction FAR outweigh those costs and risks,
> but it is hard to have a rational conversation about that when even simple
> questions like 'what is s reasonable cost to run a full node' are met with
> silence.
>
I think the benefit of an 8 MB over a 1 MB in terms of utility is marginal
(even assuming miners actually produce 8 MB blocks). There are very few use
cases that Bitcoin on-chain can support with a small extra factor. I think
the market will grow to adapt to whatever is offered anyway.
Bitcoin's advantage over other systems does not lie in scalability.
Well-designed centralized systems can trivially compete with Bitcoin's
on-chain transactions in terms of cost, speed, reliability, convenience,
and scale. Its power lies in transparency, lack of need for trust in
network peers, miners, and those who influence or control the system.
Wanting to increase the scale of the system is in conflict with all of
those. Attempting to buy time with a fast increase is not wanting to face
that reality, and treating the system as something whose scale trumps all
other concerns. A long term scalability plan should aim on decreasing the
need for trust required in off-chain systems, rather than increasing the
need for trust in Bitcoin.
Making controversial changes to the network, and not wanting to face the
reality that block chain space is a finite resource - whether enforced by a
consensus rule or by miner's capacity to process transactions - is a huge
treat to Bitcoin's usefulness in the long term.
I think the risks of trying to make a controversial change to the network
FAR outweighs the benefits of a small constant factor that "kicks the can
down the road".
Let's scale the block size gradually over time, according to technological
growth.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/fcd26023/attachment.html>;