HN user

emagdnim2100

120 karma
Posts4
Comments32
View on HN

disappointing to see so many “hacker” news comments complaining about lack of credentials or system-specific expertise.

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.

There's absolutely no reason companies can't issue options that automatically convert from ISOs to NSOs after the 90-day period, and leave the NSOs on the table for ten years. There is no downside to the employee or, really, to the company – other than that the options, which were pitched to employees as part of comp, aren't clawed back to the company's pool as quickly.

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.

Hey, great questions! I'm on the Filecoin team (but not the proofs/cryptography team, where the root answers to some of your questions lie). Let me try a first pass and tap out for someone deeper on the cryptography side if needed.

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 :)

Potentially dumb question: how do cheats even work in a game like LOL? I understand aimbots in a FPS and how they can give a pure mechanical advantage, but the LOL equivalent isn’t obvious to me. Does the client have access to data that’s not supposed to be exposed to the player?

For what it’s worth - there’s definitely no speed up, for me at least, to ship a pure handwritten HTML + CSS page vs the same page using create-next-app. The latter makes it trivially easy to add new functionality, etc; the former guarantees I have to start over. I also get a bunch of stuff - TypeScript, code splitting, minification, etc - for free, literally no work. It’s nice.

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.)

Everyone likes to pile on WeWork, and I get it, but as someone who dealt with both startup and solo office leases in the pre-WeWork era: my God is WeWork's model comparatively amazing as a customer. The spaces are nice, there are no headaches, you can purchase the exact amount of space and duration you need, and you have a guaranteed decent place to do some work or just hang out anywhere you travel.

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.

5) Don't prevent all mistakes, just horrible ones

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.

@ianjdarrow from the linked thread here. To clarify a little – the idea isn’t that Filecoin would ever tell anyone they have to remove data of any type. Filecoin is open-source software that tons of storage miners will use across diverse legal and moral systems, and it’s important that those miners can make decisions about how what they store and to whom they serve it.

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.

[dead] 8 years ago

This isn't something to be proud of. Time-based advancement is a lazy, outdated system. Folks have wildly different levels of talent coming in, and develop at different paces throughout their careers. There are much more important factors that "time served."

Slow HN is a Hacker News aggregator that allows for easy user-defined throttling of post updates.

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.)

Tesla Semi 9 years ago

Or maybe Tesla's "image and vision" stem from its founder's tendency to completely ignore sideline commentary on non-substantive issues and focus on product.

This is far from true. Client-side crypto at least gives you the ability to inspect outgoing network traffic. This should help to keep site operators honest.

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.

The Marine Corps teaches the "rule of three:" each leader should have at most three direct reports.[0] In practice, leaders at the platoon level or higher (~40 people total on the infantry side) also get a senior enlisted advisor who serves as a trusted second-in-command but who isn't a direct report in the same way as your subordinate unit leaders. Additional folks beyond those three should report to one of the boss's subordinate leaders, not to the boss. The structure repeats up and down the line, sometimes with small tweaks: three rifle platoons to a company, three squads to a platoon, three fire teams to a squad.

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

Notwithstanding all the problems with token sales: I don't really understand Vitalik's objection to the "partial refund model." He dismisses it out of hand as creating deadweight loss because the coins have to be locked up for a period of time.

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).

This may be a misconception - a decrease in the rewards paid to miners wouldn't obviously be "made up for" by an increase in transaction fees. The fee is basically a bid to be included in the next 1MB block, so it should be a pure product of transaction volume (and, of course, the BTC/USD exchange rate by extension). However, I agree that both the transaction volume and the exchange rate are likely to continue increasing.

But, if I'm missing something, it would be interesting to know!

Making an LLC costs a few hundred bucks a year, so there's no reason any benefits would only accrue to wealthy individuals. To the extent that Trump's business tax proposals actually become law (the 15% business tax with no personal tax applied is a massive change from how it currently works), I predict a shift away from salaried employment and towards independent contracting / small business ownership. Tastes may vary on whether this is a good thing.

There's a ton of irony in this coming from a group that "works to improve diversity at tech companies." I am no Trump fan, but (at least) 40% of American voters seem to like the guy better than the alternative. Does Ellen Pao want to improve superficial diversity and ideological homogeneity at the same time?

My theory is that bitcoin will end up serving as the stable reserve currency for various specialized altcoins. This is already happening a bit - take a look at the price (and market cap) of bitcoin versus something like Ethereum (smart contracts) or Monero (quick, very anonymous transactions).

By "zero out," do you mean they were previously valuable and then dropped below their strike price after accounting for the > 1x preference? That sucks and I'm sorry it happened to you. It's still pretty unusual though.

Curious to hear - were any of the following factors in play: (i) the company was struggling to stay afloat, (ii) the company was located outside SF/NYC, (iii) the company had less-experienced founders?