[p2p-hackers] good-bye, Mnet, and good luck. I'm going commercial! plus my last design doc (fwd from zooko@zooko.com)
- Forwarded message from Zooko O'Whielacronx [EMAIL PROTECTED] - From: Zooko O'Whielacronx [EMAIL PROTECTED] Date: Tue, 8 Mar 2005 17:04:46 -0400 To: Peer-to-peer development. [EMAIL PROTECTED] Subject: [p2p-hackers] good-bye, Mnet, and good luck. I'm going commercial! plus my last design doc X-Mailer: Apple Mail (2.619.2) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] contents of this message: good-bye, Mnet, The Fully Connected Topology, Rate-Limited Structured Flood, A Nice Slow Network, Did you say 'BROADCAST SEARCH'? Persistent Tit-for-Tat == Bilateral Accounting Dear mnet-devel and p2p-hackers: I am about to accept an exciting job that will preclude me from contributing to open source projects in the distributed file-system space. I will miss the Mnet project! Good luck without me! I'm writing the following as a record of the most advanced design that I have thought of for Mnet. (See Acknowledgements section below.) Most or all of the design written below has previously been published in different web pages, e-mail messages, and IRC transcripts, and a brief presentation I made at Privacy Enhancing Technologies Workshop 2004. The design described below is almost but not quite what is currently implemented, by myself and others, in Mnet v0.7, available at [1]. *** Design of Mnet v0.7+: I. Network connectivity -- the Fully Connected Topology I.A. Local peer database. Each node remembers the nodeId of for each node that it has ever heard of or received a message from. There is a maximum number of nodeIds, in deference to memory and computation costs (your local memory and your local computation). I don't know what that maximum number should be. If you have more than the maximum number of nodeIds in your database, you can flush some of the least-recently-alive ones. I.B. Exponential Backoff. With every peer in your db is stored a deadness level. When the deadness level is equal to 0, that means that the most recent thing that happened is that you receive a message from that peer -- whether it was a reponse to a request of yours or if it were a request from him to you. We say that the peers with deadness level 0 are the live peers. If a peer has deadness level 1, then that means that the most recent time that you sent a request to that peer, he didn't write back. Now, whenever you want to choose from a set of peers in order to send a request to one of them, the set you choose from is all of the deadness level 0 peers, plus with 50% probability all of the deadness level 1 peers, plus with 25% probability all of the deadness level 2 peers, and so on. Deadness level 2 means that the peer was in deadness level 1, and you chose to query him (with 50% probability), and he didn't write back again. I.C. Lookup of Peer Contact Info. When you want to find the current contact info (i.e. current IP address+port number, or current Relay Server) for a peer, you send a query to a certain number of other peers (called MetaTrackers when they are serving this purpose) -- a lookup contact info query. How many peers? Approximately log(N) where N is the number of peers in your local peer database. Which peers? You use the Chord distribution -- you query the peer closest to your target, the one closest to the point halfway around the circle from your target, the one closest to the point a quarter of the way around the circle, and cetera. Obviously, you need to publish your current contact info to *your* MetaTrackers whenever you join the network or whenever your contact info changes. Your MetaTrackers are the peer in your db which is closest to you, the peer in your db which is closest to the point halfway around the circle, etc. I.D. Discovery of New Peers. Rate-Limited Structured Flood. Every 60 minutes, you send an update to each of your MetaTrackers. That update contains the list of the peerIds of every new peer. A new peer for this purpose is defined as follows: you've never before announced this peer to MetaTrackers, and this peer currently has deadness level 0 in your local db. If the complete (compressed) message containing the information about the new peers would exceed 256 KB, then select a random subset of the new peers to announce in this announcement so that the message doesn't exceed 256 KB. This is a rate-limited structured flood. The flooding nature of it means that eventually you will find out about the arrival of every new peer. The structured nature of it means that it will take only log(N) time intervals before you find out, and you will receive only (;-)) log(N) separate notifications of the arrival of a new peer. (And you will send log(N) separate announcements of new peers -- one announcement to each of your MetaTrackers.) The rate-limited nature of it means that if new peers are arriving so fast that these notifications would take more than log(N)*256 KB per hour
Duit Di BCA
Lihat Disini! http://tinyurl.com/4h6yn
E-mailpaysu.com Best Site For Get Paid To Read Mail
Hi Friends ! I just wanted to let you know about a great new Internet program called E-Mail Pays U! They pay you for simply reading email! To make it even better they will give you $10 just to join up. E-Mail Pays U will even pay you when your friends and family read e-mail! I know you'd like to earn some easy extra cash! It doesn't get any easier than this. signing up for FREE and earn a quick $10!! http://tinyurl.com/6tnru Join today and earn a FREE $10! E-mail Pays U is totally free, privacy-protected and the money is real! Best of luck,
Re: 73-56-Mediccations
Hello , Please Visit our Great Pharrma-Mail SH0P and Save up T0 75%. Vi raAm enCi isLe tra, And ag bi al vi manyother! Just try us and you will NOT be disappointed :) Have a nice day.
Re: SHA1 broken?
Ah. You meant as a principal in general. Of course the prevailing wisdom is to go from FPGAs to ASICs when you have heavy tasks. In Telecom equipment, however, there's a few issues that basically 'require' FPGAs. First, the standards change quite a bit, depending on which area you're in. For instance, RPR didn't really get settled until very recently. Second, your customers may ask for more or different kinds of functionality, so you may have a new release of firmware to address that. Putting the framing and/or PM on an FPGA while keeping the guts (eg, packet processing) on the main ASIC/processor allows you to swap out the trivial without a major heart transplant. In addition, there's probably the far more important issue of design cycle times. ASICs will take (at the very minimum) 18 months to create, and if you make a mistake early on and don't catch, you have to start all over again. For some fields that's just unacceptable. Then again, if you're looking for sheer, brute performance and design cycle times are not a limiting factor, ASICs are often the way to go. Even in a Variola Suitcase, however, I'd bet some of the trivial functions are off-loaded to an FPGA, though, for reasons above. -TD From: Riad S. Wahby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SHA1 broken? Date: Tue, 8 Mar 2005 13:26:48 -0600 Tyler Durden [EMAIL PROTECTED] wrote: Well, maybe I misunderstand your statement here, but in Telecom most heavy iron has plenty of FPGAs, and as far as I understand it, they more or less have to. Have to in what sense? If they're constantly reconfiguring the FPGAs (new software revs, or some sort of evolutionary learning process--- the latter not likely in telecom, of course), sure, they have to be on reprogrammable structures. If, on the other hand, you're building a custom hash cracking machine, you don't need to reconfigure your gates. You could design your parallelized SHA1 cracking machine and dump it onto a bunch of FPGAs, but if you really have unlimited resources you take the plunge into ASICs, at which point you can tighten your timing substantially. -- Riad S. Wahby [EMAIL PROTECTED]
Re: SHA1 broken?
Tyler Durden [EMAIL PROTECTED] wrote: Then again, if you're looking for sheer, brute performance and design cycle times are not a limiting factor, ASICs are often the way to go. Even in a Variola Suitcase, however, I'd bet some of the trivial functions are off-loaded to an FPGA, though, for reasons above. Oh, sure. Buy yourself the flexibility of the FPGA, e.g., by putting an FPGA on a huge DMA pipe. But don't count on the FPGA to do the brunt of the crunching once you've settled on an implementation. Note also that you can probably buy yourself lots of performance without increasing the design cycle time all that much by simply synthesizing (via Synopsys or the like) the same Verilog with which you would have programmed the FPGA. Buy (or pirate if you can; it's not like you're selling these things, so who cares about the IP issues?) a set of standard logic cells in the smallest process you can afford so that even the lion's share of the layout can be done in a completely automated fashion, and you're basically all set. -- Riad S. Wahby [EMAIL PROTECTED]
Re: [p2p-hackers] good-bye, Mnet, and good luck. I'm going commercial! plus my last design doc (fwd from zooko@zooko.com)
Zooko writes: I am about to accept an exciting job that will preclude me from contributing to open source projects in the distributed file-system space. I will miss the Mnet project! Good luck without me! Is there a network currently running? At one time, I had 5 gig of Mnet blockstore, but when months went by with no metatracking, and apparently, no running network, I grew bored and rm'ed it. I'm writing the following as a record of the most advanced design that I have thought of for Mnet. [Clippage]] Yes, well. My thoughts on this, and other distributed filesystems, are as follows. We have the following useful technologies. Swarmed downloads, erasure coding, distributed filesystem with global namespace, encryption, routing, accounting, and search. We have various systems which have implemented a various subsets of these features, with varying degrees of efficiency. The killer technology amongst all these is obviously swarmed downloading, which, efficiently implemented in Bittorrent, currently accounts for a third of network bandwidth. The two systems which implement the most of the above technologies, Mnet and Freenet, while theoretically lovely, have at most a niche following, and are cumbersome to set up and use, with frequent issues in their protocols and codebase. Now, I think we can all agree that it would be lovely to have a distributed filesystem, with a global namespace, that anyone can put stuff in, and take stuff out of, which guarantees anonymity for both producers and consumers of content, swarms downloads, has an redundant distributed encrypted backing store that lasts forever, is easily and quickly searched, can be instantly set up by anyone who wishes to use it, never breaks, and starves users who unreasonably leech large amounts of resources without reciprocating. BUT, given that bittorrent is a wild success, which people ACTUALLY USE, would it not make more sense to create such a system by augmenting bittorrent with the technologies it presently lacks, than by continuing development on other systems, many of them bloated and buggy, which have been around for years without managing to be made to work well, or attracting large numbers of happy and satisfied customers? If you had a thousand hours of genius programmer time, would you spend it embracing and extending Bittorrent, or shoveling through the indecipherable bowels of legacy Mnet and Freenet code? I think Mnet and Freenet were wonderful testbeds, which taught us all a lot about what does and doesn't work in grandiose P2P schemes. But Bittorrent is where the users are, and software without users is like network television programming without viewers. -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division Do What Thou Wilt Shall Be The Whole Of The Law
Re: [p2p-hackers] good-bye, Mnet, and good luck. I'm going commercial! plus my last design doc (fwd from zooko@zooko.com)
At 12:14 PM 3/9/2005, Eric Cordian wrote: If you had a thousand hours of genius programmer time, would you spend it embracing and extending Bittorrent, or shoveling through the indecipherable bowels of legacy Mnet and Freenet code? I worked with Bram and Zooko at Mojo Nation (where both BT and Mnet got their respective genesis) and was frankly surprised when the MPAA was so easily able to target and put out of commission BT's trackers. The exposure of the trackers was a prominent topic of MN planning discussions and its odd that precautions, like distributing the tracker functions into clients or hiding them inside a TOR-like proxy network weren't taken earlier. Steve
Re: I'll show you mine if you show me, er, mine
-- However, techniques that establish that the parties share a weak secret without leaking that secret have been around for years -- Bellovin and Merritt's DH-EKE, David Jablon's SPEKE. And they don't require either party to send the password itself at the end. They are heavily patent laden, although untested last time I looked. This has been discouraging to implementers. There seem to be a shitload of protocols, in addition to SPEKE and DH-EKE A password protocol should have the following properties: 1. It should identify both parties to each other, that is to say, be secure against replay and man in the middle attacks, in particular, strong against phishing.. It should be secure against replay and dictionary attacks by an evesdropper or man-in-the-middle. Such an attacker should be able to no better than someone who just tries repeatedly to log on to the server with a guessed password 2. It should be as strong as practical against offline attacks by the server itself. The server operators, or someone who has stolen information from them, should not know the users password, and dictionary attacks should be sufficiently expensive that a strong password (not your ordinary password) is secure. Can anyone suggest a well reviewed, unpatented, protocol that has the desired properties? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG A8bCmCXDTAX2Syg907T7uRpajs77l9CqLEii+ezP 42zQDcP3xJXtcLPSgCVa55kew+ALkrQ/I50PFm9lC
Re: SHA1 broken?
Tyler Durden [EMAIL PROTECTED] wrote: Then again, if you're looking for sheer, brute performance and design cycle times are not a limiting factor, ASICs are often the way to go. Even in a Variola Suitcase, however, I'd bet some of the trivial functions are off-loaded to an FPGA, though, for reasons above. Oh, sure. Buy yourself the flexibility of the FPGA, e.g., by putting an FPGA on a huge DMA pipe. But don't count on the FPGA to do the brunt of the crunching once you've settled on an implementation. Note also that you can probably buy yourself lots of performance without increasing the design cycle time all that much by simply synthesizing (via Synopsys or the like) the same Verilog with which you would have programmed the FPGA. Buy (or pirate if you can; it's not like you're selling these things, so who cares about the IP issues?) a set of standard logic cells in the smallest process you can afford so that even the lion's share of the layout can be done in a completely automated fashion, and you're basically all set. -- Riad S. Wahby [EMAIL PROTECTED]
Re: SHA1 broken?
Ah. You meant as a principal in general. Of course the prevailing wisdom is to go from FPGAs to ASICs when you have heavy tasks. In Telecom equipment, however, there's a few issues that basically 'require' FPGAs. First, the standards change quite a bit, depending on which area you're in. For instance, RPR didn't really get settled until very recently. Second, your customers may ask for more or different kinds of functionality, so you may have a new release of firmware to address that. Putting the framing and/or PM on an FPGA while keeping the guts (eg, packet processing) on the main ASIC/processor allows you to swap out the trivial without a major heart transplant. In addition, there's probably the far more important issue of design cycle times. ASICs will take (at the very minimum) 18 months to create, and if you make a mistake early on and don't catch, you have to start all over again. For some fields that's just unacceptable. Then again, if you're looking for sheer, brute performance and design cycle times are not a limiting factor, ASICs are often the way to go. Even in a Variola Suitcase, however, I'd bet some of the trivial functions are off-loaded to an FPGA, though, for reasons above. -TD From: Riad S. Wahby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SHA1 broken? Date: Tue, 8 Mar 2005 13:26:48 -0600 Tyler Durden [EMAIL PROTECTED] wrote: Well, maybe I misunderstand your statement here, but in Telecom most heavy iron has plenty of FPGAs, and as far as I understand it, they more or less have to. Have to in what sense? If they're constantly reconfiguring the FPGAs (new software revs, or some sort of evolutionary learning process--- the latter not likely in telecom, of course), sure, they have to be on reprogrammable structures. If, on the other hand, you're building a custom hash cracking machine, you don't need to reconfigure your gates. You could design your parallelized SHA1 cracking machine and dump it onto a bunch of FPGAs, but if you really have unlimited resources you take the plunge into ASICs, at which point you can tighten your timing substantially. -- Riad S. Wahby [EMAIL PROTECTED]
Re: [p2p-hackers] good-bye, Mnet, and good luck. I'm going commercial! plus my last design doc (fwd from zooko@zooko.com)
Zooko writes: I am about to accept an exciting job that will preclude me from contributing to open source projects in the distributed file-system space. I will miss the Mnet project! Good luck without me! Is there a network currently running? At one time, I had 5 gig of Mnet blockstore, but when months went by with no metatracking, and apparently, no running network, I grew bored and rm'ed it. I'm writing the following as a record of the most advanced design that I have thought of for Mnet. [Clippage]] Yes, well. My thoughts on this, and other distributed filesystems, are as follows. We have the following useful technologies. Swarmed downloads, erasure coding, distributed filesystem with global namespace, encryption, routing, accounting, and search. We have various systems which have implemented a various subsets of these features, with varying degrees of efficiency. The killer technology amongst all these is obviously swarmed downloading, which, efficiently implemented in Bittorrent, currently accounts for a third of network bandwidth. The two systems which implement the most of the above technologies, Mnet and Freenet, while theoretically lovely, have at most a niche following, and are cumbersome to set up and use, with frequent issues in their protocols and codebase. Now, I think we can all agree that it would be lovely to have a distributed filesystem, with a global namespace, that anyone can put stuff in, and take stuff out of, which guarantees anonymity for both producers and consumers of content, swarms downloads, has an redundant distributed encrypted backing store that lasts forever, is easily and quickly searched, can be instantly set up by anyone who wishes to use it, never breaks, and starves users who unreasonably leech large amounts of resources without reciprocating. BUT, given that bittorrent is a wild success, which people ACTUALLY USE, would it not make more sense to create such a system by augmenting bittorrent with the technologies it presently lacks, than by continuing development on other systems, many of them bloated and buggy, which have been around for years without managing to be made to work well, or attracting large numbers of happy and satisfied customers? If you had a thousand hours of genius programmer time, would you spend it embracing and extending Bittorrent, or shoveling through the indecipherable bowels of legacy Mnet and Freenet code? I think Mnet and Freenet were wonderful testbeds, which taught us all a lot about what does and doesn't work in grandiose P2P schemes. But Bittorrent is where the users are, and software without users is like network television programming without viewers. -- Eric Michael Cordian 0+ O:.T:.O:. Mathematical Munitions Division Do What Thou Wilt Shall Be The Whole Of The Law
