<html><head></head><body>No, don't think so, the protocol is, essentially, relay transactions, when you get a block, send header, iterate over transactions, for each, either use two bytes for nth-recent-transaction-relayed, use 0xffff-3-byte-length-transaction-data. There are quite a few implementation details, and lots of things could be improved, but that is pretty much how it works.<br>
<br>
Matt<br><br><div class="gmail_quote">On August 6, 2015 7:16:56 PM GMT+02:00, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div></body></html>