npub1az…t2krq on Nostr: 📅 Original date posted:2015-07-23 📝 Original message:> On Jul 23, 2015, at 4:42 ...

📅 Original date posted:2015-07-23
📝 Original message:> On Jul 23, 2015, at 4:42 PM, Benedict Chan <bencxr at fragnetics.com> wrote:
>
> Scaling the network will come in the form of a combination of many
> optimizations. Just because we do not know for sure how to eventually
> serve 7 billion people does not mean we should make decisions on
> global validation that impact our ability to serve the current set of
> users.

Agreed. But I believe the economic and security arguments I gave regarding fees and incentives still hold and are largely separate from the scalability issue. Please correct me if I overlooked something.


> Also, blocking a change because it's "more important to address issues
> such as..." other improvements will further slow down the discussion.
> I believe an increase will not prevent the development of other
> improvements that we need - in contrast, the sooner we can get over
> the limit (which, as you agree, needs to be changed at some point),
> the sooner we can get back to work.

An increase in block size at this time will exacerbate security concerns around nodes relying on other nodes to validate (particularly miners and wallets). It’s not really a matter of having limited developer resources that need to be budgeted, as you seem to suggest.

Regarding developments on properly handling fees, there must exist the economic need for it before there’s an earnest effort to solve it. Increasing the block size right now will, in all likelihood, delay this effort. I’d much prefer to first let the fee market evolve because it’s a crucial component to the protocol’s design and its security model…and so we can get a better sense for fee economics. Then we might be able to figure out better approaches to block size changes in the future that makes sense economically…perhaps with mechanisms that can dynamically adjust it to reflect resource availability and network load.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/7bcddf71/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/7bcddf71/attachment.sig>;