<div dir="ltr">Two more half-baked thoughts:<div><br></div><div>We should be able to assume that the majority of transaction data (except for coinbase) has already been propagated. As Jeff said, incentivizing nodes to propagate transactions is a very good thing (the signature cache already gives a small incentive to miners to propagate and not &#39;hoard&#39; transactions).</div>
<div><br></div><div>So the only information that theoretically needs to be propagated is which transactions a miner is including in their block, and in what order they are included.</div><div><br></div><div>But if there was some agreed-upon canonical ordering, then it should theoretically be possible to take shortcuts in the &quot;what order&quot;.</div>
<div><br></div><div>You&#39;d start with setof(transactions I think everybody knows about)</div><div>Select some subset, based on miner&#39;s policy</div><div>Sort that subset with the canonical ordering algorithm</div><div>
Very efficiently broadcast, taking all sorts of shortcuts assuming most of your peers already know the set you started with and expect the same canonical ordering (see gmaxwell&#39;s thoughts on block encoding).</div><div>
<br></div><div>Second half-baked thought:</div><div>I wonder if broadcasting your transaction selection policy (&quot;11KB of free transactions, sorted by priority, then 111K of fee-paying transactions, sorted by fee&quot;) might make it possible to save even more bandwidth by letting your peers create a very good approximation of your block with just that information....</div>
<div class="gmail_extra"><div class="gmail_quote"><br></div>-- <br>--<br>Gavin Andresen<br>
</div><div class="gmail_extra"><br></div></div>