121 karma · joined March 18, 2016
yes, existing government systems are insanely complex - that’s part of the problem! the essential complexity is not higher than that of a brain-computer interface, or an interplanetary rocket.
we don’t even know what these kids’ mandate is (also disappointing). but if your general premise is “smart outsiders who are good at engineering are always the wrong people to rework complex, inefficient systems,” i’d like to think you’re on the wrong site.
I've observed many startup founders who are disdainful of employees who leave, ever, for any reason, and definitely don't want them to receive proceeds from any of the company's future successes.
> How does this system deal with the "data withholding" problem? In other words, when people provide "storage power" their data will be repeatedly sampled to make sure it is available... but when an entity claims that samples aren't being provided as required by the protocol, how does the system determine that that person wasn't lying, if the sampled data is still provided correctly in a followup request?
Filecoin sort of splits this problem into two parts – "data withholding" from Filecoin's proof-of-spacetime consensus mechanism (a "storage fault" in Filecoin terminology, yes I know there's a lot of new terminology here!), and "data withholding" from a client that's requesting stored data.
Storage miners are required to prove to the network itself, not to any specific challenger entity, that they're storing files. Each storage miner is (basically) randomly challenged once per [short interval] to provide a compressed cryptographic proof in response to a challenge. The proof conclusively confirms that, during that period, the miner was storing the data being they'd previously promised to store. You can ctrl-f "if a miner goes offline" in the linked post for a surface-level description of how the network deals with storage faults. Ditching the data and recovering it later is economically irrational for pretty involved reasons – basically, recovery is more expensive than just storing the data over the short-ish intervals during which faults are recoverable.
When it comes to "withholding data" from clients – retrieval on Filecoin is just a market-based system for bandwidth. The solution to holding data "hostage," i.e. refusing to serve it at reasonable prices, is to store a few replicated copies (just like centralized storage services do for you today behind the scenes). There's really no upside to miners refusing to profitably serve you a file when they know or suspect you can get it from another source.
> The "verified clients" are certified by "a decentralized network of verifiers". How does this system prevent a sibyl attack, i.e how does it prevent verifiers from repeatedly verifying themselves using multiple accounts?
The short answer here – with apologies for the brevity; details forthcoming – is that verified data isn't meant to be scarce, and some degree of over-verification is expected. There will be a decentralized group of folks responsible for (quite permissively) verifying and renewing clients for fixed amounts of data, and declining to renew allocations for clients who seem to be abusively verifying data. We're optimistic that this will dramatically decrease the rate at which "fake" data is stored and (most importantly) ensure that there's always storage available for client data.
> Why is it that erasure coding isn't necessary in this system?
Basically: cool, novel cryptography! In particular, this is where proofs-of-replication and proofs-of-spacetime kick in. Check out this podcast with Juan to learn much more: https://filecoin.io/blog/filecoin-proof-system/
(Also – if you like erasure coding, it is totally compatible with Filecoin whether you're a miner or a client! I would be surprised if this feature isn't developed by the community in Filecoin's early days.)
> How can a user of filecoin get some assurance that the files they are storing aren't just sitting on a server run by the filecoin organization?
Really fair question. First and foremost, as a client, you get to choose your storage miner if you want to. You then have to solve another problem, of course, which is how to map a Filecoin peer ID to a real-world actor (or prove that it's not being run by Filecoin, or whatever). This is solvable in a bunch of different ways, which I won't get into here, but the high-level takeaway is that you're not just throwing your data at an undifferentiated storage interface with obscure inner workings.
More fundamentally – Filecoin is part of a huge ecosystem of open source projects. Transparency is a key value – highlighting the success of the community, including the many decentralized storage miners participating in Filecoin, is really important to us and the only way the network can succeed. You can hop on our Slack any time (https://join.slack.com/t/filecoinproject/shared_invite/zt-dj...) to chat with the many folks already building on Filecoin. If you have other ideas on how we can establish that there are lots of groups operating on the network, not just us, let us know and I'll see what we can do :)
Using Next with Preact instead of React makes the total gzipped JS bundle around 20kb. Takes no time to set up.
If you’ll only ever build one website, sure, use basic tools. If you can amortize the cost of learning the toolchain across many projects, use better tools! (I’m not saying that’s only React by any means.)
The "no competitive advantage / anyone can do this" crowd is sort of ignoring the fact that no one did, at least for folks that care about the things I mention.
I think this is critical, and engineers seem to struggle with it more than the average person. Remember your codebase is a business tool, not an art project. It's okay if some of your junior person's inelegant code ships as long as it works acceptably well. If you try to make every line exactly what you would have written, you'll drive yourself crazy.
Of course, you have to do this using incentives to avoid breaking the protocol. This is actually one of the reasons it makes sense for storage and retrieval markets to be separate. If you’re being paid a fee to serve a file you have, you should rationally want to serve it unless there’s a compelling reason not to.
I love HN, but frequently find myself mindlessly refreshing the page throughout the day. This feels unproductive and sometimes unhealthy. Tools like browser extensions that time-limit domains haven't been effective for me, so I decided to try to build something that would trick my brain a little more cleverly.
On the backend, Slow HN is a Go server that frequently pulls the best posts from the HN API. It persists data about those posts, as well as their position on the page, to a sqlite3 database. When a user selects their desired update frequency, they receive a list of the weighted-average best posts from the relevant interval. The whole thing is running on a $5 VPS.
I'm also picking up great historical data about HN posts and looking forward to publishing periodic summaries of the best posts!
(Another purpose for the project was to learn more about React, so apologies to the <noscript> crowd.)
The site operator can of course nefariously and randomly serve JS that exfiltrates keys, but users at least have the _ability_ to audit every single transaction.
I always found this approach to be tremendously effective. If decentralized command were applied diligently from a company's earliest days, I believe it would sole a lot of the scaling issues organizations face. But it's difficult for most startup founders to give up control.
[0] See, e.g., https://www.inc.com/magazine/19980401/906.html
First, it's not clear to me that the coins need to be locked up at all - why can't participants deposit or withdraw their funds as they please, with the funding contract relying on the current state at the end of the funding period?
Second, even if they do have to be locked up, I'm not at all sure that it results in deadweight loss. Certainly not appreciable amounts compared to traditional methods of funding.
To me, this is pretty clearly the best system currently available. It avoids problems like scammy, uncapped sales (Bancor) and sales that instantly sell out to a few buyers (BAT).
But, if I'm missing something, it would be interesting to know!
(Further information on whether your company is covered: https://www.nlrb.gov/rights-we-protect/jurisdictional-standa...)