Jameson Lopp [ARCHIVE] on Nostr: đź“… Original date posted:2015-07-23 đź“ť Original message:On Thu, Jul 23, 2015 at ...
đź“… Original date posted:2015-07-23
đź“ť Original message:On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>
> Larger block sizes don't scale the network, they merely increase how much
> load we allow the network to bear.
>
>
> Very well put, Jameson. And the cost of bearing this load must be paid
> for. And unless we’re willing to accept that computational resources are
> finite and subject to the same economic issues as any other finite
> resource, our incentive model collapses the security of the network will be
> significantly at risk. Whatever your usability concerns may be regarding
> fees, when the security model’s busted usability issues are moot.
>
> Larger blocks support more transactions…but they also incur Ω(n) overhead
> in bandwidth, CPU, and space. These are finite resources that must be paid
> for somehow…and as we all already know miners are willing to cut corners on
> all this and push the costs onto others (not to mention wallets and online
> block explorers). And who can really blame them? It’s rational behavior
> given the skewed incentives.
>
Running a node certainly has real-world costs that shouldn't be ignored.
There are plenty of advocates who argue that Bitcoin should strive to keep
it feasible for the average user to run their own node (as opposed to
Satoshi's vision of beefy servers in data centers.) My impression is that
even most of these advocates agree that it will be acceptable to eventually
increase block sizes as resources become faster and cheaper because it
won't be 'pricing out' the average user from running their own node. If
this is the case, it seems to me that we have a problem given that there is
no established baseline for the acceptable performance / hardware cost
requirements to run a node. I'd really like to see further clarification
from these advocates around the acceptable cost of running a node and how
we can measure the global reduction in hardware and bandwidth costs in
order to establish a baseline that we can use to justify additional
resource usage by nodes.
- Jameson
>
> On the flip side, the scalability proposals will still require larger
> blocks if we are ever to support anything close to resembling "mainstream"
> usage. This is not an either/or proposition - we clearly need both.
>
>
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/9407b8c4/attachment.html>;
đź“ť Original message:On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> On Jul 23, 2015, at 11:10 AM, Jameson Lopp <jameson.lopp at gmail.com> wrote:
>
> Larger block sizes don't scale the network, they merely increase how much
> load we allow the network to bear.
>
>
> Very well put, Jameson. And the cost of bearing this load must be paid
> for. And unless we’re willing to accept that computational resources are
> finite and subject to the same economic issues as any other finite
> resource, our incentive model collapses the security of the network will be
> significantly at risk. Whatever your usability concerns may be regarding
> fees, when the security model’s busted usability issues are moot.
>
> Larger blocks support more transactions…but they also incur Ω(n) overhead
> in bandwidth, CPU, and space. These are finite resources that must be paid
> for somehow…and as we all already know miners are willing to cut corners on
> all this and push the costs onto others (not to mention wallets and online
> block explorers). And who can really blame them? It’s rational behavior
> given the skewed incentives.
>
Running a node certainly has real-world costs that shouldn't be ignored.
There are plenty of advocates who argue that Bitcoin should strive to keep
it feasible for the average user to run their own node (as opposed to
Satoshi's vision of beefy servers in data centers.) My impression is that
even most of these advocates agree that it will be acceptable to eventually
increase block sizes as resources become faster and cheaper because it
won't be 'pricing out' the average user from running their own node. If
this is the case, it seems to me that we have a problem given that there is
no established baseline for the acceptable performance / hardware cost
requirements to run a node. I'd really like to see further clarification
from these advocates around the acceptable cost of running a node and how
we can measure the global reduction in hardware and bandwidth costs in
order to establish a baseline that we can use to justify additional
resource usage by nodes.
- Jameson
>
> On the flip side, the scalability proposals will still require larger
> blocks if we are ever to support anything close to resembling "mainstream"
> usage. This is not an either/or proposition - we clearly need both.
>
>
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/9407b8c4/attachment.html>;