Re: [bitcoin-dev] Bitcoin Core and hard forks

[Eric Lombrozo <elombrozo@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4043 bytes --]

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo@gmail.com <mailto:elombrozo@gmail.com>> wrote:
> 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.’

I should also point out, improvements in hardware and network infrastructure can also reduce costs…and we could very well have a model where resource requirements can be increased as technology improves. However, currently, the computational cost of validation is clearly growing far more quickly than the cost of computational resources is going down. There are 7,000,000,000 people in the world. Payment networks in the developed world already regularly handle thousands of transactions a second. Even with highly optimized block propagation, pruning, and signature validation, we’re still many orders shy of being able to satisfy demand. To achieve mainstream adoption, we’ll have to pass through a period of quasi-exponential growth in userbase (until the market saturates…or until the network resources run out). Unless we’re able to achieve a validation complexity of O(polylog n) or better, it’s not a matter of having a negative attitude about the prospects…it’s just math. Whether we have 2MB or 20MB or 100MB blocks (even assuming the above mentioned optimizations and that the computational resources exist and are willing to handle it) we will not be able to satisfy demand if we insist on requiring global validation for all transactions.


> On Jul 23, 2015, at 1:26 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
> 
> On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 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.
> 
> Although I don't have a concrete proposals myself, I agree that
> without having any common notion of what the "minimal target hardware"
> looks like, it is very difficult to discuss other things that depend
> on that.
> If there's data that shows that a 100 usd raspberry pi with a 1 MB
> connection in say, India (I actually have no idea about internet
> speeds there) size X is a viable full node, then I don't think anybody
> can reasonably oppose to rising the block size to X, and such a
> hardfork can perfectly be uncontroversial.
> I'm exaggerating ultra-low specifications, but it's just an example to
> illustrate your point.
> There was a thread about formalizing such "minimum hardware
> requirements", but I think the discussion simply finished there:
> - Let's do this
> - Yeah, let's do it
> - +1, let's have concrete values, I generally agree.


[-- Attachment #1.2: Type: text/html, Size: 5414 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]