[bitcoin-dev] Block size following technological growth

[Jameson Lopp]

I fully expect that new layers will someday allow us to facilitate higher
transaction volumes, though I'm concerned about the current state of the
network and the fact that there are no concrete timelines for the rollout
of aforementioned high volume networks.

As for reasoning behind why users will still need to settle on-chain even
with the existence of high volume networks, see these posts:

http://sourceforge.net/p/bitcoin/mailman/message/34119233/

http://sourceforge.net/p/bitcoin/mailman/message/34113067/

Point being, the scalability proposals that are currently being developed
are not magic bullets and still require the occasional on-chain settlement.
Larger blocks will be necessary with or without the actual scalability
enhancements.

- Jameson

On Thu, Jul 30, 2015 at 12:36 PM, Bryan Bishop <kanzure at gmail.com> wrote:

> On Thu, Jul 30, 2015 at 11:23 AM, Jameson Lopp via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Stated differently, if the cost or contention of using the network rises
>> to the point of excluding the average user from making transactions, then
>> they probably aren't going to care that they can run a node at trivial cost.
>
>
> That's an interesting claim; so suppose you're living in a future where
> transactions are summarizing millions or billions of other daily
> transactions, possibly with merkle hashes. You think that because a user
> can't individually broadcast his own personal transaction, that the user
> would not be interested in verifying the presence of a summarizing
> transaction in the blockchain? I'm just curious if you could elaborate on
> this effect. Why would I need to see my individual transactions on the
> network, but not see aggregate transactions that include my own?
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/b38ccb0a/attachment.html>