On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley <kezi...@gmail.com> wrote: >> the FEC still lets you fill in the missing transactions without knowing in >> advance all that will be missing. > > I don't see why we need to solve that problem, since the protocol > already involves exchanging the information necessary to determine > (with some false positives) what a peer is missing, and needs to > continue doing so regardless of how blocks are transmitted.
False positives, and if you have more than one peer— false negatives. (or a rule for what you must keep which is conservative in order to avoid creating huge storage requirements— but then also has false negatives). > As far as I can tell, channel memory sparseblocks achieve most of the > possible bandwidth savings, and when FEC-based mempool synchronization > is implemented its benefits can be applied to the sparseblocks by > resetting the channel memory to the mutual mempool state each time > mempool differences are exchanged. Am I missing a benefit to doing FEC > at block forwarding time that can't be realized by FEC-based mempool > synchronization, implemented separately from channel-memory based > index-coding? Yes, minimizing latency in the face of multiple peers. Otherwise no. And certantly no reason to to implement something simple first. ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
