This is an initiative that definitely needs community as well as external support. It isn't as simple as tweaking a few lines of code in bitcoin-qt. And glad to see that Stanford is behind this, at least in part. As a former Cal bear though, we have our differences. Lol  |
|
|
|
An ASIC for folding ... I'd love to see that. This isn't a hash function we're talking about here. Folding (at least decent algos) is quite a bit more complicated (even talking about the basic molecular dynamics calcs, much more if you're going to introduce solvation models, etc). Also, folding is very much a floating-point intensive operation, which is really tough to do on ASIC, unlike hash functions. The more fundamental problem is that most folding algos are amenable to parallelization only up to the # of atoms in your system - if your system doesn't have more than 2000 atoms, for instance, then 2000 or 4000 cores doesn't really make a difference. That said if a pharma really wants to invest millions into this project, well that would simply serve to validate its existence. Similarly to how ASIC development is supporting BTC's existence. And no, folding doesn't "cure cancer". It does though make the development of targeted drugs against proteins a whole lot easier (for cancer as well as other diseases). If you're going to hit something, it sure is helpful to know what you're actually hitting, and that's part of the problem that protein folding can address. The field as a whole has moved on from studying intact proteins to trying to study the effects of mutations (i.e. why does mutated B-amyloid aggregate more in Alzheimer's?), or trying to do drug-protein docking (to find better inhibitors, etc). BTW, there are already competitions for protein folding, the most well known of which is CASP: http://predictioncenter.org/casp10/index.cgi ... every year, they give out sequences to researchers all over the world, and hold a structure in secret that has been solved (with X-ray crystallography or EM) before, but not published. Scientists then publish their predictions, and they are compared to the structures that they have for a ranking, which are then released. |
|
|
|
Folding is, or at least, should be amenable to a proof-of-work function. I'm studying molecular biology, so I can give more background. Basically, folding is PoW in that: 1. It's difficult to find a configuration that is "better" then the best so far. By "best", I am referring to the minimum free energy, or a similar score system, where the atoms in the protein are in a most energetically favorable state. That is analogous to "difficulty" - If difficulty increases, then the free energy criteria required to satisfy the "folded" criteria is smaller. This problem is difficult because of the vast configuration space of possible positions for each of the protein residues (something on the order of 3^300), otherwise known as Levinthal's paradox. 2. It's relatively simple to compute the free energy of the system. (More difficult than a hash, but much simpler than trying to find the minimum free energy structure). 3. If someone manages to "cheat" (find a structure with a good MFE in substantially less time than the rest), well that's called a scientific breakthrough. And that someone gets rewarded with a lot of coins. Probably the most direct incentivizing of R&D possible. Check out http://en.wikipedia.org/wiki/Foldit some time. Interesting concept. 1 & 2 sounds good, but the current folding projects contain some thousand atoms (or proteins, don't remember right now) place them in a 3d space ... we are talking about some mb here i would say way to much for a blockchain! bitcoin exists since 2009 and needs something like 8 gb currently, on average a bitcoin block is not more than 10k or so (arverage! currently more like 150) 3 would be great  (but unlikely) what about an attacker who simply takes all available atoms and throws them into a space search with heuristics? he may come up with a solution that has low energy but is unrealistic due to some folding rules. or is it really that "simple"? A PDB (structure) is ~500kB. DOn't know if that's too big or small, but for 10000, that is 5GB, less w/ compressing (compression ratio ~ 5:1 with 7-zip). Of course for additional structures beyond the initial set, this will increase further, don't know how much. No, folding is not that simple. Side chain residues only fit in certain ways; otherwise the sterics will blow the thing apart. MFE also takes into account bond lengths, charge, torsion and dihedral angles, hydrophobicity, all the way to to things like implicit solvation models (which folding@home uses a simplified version of). That said, you mention a valid concern that proteins may adopt "low energy" configs that are unrealistic. This mainly applies for very dynamic proteins, proteins that form multi-subunit complexes, transmembrane proteins, etc which all require special "rules" to fold properly, but this is kinda beyond my expertise here. To alleviate that, careful selection of the initial set of proteins that are stable, have reasonable dynamics, etc. will be required (by people smarter than me). The bounty system that I proposed can help if scientists can specify specific criteria, that can be checked easily (e.g. must have 2 alpha helices, Ser273 must not be in hydrophobic core, etc). This is complicated though, so I don't expect to see this in the first iteration of the client. http://www.ncbi.nlm.nih.gov/protein/YP_005795070.1 - the bottommost part with a lot of random letters is the actual sequence; the other stuff is identifying information that is useful generally and also for certain domain-based/homology-based folding algorithms (too complicated to discuss here).) What does it mean? You simply take this string and start folding? Is there no other protein or something? That string describes the amino acid residues on the protein (i.e. L = leucine, E = glutamic acid, etc). Any mediocre biologist has these memorized. See http://bioinformatics.istge.it/bcd/Curric/PrwAli/_18604_tabular513.gif . A protein is made up of a string of these, terminated by a NH3 (N-terminal side) and a COOH (C-terminal side). Other codes can be used to denote post-translation modifications (beyond the scope of this forum). As for a real project, I'm far too busy (medical school + graduate school) to seriously program anything, but I'm willing to look at code / give advice / refer to people smarter than me for further advice. |
|
|
|
Folding is, or at least, should be amenable to a proof-of-work function. I'm studying molecular biology, so I can give more background. Basically, folding is PoW in that: 1. It's difficult to find a configuration that is "better" then the best so far. By "best", I am referring to the minimum free energy, or a similar score system, where the atoms in the protein are in a most energetically favorable state. That is analogous to "difficulty" - If difficulty increases, then the free energy criteria required to satisfy the "folded" criteria is smaller. This problem is difficult because of the vast configuration space of possible positions for each of the protein residues (something on the order of 3^300), otherwise known as Levinthal's paradox. 2. It's relatively simple to compute the free energy of the system. (More difficult than a hash, but much simpler than trying to find the minimum free energy structure). 3. If someone manages to "cheat" (find a structure with a good MFE in substantially less time than the rest), well that's called a scientific breakthrough. And that someone gets rewarded with a lot of coins. Probably the most direct incentivizing of R&D possible. Check out http://en.wikipedia.org/wiki/Foldit some time. Interesting concept. For the technical stuff: 1. Structures to be solved will be determined by consensus, and are distributed as PubMed ID's / NCBI reference sequences (this is an example: http://www.ncbi.nlm.nih.gov/protein/YP_005795070.1 - the bottommost part with a lot of random letters is the actual sequence; the other stuff is identifying information that is useful generally and also for certain domain-based/homology-based folding algorithms (too complicated to discuss here).) 2. Clients download this, begin folding work (using any algorithm). Folding is a vast topic and the # of algorithms is just as vast. 3. Structures that are below a certain minimum free energy (need to determine the exact equation for this beforehand) will be returned as PDBs (example: http://pdb.org/pdb/explore/explore.do?structureId=4A8N - this is a crystal structure, but a computationally generated model looks similar). 4. Other clients verify - if this structure indeed is below a certain MFE, block reward is generated. |
|
|
|
|
"Some" amount of centralization will be required for the initial phase of this project, but this is what I see:
Folding blocks: (centralized portion in underline)
- A consensus of N proteins that need structures is arrived at (by the scientific community in collaboration with the coin authors). This times the block reward is the total # of coins in the pool.
Let's say 10000 proteins * 100 reward = 1M coins. We may also want a % to go towards some sort of bounty (below)
- Proteins are introduced at some fixed rate, and the order is determined by SHA256 of the previous block (folding or mining). This to prevent precomputation of folding work, and also prevents too much early hoarding.
- Difficulty retargets per last folding block.
- Once all proteins have been "solved", clients can attempt to solve existing blocks with the "current" difficulty at half block reward. This would be some sort of ratio between the "already solved difficulty" that would determine the new difficulty target. The reward can halve sequentially for each additional attempt, until it goes to zero.
- By default, clients will automatically attempt to solve proteins with the lowest difficulty.
Bounty system: (decentralized)
- Once all proteins in the initial 10000 set have been solved, scientists that want a new structure to be solved can post it as work with any arbitrary block reward / difficulty. These coins come from them personally (hence the above % for the bounty)
- Clients will automatically compete for these block rewards
- Once these proteins are solved, they too go into the "pool" that can be solved at sequentially higher difficulty. they don't go into the pool, unless the researcher puts up additional block rewards (this could happen automatically).
Mining blocks:
- Only for transaction processing
- No block reward
- Miners get transaction fees, of course.
- Difficulty is decoupled from folding difficulty (PPC style).
|
|
|
|
Folding is, or at least, should be amenable to a proof-of-work function. I'm studying molecular biology, so I can give more background. Basically, folding is PoW in that: 1. It's difficult to find a configuration that is "better" then the best so far. By "best", I am referring to the minimum free energy, or a similar score system, where the atoms in the protein are in a most energetically favorable state. That is analogous to "difficulty" - If difficulty increases, then the free energy criteria required to satisfy the "folded" criteria is smaller. This problem is difficult because of the vast configuration space of possible positions for each of the protein residues (something on the order of 3^300), otherwise known as Levinthal's paradox. 2. It's relatively simple to compute the free energy of the system. (More difficult than a hash, but much simpler than trying to find the minimum free energy structure). 3. If someone manages to "cheat" (find a structure with a good MFE in substantially less time than the rest), well that's called a scientific breakthrough. And that someone gets rewarded with a lot of coins. Probably the most direct incentivizing of R&D possible. Check out http://en.wikipedia.org/wiki/Foldit some time. Interesting concept. |
|
|
|
|
The fact that it's down is not helping...
|
|
|
|
|
Oh, it'll stabilize eventually. And one of the big factors that will contribute is something that the libertarian crypto-anarchists will hate - the traditional banking institutions. Simply put, institutions move slower (technically, their holdings have lower velocity). Hence, participation in bubbles and crashes will slow commensurately as more money total is involved. Yes, there will still be bubbles and crashes (just as there are with stocks, gold, USD, etc). But no, we won't see as many 40%+ moves in the future, simply because of greater (and slower) participation.
|
|
|
|
No, actually, it's called loss aversion. People tend to strongly prefer avoiding losses relative to acquiring gains, even if both forces are "strong". This has generally been understood as the source of violent declines (as well as rises) that are more frequent in bear markets, for a few centuries of history. (Interestingly, newer studies discount the phenomenon of loss aversion to instead prefer a competition-oriented model - behavioral finance is still an evolving field). And also no, sharing "investing strategies" does not make them any less valid; on the contrary, technical analysis "works" because people know about it (i.e. self-fulfilling prophecy) -- it's the exceptions that get you. People have been screaming about PE10 for the last couple of decades -- look how well that worked during the internet bubble and financial bubble. Now if someone wants to sell you a "proprietary investment strategy" or "wants you to invest in his strategy that he can't disclose because ... well, it's secret", those people you run away from, 10-foot pole or no. "This time it's different". No, it never is. |
|
|
|
|
Post count ... well.
I got interested in bitcoin actually from the real financial world. Though I don't have a finance degree (choosing instead to pursue medicine), I frequent Zerohedge and Seekingalpha, do some quantitative financial modeling, do transaction processing for academic institutions, and have traded for a decade and half so far (long-term, swing, or intraday on stocks, options, futures, commodities, forex). I imagine some other members with low post counts around here have similar experience.
|
|
|
|
A better analogy would be a deed, actually. It is a piece of paper that can fit in your pocket (Casascius coin, private key) granting a privilege (a claim to some value of bitcoins held at a public key) to an owner (you) that has a record of ownership (transactions). It's the best analogy I can think of, actually. |
|
|
|
Another potential contender: Bittorrent's "sync service". http://labs.bittorrent.com/experiments/sync/get-started.htmlP2P Protocol
BitTorrent Sync synchronizes your files using a peer-to-peer (P2P) protocol. This protocol is very effective for transferring large files across multiple devices, and is very similar to the powerful protocol used by applications like µTorrent and BitTorrent. The data is transferred in pieces from each of the syncing devices, and BitTorrent Sync chooses the optimal algorithm to make sure you have a maximum download and upload speed during the process.
The devices you setup to sync are connected directly using UDP, NAT traversal and UPnP port mapping. We also provide such additional methods of ensuring connectivity as relay and tracker servers. If your devices are on the same local network, BitTorrent Sync will use your LAN for faster synchronization.
Security
BitTorrent Sync was designed with privacy and security in mind. All the traffic between devices is encrypted with AES cypher and a 256-bit key created on the base of the secret—a random string (20 bytes or more) that is unique for every folder.
It’s our priority to make sure that nobody has unauthorized access to your folders. That’s why there are no 3rd party servers involved when syncing your files. All the files are stored only on your trusted devices, controlled and managed solely by you.
For the same reason we provide you with a quick and easy way to manage secrets. You can regularly change them and invite people by sharing a one-time secret instead of distributing a permanent one.
Secret
The secret is a randomly generated 21-byte key. It is Base32-encoded in order to be readable by humans. BitTorrent Sync uses dev/random (Mac, Linux) and the Crypto API (Windows) in order to produce a completely random string. This authentication approach is significantly stronger than a login/password combination used by other services. That's why using a secret generated by BitTorrent Sync is very safe and secure.
If you want even more security, BitTorrent Sync gives you a way to use a custom secret. Just create your own secret, encode it with Base64, and enter in the secret field for BitTorrent Sync. Note that a custom secret should be more than 40 characters long.
Peer Discovery
In order to find proper peers that have the same secret, Sync uses:
Local peer discovery. All peers inside local network are discovered by sending broadcast packets. If there are peers with the same secret they respond to the broadcast message and connect.
Peer exchange (PEX). When two peers are connected, they exchange information about other peers they know.
Known hosts (folder settings). If you have a known host with a static ip:port, you can specify this in Sync client, so that it connects to the peer using this information.
DHT. Sync uses DHT to distribute information about itself and obtain the information about other peers with this secret. Sync sends SHA2(Secret):ip:port to DHT to announce itself and will get a list of peers by asking DHT for the following key SHA2(Secret)
BitTorrent tracker. BitTorrent Sync can use a specific tracker server to facilitate peer discovery. The tracker server sees the combination of SHA2(secret):ip:port and helps peers connect directly. The BitTorrent Sync tracker also acts like a STUN server and can help do a NAT traversal for peers so that they can establish a direct connection even behind a NAT.
We recommend that you use a tracker server instead of DHT for reasons of faster response and NAT traversal, so peers have a higher probability of networking directly.
I'll need to read it in detail / actually try it out to comment on whether something like this can actually apply to this scheme. |
|
|
|
|
Around when it started appearing on Zerohedge/Seekingalpha (my favorite financial blogs).
Now if I had actually bought then ... well, anyways.
|
|
|
|
I image a kind of free "distributed dropbox" with huge capacity.
Is it possible to use proof of storage for a new coin? It would serve as a free distributed filesystem for people who need extra space. People who have extra space would earn coins.
If its even possible there's probably other ways to do it, but here is my way:
-nodes store segments of a file that someone wants backed up
-for each block, nodes agree on a random file segment in a distributed way.
-nodes retrieve the file segment asked for.
-nodes check that the file segment matches a one-way accumulator (or bloom filter?)
-nodes get coins in proportion to the amount of hard drive space they are contributing
Yep, but you can verify somebody else stores the same data only if you have it already as well. What you do is simple cookie authentication: a: generates a cookie like this: { r: random_bytes , sig: ecc_sign(random_bytes) } b: cookie.r == ecc_verify(cookie.sig), if ok then computes sha256(cookie + data_checked_ + cookie) and sends it to a a: does the same sha256 to verify b does indeed stores the data Imho it's impossible to check somebody owns the data without having it as well - if you have only hash of the data, they could have only the hash too and so on. If you can come up with scheme to actually verify storage w/o having it too, I'd be very interested in how to do that! There's also Bytecoin mentioned on the wiki, but its description was too wague for me. I think one-way-accumulators allow you to verify a bunch of data using a small amount of data. The small data piece is what is stored in the blockchain. I think bloom-filters are similar, but I am not an expert in either. Sure, you can verify authenticity of data (if i understand correctly, this is just glorified merkle tree/blockchain). But how does http://upload.wikimedia.org/wikipedia/commons/8/8c/Hashlink_timestamping.svg actually prevents people just storing the hash of data? The data and the hash would have to be the same size. Or, if you like, the data *is* the hash. Alternatively concatenate the timestamp/signature of the last block onto the file contents, and hash that? Would that work? Yes that will require disk access, but we're assuming that disk rate is faster than network rate. |
|
|
|
|
My thought of bandwidth was to simply use a 24-hour (or some nice fraction of the block retarget interval) rolling bandwidth. Self-reporting will not work, because of the possibility of malicious nodes. Rather, each node will report the bandwidth that it "sees" coming from all other nodes connected to it (one instantaneous measurement every block, averaged over the time interval) - therefore, if there are at least some honest nodes on the network, then reporting by malicious nodes will show up as a discrepancy. Not sure about the particular details, but guys with better math skills can take it from there.
|
|
|
|
Here's a publication on Wuala, and why it ultimately scrapped the distributed approach in favor of centralization: http://www.eurecom.fr/fr/publication/3772/download/rs-publi-3772.pdf1. Better data-deduplication. This is clearly a concern with downloading the full blockchain (no way would a user ever require 10000 copies of his or her files, no matter how important). Modify client to allow a "blockchain coverage" option. If blockchain coverage is adjusted down, delete the most redundant blocks in the local blockchain. If coverage is adjusted up, download the least redundant blocks to the local blockchain. (Need a way to get redundancy somehow, perhaps via broadcasting something from the client software, counting blocks "that I own"). Tie "blockchain coverage" setting directly into "allocated storage size" (below). 2. Bandwidth limitations. Users putting up, say 1TB, over a puny 768 kbps connection. "Proof of storage" also requires a "proof of bandwidth" and "proof of uptime" component. Storage with unreliable bandwidth is useless. I propose a function like this: "Storage rate" = Allocated storage size * 24-hour rolling bandwidth (units: bits^2/sec). Tie this into "difficulty". Clients that contribute either more bandwidth or more storage are rewarded w/ blocks.
3. Centralization efficiency. Having clients communicate with a central server for distributed data is inefficient. Cryptocoins inherently solve this problem. But then there's the blockchain problem again. 4. Simplicity. Centralization is simple, for the reasons above. Then again, cryptocoins have this down also. |
|
|
|
So something like a crypto-version of Wuala (before it got bought by Lacie)? I would be up for that. What would be a "block" in this case? A unit of storage (1GB, 1TB, ?) Encrypted file segments (as transactions)? What will addresses correspond to? Cool idea regardless. A full blockchain definitely won't work though, so the client will have to be coded with that in mind. |
|
|
|
|
Fun coin. Confirm rate right now is almost 1/sec. Will mine a night for the lulz.
|
|
|
|
|
Show Posts
