On Thursday 24 June 2010 04:05:48 Evan Daniel wrote:
On Wed, Jun 23, 2010 at 5:43 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Wednesday 23 June 2010 20:33:50 Sich wrote:
Le 23/06/2010 21:01, Matthew Toseland a écrit :
Insert a random, safe key
This is much safer than the
On Thursday 24 June 2010 18:28:42 Matthew Toseland wrote:
On Thursday 24 June 2010 04:05:48 Evan Daniel wrote:
On Wed, Jun 23, 2010 at 5:43 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Wednesday 23 June 2010 20:33:50 Sich wrote:
Le 23/06/2010 21:01, Matthew Toseland a écrit
On Thursday 24 June 2010 18:28:42 Matthew Toseland wrote:
On Thursday 24 June 2010 04:05:48 Evan Daniel wrote:
On Wed, Jun 23, 2010 at 5:43 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Wednesday 23 June 2010 20:33:50 Sich wrote:
Le 23/06/2010 21:01, Matthew Toseland a écrit
On Thursday 24 June 2010 18:28:42 Matthew Toseland wrote:
On Thursday 24 June 2010 04:05:48 Evan Daniel wrote:
On Wed, Jun 23, 2010 at 5:43 PM, Matthew Toseland
t...@amphibian.dyndns.org wrote:
On Wednesday 23 June 2010 20:33:50 Sich wrote:
Le 23/06/2010 21:01, Matthew Toseland a écrit
On Wed, Jun 23, 2010 at 5:43 PM, Matthew Toseland
wrote:
> On Wednesday 23 June 2010 20:33:50 Sich wrote:
>> Le 23/06/2010 21:01, Matthew Toseland a ?crit :
>> > Insert a random, safe key
>> > This is much safer than the first option, but the key will be different
>> > every time you or somebody
the data as fast or as
slow as possible. It is compatible with sneakernet, it is compatible with CBR
links.
Ideas? Challenges? Suggestions for how to deal with opennet in this framework?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20100624/0339c74a/attachment.pgp>
you are vulnerable. So either:
1) We route once, and reroute downstream. I.e. full passive requests. Which
would combine very neatly with passive requests - when a peer comes online,
check its bloom filters for anything that you or any of your pending requests
want. However, this is a big step beyo
y them anyway, by the timestamp being the same (or very
close, but that might allow some window for progression for attackers), or by
correlated keys (for requests).
2. We can then round-robin between them. So we send a bundle asking for a
freesite, and we expect it to complete more quickly than the bundle we sent
requesting a (gnu/hurd!) DVD ISO.
3. We can send the requests more efficiently, we don't need one message for
each request, we can send a bulk transfer with all the keys, the first block or
even a separate message specifies the HTL, etc. Okay it might be possible to
compress requests anyway ... but it makes more sense if it's a bundle ...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20100624/8b3ae1fb/attachment.pgp>
ata,
because there is no abort. If an alternative route to A is found, then C will
have less reason to penalise B if (when!) it reconnects.
Should there be an abort option? The problem is that being able to start a
transfer and then abort it facilitates censorship attacks. Classically Freenet
resists censorship because if you fetch a key and take out the node that
returned it, the data will have been cached downstream.
We should check fairly urgently whether the current code allows for aborting
transfers all the way down, I think it did but I fixed it.
Another interesting point with all this is it requires quite a lot of disk
space - the maximum in-flight data for each peer.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20100624/23adbc10/attachment.pgp>
