<div dir="ltr">Is there any up to date documentation about TheBlueMatt relay network including what kind of block compression it is currently doing? (apart from the source code)<div><br><div>Regards, Sergio.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Aug 5, 2015 at 9:19 PM, Arnoud Kouwenhoven - Pukaki Corp<br>
<<a href="mailto:arnoud@pukaki.bz">arnoud@pukaki.bz</a>> wrote:<br>
> Thanks for this (direct) feedback. It would make sense that if blocks can be<br>
> submitted using ~5kb packets, that no further optimizations would be needed<br>
> at this point. I will look into the relay network transmission protocol to<br>
> understand how it works!<br>
><br>
> I hear that you are saying that this network solves speed of transmission<br>
> and thereby (technical) block size issues. Presumably it would solve speed<br>
> of block validation too by prevalidating transactions.<br>
<br>
<br>
</span>Correct. Bitcoin Core has cached validation for many years now... if<br>
not for that and other optimizations, things would be really broken<br>
right now. :)<br>
<span class=""><br>
> Assuming this is all<br>
> true, and I have no reason to doubt that at this point, I do not understand<br>
> why there is any discussion at all about the (technical) impact of large<br>
</span>> blocks, why there are large numbers of miners building on invalid blocks<br>
<span class="">> (SPV mining, <a href="https://bitcoin.org/en/alert/2015-07-04-spv-mining" rel="noreferrer" target="_blank">https://bitcoin.org/en/alert/2015-07-04-spv-mining</a>), or why<br>
> there is any discussion about the speed of block validation (cpu processing<br>
> time to verify blocks and transactions in blocks being a limitation).<br>
<br>
</span>I'm also mystified by a lot of the large block discussion, much of it<br>
is completely divorced from the technology as deployed; much less what<br>
we-- in industry-- know to be possible. I don't blame you or anyone in<br>
particular on this; it's a new area and we don't yet know what we need<br>
to know to know what we need to know; or to the extent that we do it<br>
hasn't had time to get effectively communicated.<br>
<br>
The technical/security implications of larger blocks are related to<br>
other things than propagation time, if you assume people are using the<br>
available efficient relay protocol (or better).<br>
<br>
SPV mining is a bit of a misnomer (If I coined the term, I'm sorry).<br>
What these parties are actually doing is blinding mining on top of<br>
other pools' stratum work. You can think of it as sub-pooling with<br>
hopping onto whatever pool has the highest block (I'll call it VFSSP<br>
in this post-- validation free stratum subpooling). It's very easy to<br>
implement, and there are other considerations.<br>
<br>
It was initially deployed at a time when a single pool in Europe has<br>
amassed more than half of the hashrate. This pool had propagation<br>
problems and a very high orphan rate, it may have (perhaps<br>
unintentionally) been performing a selfish mining attack; mining off<br>
their stratum work was an easy fix which massively cut down the orphan<br>
rates for anyone who did it. This was before the relay network<br>
protocol existed (the fact that all the hashpower was consolidating on<br>
a single pool was a major motivation for creating it).<br>
<br>
VFSSP also cuts through a number of practical issues miners have had:<br>
Miners that run their own bitcoin nodes in far away colocation<br>
(>100ms) due to local bandwidth or connectivity issues (censored<br>
internet); relay network hubs not being anywhere near by due to<br>
strange internet routing (e.g. japan to china going via the US for ...<br>
reasons...); the CreateNewBlock() function being very slow and<br>
unoptimized, etc. There are many other things like this-- and VFSSP<br>
avoids them causing delays even when you don't understand them or know<br>
about them. So even when they're easily fixed the VFSSP is a more<br>
general workaround.<br>
<br>
Mining operations are also usually operated in a largely fire and<br>
forget manner. There is a long history in (esp pooled) mining where<br>
someone sets up an operation and then hardly maintains it after the<br>
fact... so some of the use of VFSSP appears to just be inertia-- we<br>
have better solutions now, but they they work to deploy and changing<br>
things involves risk (which is heightened by a lack of good<br>
monitoring-- participants learn they are too latent by observing<br>
orphaned blocks at a cost of 25 BTC each).<br>
<br>
One of the frustrating things about incentives in this space is that<br>
bad outcomes are possible even when they're not necessary. E.g. if a<br>
miner can lower their orphan rate by deploying a new protocol (or<br>
simply fixing some faulty hardware in their infrastructure, like<br>
Bitcoin nodes running on cheap VPSes with remote storage) OR they can<br>
lower their orphan rate by pointing their hashpower at a free<br>
centeralized pool, they're likely to do the latter because it takes<br>
less effort.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>