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

> 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.
Bitcoin-development mailing list

Reply via email to