On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley <kezi...@gmail.com> wrote: >> the need to have transmitted the transaction list [..] first > > 32 bits per transaction is at least double the communication overhead > of the simple approach, and only offers a bound on the probability of > needing a round trip.
"(e.g. from a reconciliation step first)" the list can be communicated in the space roughly equal to the size of the difference in sets plus coding the permutation from the permissible orderings. If you did have some "simple approach" that guaranteed that some transactions would be present, then you could code those with indexes... the FEC still lets you fill in the missing transactions without knowing in advance all that will be missing. (Also, the suggestion on the network block coding page of using part of a cryptographic permutation as the key means that for unknown transactions the transmission of the new unknown keys is always goodput— doesn't add overhead) It's "only a bound" but you can pick whatever bound you want, including— if you send data equal to the missing amount, then it'll be always successful, but no bandwidth savings. Though if the transport is unordered (e.g. UDP or non-blocking SCTP) even sending 100% of the missing amount can save time by eliminating a round trip that might otherwise be needed for a retransmission. ------------------------------------------------------------------------------ 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
