tkfu

I'm curious to dig into this a bit more. In general, I'm skeptical about those use cases.

* If it's a governance token system where more money == more power...well, I just don't think it's a good idea in general.

* If it's a system that tries to replicate the idea of one person/one vote, you have to have KYC (and re-KYC upon membership transfer) or it devolves into the first case. Then the entity doing KYC has centralized control over membership, so it seems like storing membership info on a ledger doesn't offer any benefits compared to just having a central membership database.

That's a bit misleading--you can only stake for 10% if you agree to lock up a large amount of money in CRO for a long period of time, and if you agree to a three month fixed-term deposit for the USDC you're "staking". CRO exposes you to arguably more risk than the staking is worth, and the fixed-term deposits have the downside risk of crypto.com literally collapsing and not being able to pay you back.

If you want staking rewards on USDC (from crypto.com) without a fixed-term deposit, the best you can do is 2%. If you want to avoid having to lock up $40,000 in CRO for a minimum of 6 months, the best you can do is 1.5%. Given that you can earn 0.7% on a FDIC-insured deposit in actual USD, that's not much of a deal.

You're being willfully obtuse here.

> What non-blockchain solution solves the double spend problem when transferring digital assets in a peer-to-peer network?

Literally any trusted central authority or database.

> Or, in the case of Ethereum, providing solutions to general-purpose decentralized computation and state (rather than only peer-to-peer payments) with such strong public consensus?

You haven't actually stated a problem here, you've described a solution in search of a problem.

> User A holds digital asset X (such as a valuable domain name "xyz.eth")

You're mentioning a .eth domain name being bought with cryptocurrency as an example, which is entirely circular. "Hurr durr, betcha can't swap one blockchain thing (.eth domain) for another blockchain thing (cryptocurrency tokens) without using a blockchain" isn't as strong an argument as you think it is. If we were talking about a .com domain name, no blockchain in the world will help you with that transaction.

I just had to laugh at this one:

> Maybe the shadiest form of these deals comes from the public equity markets from a no-fees online broker Robin Hood and its Payment For Order Flow (PFOF) because of the conflict of interest of a broker making more profit when it is "saving in customer transaction fees." > > In decentralised markets, such shenanigans do not exist.

MEV is an extremely well-known, well-studied empirical phenomenon that happens today and does not have a known solution, and it's exactly analogous to front-running. It's especially funny that you put out this blog post almost exactly on the 3rd anniversary of the publication of the Flash Boys 2.0 paper.

What I want to know is, are you just ignorant of MEV-related problems, are you trying to mislead your readers, or do you have some sincerely-held belief that MEV front-running is somehow morally okay in a way that PFOF isn't?

The basic argument you seem to be making is "This exists, and there is self-evidently a market for it, therefore it must be good. (Or, if it isn't good, tweaking some parameters could make it good.)" That's a bad way to evaluate the risk of something so new, in a market that is so volatile. People get suckered into buying bad insurance all the time, even in highly regulated markets.

But anyway, I went ahead and checked out the white paper of nexus mutual [1], because I was curious. It appears to have a serious amount of hand-waving on one of the most important topics: the risk correlation between offered insurance products. They do reference the correlation matrix, but the only mention of how the value of the matrix is determined is to say that if independence between cells can be assumed, the math is very simple. Doing a quick search through their website and code, it looks like they are indeed just assuming that products aren't correlated, instead of trying to estimate real correlation values. This means that their minimum capital requirements (and thus the implied risk of default) are incorrectly calculated if that assumption is violated--which it certainly is.

This seems to be by design, and baked into the incentive structure of the whole concept. There's just no practical way to crowdsource proper correlation evaluation and adjustment, and the economics stop being remotely competitive if you just guess at correlations and treat it as another risk to be hedged. You can see this later on in the white paper (appendix A), where they point out that the economic viability of the project depends on lowered labour costs because product creation, assessment, and policy issuance are crowdsourced or automated. Their game theory/tokenomics are focused on providing incentives for individual products to price risk accurately, however: they do not propose any mechanism for adjusting or calculating MCR based on correlation risk when new products/coverage are offered. This is further evidence that they're just assuming independence without any real justification, and thus being chronically undercapitalized.

