rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2015-05-08 📝 Original message:> > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of them are > implemented today. With a 20mb cap, miners still have the option of the soft limit. I would actually be quite surprised if there were no point along the road from 1mb to 20mb where miners felt a need to throttle their block sizes artificially, for the exact reason you point out: propagation delays. But we don't *need* to have fancy protocol upgrades implemented right now. All we need is to demolish one bottleneck (the hard cap) so we can then move on and demolish the next one (whatever that is, probably faster propagation). Scaling is a series of walls we punch through as we encounter them. One down, onto the next. We don't have to tackle them all simultaneously. FWIW I don't think the GFW just triggers packet loss, these days. It's blocked port 8333 entirely. * I'd very much like to see someone working on better scaling > technology ... I know StrawPay is working on development, > So this request is already satisfied, isn't it? As you point out, expecting more at this stage in development is unreasonable, there's nothing for anyone to experiment with or commit to. They have code here, by the way: https://github.com/strawpay You can find their fork of MultiBit HD, their implementation library, etc. They've contributed patches and improvements to the payment channels code we wrote. > * I'd like to see some better conclusions to the discussion around > long-term incentives within the system. > What are your thoughts on using assurance contracts to fund network security? I don't *know* if hashing assurance contracts (HACs) will work. But I don't know they won't work either. And right now I'm pretty sure that plain old fee pressure won't work. Demand doesn't outstrip supply forever - people find substitutes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/431f2412/attachment.html>