<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> * Though there are many proposals floating around which could<br>
significantly decrease block propagation latency, none of them are<br>
implemented today. </blockquote><div><br></div><div>With a 20mb cap, miners still have the option of the soft limit.</div><div><br></div><div>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.</div><div><br></div><div>But we don't <i>need</i> 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.</div><div><br></div><div>FWIW I don't think the GFW just triggers packet loss, these days. It's blocked port 8333 entirely.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> * I'd very much like to see someone working on better scaling<br>
technology ... I know StrawPay is working on development,<br></blockquote><div><br></div><div>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.</div><div><br></div><div>They have code here, by the way:</div><div><br></div><div> <a href="https://github.com/strawpay">https://github.com/strawpay</a><br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* I'd like to see some better conclusions to the discussion around<br>
long-term incentives within the system.<br></blockquote><div><br></div><div>What are your thoughts on using assurance contracts to fund network security?</div><div><br></div><div>I don't <i>know</i> 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. </div></div></div></div>