[1] https://nexusmutual.io/assets/docs/nmx_white_paperv2_3.pdf

That's a completely nonsensical answer to the question that was asked. It's frigging insurance--the whole damn point of buying insurance is to offload risk.

Insurance where you can't be certain the company will be around (or actually pay out) when the shit hits the fan is completely useless as insurance, and it's either naïve or disingenuous to suggest that the solution to that is to "complain". And suggesting launching a competitor is just an extra special kind of stupid: if you have enough capital to start an insurance company, you're obviously not in the market for buying insurance.

It might be a "common delusion" where you live (I'm guessing the US), but in every country I've lived in (n=6), it's an accurate understanding of basic privacy law. You can't just go and take someone's photo without their permission, even if they're in a public place.

I think this is a really nice and important project, and at a cursory glance the design looks sane from a crypto perspective. But I question the basic UX design.

The attestation system seems like it's reproducing one of GPG's UX problems: you have these categories of attestation, and it's seemingly pretty sane as long as everyone uses the attestations right (and there are enough players in the ecosystem doing the work of attesting). GPG's trust levels have the same idea, but in reality people often just pull keys from some public keyserver and then assign them Full trust.

I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice.

Finally, although I in-theory admire the goal of allowing the user to define their own policy about trusting updates (defining how many attestations of which types are required/sufficient), my experience in software update systems tells me that real people absolutely won't do this. What will happen, if Gossamer sees good adoption, is that (1) there will be a standard trust config that gets distributed and reproduced, (2) everyone will use that config, and (3) it will be very permissive, because users don't want updates to be delayed/denied. The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence.

Probably "impassionate". (Which has been displaced in modern usage by "dispassionate", but if you learned your English from books you're likely to still use.)

I'd say that >90% of keyboard users never think about "liking" their keyboard localization at all; if you grow up in a country with a particular standardized keyboard, it's just the one you're used to, and you deal with its quirks. On top of that, I'd guess that >50% of keyboard users still need to frequently look at the keys when they're typing, so changing keyboard layouts to one that their keyboard isn't marked up for isn't a realistic option.

For me personally, I also type in 3 different languages (two of them making use of various diacritics) frequently; my preference for the last decade or so has been to use the "normal" US-English layout for writing English prose, code, or working on the command line, and switching to US-International (w/dead keys) whenever I'm writing in a non-English language. I just find the dead keys on backticks and quotes to be especially annoying for programming.

I think that's absolutely the most likely. And it's not hundreds, it's probably more like tens of thousands (or more). For example, when I got mine issued in Germany, I just went to a pharmacy, gave them my ID and (paper) vaccination record, and the pharmacist came back in a couple of minutes with my QR code.

The interesting thing to watch, over the coming days, is this: will the public policy response do the technically correct thing, and make sure that you need all your original documentation (signed records from the doctor's office, etc.) to get your new covpass issued? Or will they do something incorrect (but easy), like let people come in with their now-invalid pass plus a government ID to get a new one issued?

Have you ever heard of "The Narcissist's Prayer"? It goes like this:

That didn't happen.

And if it did, it wasn't that bad.

And if it was, that's not a big deal.

And if it is, that's not my fault.

And if it was, I didn't mean it.

And if I did...

You deserved it.

Tether defenders are really working their way through the steps here.

18 months ago, it was "That didn't happen." (Tether is 100% backed by USD cash.)

6 months ago, it "wasn't that bad." (It might not be 100% USD cash, but it's cash-equivalent assets like short-term commercial paper.)

Now that there's strong evidence the commercial paper is just fake money shuffling between Tether/Binfinex/other shady crypto investments we get "that's not a big deal." (Look at the way banks work! They only need 4% collateral! Tether's probably got at least that much...)

Next step is finding out that their actual liquidity isn't capable of holding up under a real-life stress test, and the defenders will be talking about "not my fault." (This was a once-in-a-lifetime crash, they couldn't have foreseen it, crypto's still way better than the fiat banking system!)

When thousands of people lose their retirements in a gigantic defi crash, it'll be "you deserved it." (Everyone knows crypto is risky, you shouldn't have believed Tether was the same as USD.)

Are you sure about that? I certainly don't recall that, and it seems like it would be a bad UX idea anyway: you can't clone a repo via SSH without having an account (and a pubkey registered), so showing the SSH string to people who aren't logged in seems counterproductive.

The article already mentions both of those challenges, and outlines practical solutions/mitigations to both--can you be more specific about what you didn't like?

This reminds me of the old xkcd [1] about how standards proliferate...

Situation: Git has 137 difficult and unintuitive subcommands [2], and new users can't keep straight which ones they should use.

"Oh man, that's awful, let's add new subcommands that are clear, and do just one thing well!"

Soon: Situation: Git's CLI has 138 difficult and unintuitive subcommands.

[1] <https://xkcd.com/927/>

[2] Yup, seriously, as of 2.32. I checked.

I see a lot of people saying that there aren't a lot of attacks that having a 51% enables. I'd like to understand that a little bit better. Are there markets where you can short-sell cryptocurrencies? If so, mightn't you be able to turn a good profit by shorting one of these smaller coins (say Quarkchain at $30/hour with a market cap of $116M), then launching a 51% attack for a week or two, in the hopes of tanking the coins value? That would only cost you $5k per week.

Money market funds arguably act like a banking business, but are subject to regulation of their marketing material that obliges them to explain that they're not, and they certainly don't operate like a payments business.

Money market deposit accounts are a different story, and are highly regulated (and secured).

That being said, even if your comparison was accurate "hey, look at this similar business that caused harm and chaos during the last financial crisis" isn't exactly a glowing endorsement, is it?

That's a bit of a mischaracterization. The 75% that they're describing as "Cash & Cash Equivalents" might be similar to money market funds in composition, but we can't know whether it is or not because they don't give any details about the commercial paper. They don't even make the claim that it's asset-backed. Because they aren't saying anything about that, and they're not audited, they could very well be making riskier bets.

But more importantly, there's the 25% of their funds that bears absolutely no resemblance to anything a money market fund would do. The quote the FT article publishes from Martin Walker looks pretty reasonable to me:

> It is pretty clear looking at the makeup of the reserves — a tiny proportion of the reserves are cash on account at banks — that Tether is operating like a bank but with none of the normal disclosure.

> They are creating a dollar substitute and basically running a banking and payments business but without the oversight that anyone else doing a similar kind of business would have.

> What does a time system have to with system start infrastructure?

Accurate time is vital for many cryptographic operations. For example, in the embedded space you may want to have a check that your current disk image (ideally checked by dm-verity) is actually up to date. And to verify the metadata signing that disk image using Uptane/TUF/SUIT or similar protocols you need verifiable time. Or you might need to contact a provisioning server at boot time, and need to be able to verify that server's TLS cert.

(Now, systemd used to have a bug[1] where time-sync.target would be reached before time was actually synced, and Poettering's response to the bug was the all-too-typical typical "yeah, don't worry about it, it's intended behaviour that the time-sync target doesn't mean that time is synced"[2]. But that did get fixed a couple years ago [3].)

[1] https://github.com/systemd/systemd/issues/5097 [2] https://github.com/systemd/systemd/issues/5097#issuecomment-... [3] https://github.com/systemd/systemd/pull/8494

The biggest thing is about trust: you can tell me that you're following good security practices with my keys, but I don't have a good reason to believe you, and the signals you're giving off all point in the wrong direction.

jart's finding (in another comment below) that you're using fullstory in your electron app is probably the most damning; at this point I wouldn't ever consider even trying your product. Putting a keylogger in an app like this is evidence of careless engineering at best, and malicious intent at worst. Either one is disqualifying for a tool that would have access to so much of my critical infrastructure.

I tried to email this to you privately, but hello@kloud.team bounced and you don't have any other public contact info.

Your docker image (kloudi/api) has a whole bunch of credentials in plaintext inside it. I am not going to check whether they're valid or not, but they certainly look real.

Look, I think this might just be a little bit premature. Claiming that it's secure and fast because it's locally hosted is not convincing at all. "Secure" isn't convincing because you're asking me to run three docker containers worth of random code, and trust that random code with API keys/credentials to all my critical infrastructure. I have no way to know what your security practices inside those containers are. "Fast" isn't convincing either, with the need to run redis and mongoDB inside local docker containers being particularly unconvincing. The fact that there's no documentation at all (or at least, none that I could find) is the cherry on top.

Plus, what's up with only supporting running the containers on MacOS? That's really, really bizarre.

Basically, there are a number of signals here that prevent me from trusting you enough to even consider trying this out, even though it's quite possibly solving an interesting problem.

Yes! I'm not shocked to see that this response is the one that gets downvoted instead of the chorus of content-free agreements, but that's HN for you.

Ok, but how do you do that? It was easy in classical music; they just started doing auditions behind a curtain, without any verbal Q&A, and suddenly a field that used to be dominated by men became pretty much 50/50, and all the people who said that men were better at the highest echelons of musical achievement had to shut up.

But tech companies want to talk to the humans they're hiring, so race and gender are (almost) always available as information inputs during the hiring process. There's no equivalent to the curtain to remove the possibility of bias, so you need to look at alternate methods. Setting hiring targets is one way to do it. If you're going to complain that the targets are unfair, you can't just say "Well shucks, guess we have to stick with the system that produces massively unequal outcomes." You've gotta propose a system that's less unfair than the status quo.

In most cases, it’s not so much a considered security posture and more that Yocto and other embedded builds tend to use dropbear instead of openssh because it’s smaller, and dropbear doesn’t support sftp.

> I'm not quite sure what you're saying here. Are you claiming that you can push a commit to userA/project and then view it under the Github web interface for userB/project (assuming one repo is forked from the other)?

Very close to that, yes. There's actually just one more step you need to take: you have to also open a pull request from userA/project to userB/project. As a convenience feature, GitHub automatically makes PR commits available under a special namespace. You can try it yourself with any pull request that comes from another repo--just `git fetch origin pulls/<PR #>/head.

Since the foreign commit is there in this special 'pulls' namespace, it can be viewed in the web UI by its commit ID. That's how people are adding youtube-dl to github's DMCA notice repo; they're just opening a PR containing youtube-dl's commit history.

No, not even a little bit. There is a gigantic gulf between an organization with power in the situation making an official finding, and an individual with no power over the situation looking at the facts and forming a conclusion.

> that can run pretty much every widely available open source operating system.

That's just not true, though. Here's a git repo listing what works and doesn't work in Linux for all of the macbook pro models since 13,1 (released in 2016): https://github.com/Dunedan/mbp-2016-linux

You'll notice that power management (suspend/resume) doesn't work for any model, wifi only works for a few select models, and support for audio is pretty spotty. If you buy Mac hardware, you're pretty much locked into MacOS if you want to have a reasonably acceptable experience.

BSD support is much, much, much worse--it basically doesn't work at all for any relatively recent model.

Are you familiar with Prawn [1]? Perhaps I just haven't bumped up against its limitations yet, but in my experience it's exactly what you're asking for. Of course, it's in Ruby, which isn't to everyone's taste, but it's the best tool out there that I've found.

[1] https://github.com/prawnpdf/prawn

I have to confess, I was a solid halfway through before I realized it was satire.