#1 Forward error correction

[Anonymous]

This feature is importend, it was not implemented in OFF SYSTEM.

I suspect that Blocksnet has the same problem as OFFSystem (no redundancy in the blocks, so stay put blocks in the absence of the downloads at 99%, Freenet uses as a remedy FEC (Forward error correction)

http://en.wikipedia.org/wiki/Forward_error_correction

[da1l6]

Error correction in OFF is NOT trivial to implement. Standard Error correction methods like Reed Solomon codes or Parity bits are not applicable, because (depending on implementation) they suffer either from
- Security problems because error correction data is saved directly in the cache (not "owner free")
- Non-recoverable losses. If the error correction data is run through the store process it can't correct its own blocks if more than one in a tuple is lost.

If you have ideas on the problem, i'd like to hear them.

da1l6

[Nobody/Anonymous]

Freenet uses FEC for preventing a fast decay of huge files because some blocks falling out of the network is normal.
An example: If a file has 100 individual blocks and the FEC-algorithm creates a 30% redundancy, then we get 100 blocks plus 30 FEC-blocks. When some blocks are unavailable then it's possible to recreate them, but you must be able to get at least total 100 blocks for a successful download (one FEC-block can substitute one random original block). Freenet extracts the original file from the 100 original blocks.
"Healing" means the recreation of FEC blocks from the original file and re-inserting of original and FEC blocks into Freenet, this is important to delay the decay process.

About security problems: FEC-blocks aren't "owner free", because they're bound to the original blocks. The more blocks from a file are downloaded the better are statistical attacks. It's not a problem in Freenet because all blocks are encrypted.
In blocksnet it's perhaps necessary to encrypt the FEC-blocks. The key is stored in the description-block, perhaps it's the hashvalue of this FEC-block (this means an FEC-block needs two values: hash of the encrypted FEC-block and the key to extract the real FEC-block...)

About non-recoverable losses: Creating FEC-blocks similar to Freenet means that we need all necessary blocks for creating the FEC-blocks over all blocks of a file. This is a flexible solution because it doesn't matter which blocks aren't any more available.
Creating one FEC-block per every tuple leads to 33% recundancy, this is the same redundancy as with 33% FEC over all blocks. But I think it's not useful this way, because IMHO the block availability rate is at the file beginning higher than at the file end (users stopping the downloads).

MfG,
Nemo.

[Nobody/Anonymous]

Encrypting data does not make it more or less owner free. This does not solve any problem.

I don't understand your comment about recoverability. The problem is that if FEC data is not owner free, it must be inserted (encoded into blocks). But this means that it can't recover its own blocks any more if more than one in a tuple is lost.