Keybase is now supported by the Stellar Development Foundation
keybase.io
keybase.io
There's a subtle point I cut from my post for simplicity reasons, but which feels perfect for HN. I've been convinced by Mazières and the Stellar team that the classic "blockchain" works great for native tokens but is extremely dangerous for anything with counterparty redemption. For example, imagine the shitshow after a truly contentious fork, if there are tokens which are supposed to be redeemable with a counterparty.
Let's say Deutsche Bank had put €1 billion into colored coins on Bitcoin. Suddenly, after a fork (e.g. bitcoin vs. bitcoin cash), there would be €2 billion IOU's in the wild. The people on each side of that fork would not roll over and die, and it's not simple to say "Oh, whoever Deutsche picks wins." Or even "Whoever has the strongest chain wins." I have a hard time imagining a company would ever take that risk. I worry big companies would never dare to put anything real-world redeemable directly onto, say, Bitcoin or Ethereum, for this reason. They'd just get sued over and over again.
The Stellar federated consensus story (HN debates about SCP below [1][2]) has Deutsche Bank as an actual player on the network. If you want DB redemptions then you would include them in your trust lines / quorum slices, and if Stellar fell apart and became partitioned, you would stay on DB's side. All said, it seems significantly faster and more stable for cryptocurrency-to-real-world mappings, both for the consumer and counterparty.
Fun discussions:
[1] https://news.ycombinator.com/item?id=9341687 -- of particular note, because it has David Mazières, Vitalik Buterin, and Greg Maxwell all weighing in.
Stellar does not use proof of work.
> Also, why are you seeking more funding in the first place?
AFAIK Keybase are a for-profit private company.
For example if you have some type of mathematical problem (the unknotting problem) to take the place of the proof of work then you have to worry that that problem is actually hard to perform. Hypothetically that problem could be quite easy and you can subvert the system by having some shortcut.
But inverting a hash is known to be hard. Through this hardness you get artificial scarcity by making people efficiently design systems to consume electricity.
if you have to hold a lot of limited thing X (that’s difficult to get; eg $10m worth of ETH) on the very chain you’re securing, then that’s scarcity too.
another benefit here is that you can make a trusted network; that way you don’t have nodes coming and going, you have a group of trusted parties with their own network, and there’s less potential for a 51% attack
electricity and work isn’t the only thing that can be scarce
The other thing that is compelling about Bitcoin's proof of work protocol is the ideal that every participant is equal. The whole point is to avoid the circumstance where more money means more control. Now, I think we can probably all agree that this didn't pan out -- whoever controls the big mining pools controls the system. I think that if anyone is going to go to the next level they probably have to step back and look at the problem with fresh eyes. Substituting X into "Proof of X" is unlikely to provide the solution, IMHO.
What is the purpose of this question? You want KeyBase, a private entity, to convince you, a stranger on the inter-webs about their plans for said funding? That's giving yourself FAR too much importance. Here's $5 bet that the company will ignore this question.
I've been convinced by Mazières and the Stellar team
This is no different than what current financial institutions do other than a new UI.
My impression was that Lumens seemed to be solving one of the legitimate problems of the world—the inefficiency of the SWIFT system for cross-border transactions—and appears to have a viable model for doing so.
I don’t see how whether or not it’s centralized makes it a swindle?
When SWIFT was devised, the idea of having a singular system for resolving these transactions not only made sense but was (probably?) technically necessary. I think given where we are today, multiple competing protocols, each with their own advantages, may be viable.
Lastly, for finance, consumer choice is valuable: I like being able to Venmo my friends, autodeposit my landlord, slow mail my bills, and Apple Pay my retail purchases. I don’t send money overseas but I could imagine a similar bifurcation of solutions in this space, all with their own advantages.
Ripple has only just now, in 2018, published their decentralized consensus algorithm (Cobalt), which as far as I know is not even in production use yet, and doesn't provide optimal safety. (In settings where Cobalt is guaranteed Safe, SCP would be too, but not vice versa.) Their production network still uses a protocol that, by Ripple's own analysis (https://arxiv.org/pdf/1802.07242), fails to guarantee safety without >90% agreement on the UNL.
the foundation is some group of fly-by-night scammers
This was my implication. I have known 'Stellar' since its beginnings as Ripple. I have no expectations of changing your mind or obligation to convince you otherwise. Just thought I'd share my viewpoint.
I think Stellar's model if Internet-style (as in the backbone network infrastructure) organic, federated trust relationships is the most practical and viable approach to decentralization that I have seen.
Organizations decide who to trust based on their relationships with them and individuals decide which organizations to trust for the same reason. That is how trust works in the real world, and for good reason. The problem is that the costs of operating at a global level in the current financial system are very high, which leads to centralized control.
Stellar will potentially allow many different types of new, small and innovative organizations to participate in the same network as larger more traditional institutions, with no restrictions for joining the network. Of course those small organization still have to compete for customers in the real world and the playing field is never fully level, but certainly opens up the game.
I personally just don't see the Utopian, fully-decentralized, f*ck-the-system future that a lot of crytpo-enthusiasts envision. It just doesn't mesh with the reality of how non-technical users operate in the real world. For example, right now the vast majority of US users purchase Bitcoin through Coinbase, because that is who they deem trustworthy. What I do see with Stellar is the possibility for greater innovation and greater individual access to the global payments network.
[1] https://medium.com/a-stellar-journey/on-worldwide-consensus-...
An analogy I can be able to give, is banking is double entry book keeping. DLT's are triple entry book keeping, there is simply many things that their current ledger entries can't do. DLT allows their money to become commodity money, there is also a bunch of contracts that can be added on top of that. So main thing is banks could be able to potentially offer many more services than just verifying payments, at a much lower cost reducing the amount of employees they need. Make more offices or w/e else bankers do lol.
This is use-it-or-lose-it. Should they just allow the river to flow and bypass the turbines?
There's a reason why hydroelectric plants and dams go together.
And they don't need it, because power-generating dams are generally only built in places that provide lots of downstream flow naturally, like the U.S. Pacific Northwest, or in places where a reservoir is already desired for other reasons (typically drinking water, navigation, and/or flood control).
Dams have the capacity to route downstream flow around some turbines to lower their generating capacity. It's not really accurate to think of that routed water as "wasted capacity," because that water would flow naturally even if the dam wasn't there.
The (amortized) cost of building out new supply is a major[0] part of the cost of electricity - this is why most big energy producers spend millions of dollars per year on energy efficiency incentives. Haven't you ever wondered why your power company will give you a $50 rebate on an EnergyStar dishwasher? Isn't it counter-intuitive that they would pay you to buy less energy, when they have excess? It's not because they're tree-huggers - it's because decreasing demand growth delays the day when they need to build a new plant to meet demand, which increases the profitability of the current plant enough to make those incentives cost-effective[1].
0: I can't find a good estimate and it varies by fuel type, but I rememeber an environmental engineer at a former job telling me it was about half. Look up "Levelized Cost of Electricity" for more info.
1: If you're not convinced, instead of demanding more details, I urge you to just stop and ask whether the proposition "There is a lot of excess energy production lying around which BTC miners can soak up without impacting everyone else very much" really passes the sniff test.
Doesn't California actually pay Arizona to offload their surplus energy?
http://www.energy.ca.gov/almanac/electricity_data/total_syst...
So the extra there is not really electricity you'd want to plan a crytocurrency operation around.
Otherwise you'd ruin a lot of machines depending on either 220V/110V or 50Hz being on the grid.
This argument also explicitly ignores schemes such as PoS that don't have this massive power drain, and also ignores interesting schemes like PoC (Proof of Capacity)[1] that also don't have this power drain (apparently).
there absolutely is a disbalance between energy produced and energy consumed. if we're lucky, there will be storage capacity nearby. we're mostly not lucky. ever heard of australia? or tesla? google some.
> wasted on useless cryptocurrencies
yeah, transferring value securely without trusting third parties is not useful at all. gotta run all those banks and employ all those bankers, because that costs no energy nor other resources.
are you a banker by any chance?
Normally surplus electricity results in a curtailment of fossil sources.
How is that different from a network fork happening, and DB saying "We only accept tokens from ETH and not ETH classic".
At the end of the day, DB is deciding on a network partition to support, and you either support the network partition DB is supporting, or you don't do business with the DB tokens.
If the Stellar client's behaviour in the face of a partition takes trustlines into account, that's much safer than the default behaviour in bitcoin, which I believe is "pick a partition at (pseudo)random".
It's possible to manually coax the client to pick a partition, but that requires user interaction, i.e. it's not fail-safe, it's fail-unsafe.
What's worse is that colored coins could distort the incentive structure to make it profitable to bribe miners, because the benefit to an attacker of subverting consensus could far outweigh the value of 12.5 BTC/block.
Presumably, the default implementation of such a fork-event handler would have all but one of the contracts destroy themselves (and not in the common Ethereum sense of a contract "suicide", with the owner getting returned any held value; but instead with the contract simply blackholing all its value and state.)
> they also take resources to execute (which is represented by gas)
...and so you'd need to pay to fork, proportionally to the number of contracts that wanted to react to your fork. Though keep in mind that the forked network on the "new" side would have a low hashpower, and so a low gasPrice, and so could afford the required gas quite easily (the base-case being one where the forking entity temporarily controls 100% of the hash power of the network, and thereby can just "pay themselves" the gas, just like when bootstrapping a new Ethereum private chain.)
The more questionable aspect is that the network "being forked against" would also need to pay. Somehow, you'd need to make it such that the whole of the network would "want" to execute such transactions. Mind you, gas just prioritizes which transactions go through; if the "right of way" of fork-event contract-input transactions is hardcoded, it doesn't matter how much gas goes along with it—the network will run them. You can even just add some code that means that the network can't make progress until those transactions are in. (I.e. that chain consensus will treat chains that had the same fork-event transactions appear "earlier" in them as better, so it's useless to put work besides inserting a fork-event transaction in, knowing that the branch you'll be creating by doing so will be outcompeted by one that just executed the fork-event transaction first.)
> you would basically have one master contract with all the resources
I don't see how this implies that. The fork-er doesn't get to decide what's happening inside the contract, on either side of the fork. The network, on each side, is just sending an event—"hey, the network forked, you {are/aren't} on the forked side"—to each contract that wants to know, and it's up to the contract to decide what to do with that information. Each contract is still a standalone program with its own private memory-space that nothing else can touch.
Now you just said "whatever Deutsche picks win" with other words.
I believe they just basically said "we are treating the tokens on Ethereum, not on Ethereum Classic, as being the ones which are redeemable". I don't see what the problem with this is. It is inconvenient for the people who prefer to use Ethereum Classic, yes, but they didn't lose their tokens. They still have control of those tokens on the Ethereum (ETH(F)) chain, and can sell those if they want to end up only using Ethereum Classic.
This is unfortunate for them, and if this inconvenience could be avoided for free, then that would be better, but I don't think it is unfair to them. They still have the same control over the same tokens that are accepted as legitimate as they did before.
Thanks, Chris. You're doing a great job of making me look like an asshole for believing in you guys.
I don't want your "monetization plays" and my clients don't either. Giving you guys money for Keybase is infinitely preferable to having cryptocoin crap, Stellar or otherwise, being jammed into a tool I use for work. (Or anything else, really, that I ever have to touch.) And I feel like a sap for being an enthusiastic user of Keybase and recommending it to people when this sort of garbage is coming down the pike.
I am really, really disappointed.
It is the pure addition of risk to my operations and my clients' operations and offers nothing to me except a ding to my reputation, because I now look like an asshole because a security tool I recommended and spoke highly of is now going to be flogging funbux.
If they wanted to build some whateverthing that leverages Keybase for identity? Sure, go nuts, I think it's silly but it's not my time. But injecting it "into their apps"? No. These are tools for production, for me, and were developed with certain explicit and implicit promises. I see cryptocoin junk being shoved into production tools as a break of those promises.
I know a bit about how Stellar works, and I can't imagine any kind of software they could "inject" in their apps besides perhaps a way to post a Stellar address into the current merkle-tree they host and a way to fetch that through an API. How is that worse than having a Bitcoin address optionally includable in the same way?
The rest of their announcement, I legit don't care about. This is the deal-breaker here. You don't need a Big Announcement or to hire more people to add a Stellar address for verification. I know a bit about Stellar as well (granted, you probably know more) but this reads to me as a let's-be-a-wallet game.
And this is worse than having Bitcoin addresses: active functionality versus passive functionality. Difference of kind, yeah?
So... don't use it? I probably don't use 99% of the functionality in the software installed on my computer.
It sounds like you just have an axe to grind with anything relating to cryptocurrency.
AFAIK Keybase's clients are all open source. If this is a real problem someone (maybe you?) will fork them and remove the "cryptocoin crap".
What is it about this change that makes you assume you're going to have to deal with cryptomining et al?
This really is about Keybase bringing expertise with identity to the table and it makes a lot of sense for the two teams to work together. The currency side of things is still going to be handled by Stellar as far as I can tell.
Here's how normal people look at something like this. It's not "oh, but they're just facilitating," it's "why is there cryptocoin crap in this thing we use for work?". Then it's "Ed, why is this thing you recommended and spoke so highly about doing this? Are they cryptomining on our computers now?". Then, even after an explanation, they're probably still suspicious and probably right to still be suspicious because the cryptocurrency universe is, by normal and sane people, still viewed as a scammer's paradise. (To be clear: is this entirely justified? No, and I think there are decent people trying to make a go of it. But there's plenty of dirt going on and people should be suspicious until it's proven otherwise.)
I don't want this on my computers. But, more than that, I don't want my clients thinking that I am a party to shady business because of the tools I recommend that they use.
There are obviously annoying ways in which keybase could support cryptocurrency, but you are making a lot of assumptions about what Keybase is going to do that are not based on the blog post. For example, wallets do not mine coins and Stellar does not support mining.
Why don't you wait to see what comes out and submit a feature request if you don't like it, instead of flipping out about some hypothetical feature you won't like.
Where is this risk you speak of? Can you articulate it in any way? "Flogging"? Not anymore than they're flogging Hacker News or Facebook or Reddit by having an ID verification hook into them (complete with corporate logos!)
Hell, they already let you add Bitcoin (that thing that's only ever supposedly used for scams and drugs if the cynics are to be believed) and ZCash addresses for verification.
If the people you recommended Keybase to weren't turned off by having those front and center, it's likely they won't be turned off by this either. Take a deep breath.
It's also prone to reputational risks; basically everyone who hears about cryptocurrency almost immediately either loves it or hates it.
It seems less like you're being given a free piece of asbestos and more like you're being given tongs for holding some asbestos if you choose. Allowing one technology to work with another is different than marrying two technologies in an inseparable way.
Someone made the sandwich and let you use it, being clear along the way optional toppings may be added later.
* Keybase's plans will create an unofficial security bounty that is paid (1) out of users' wallets (2) to actors who haven't agreed to responsible disclosure practices.
* My personal choice not to use this (presumably) upcoming feature will protect my financial assets from exposure to (1), but it won't protect my data and identity from exposure to (2).
---
I myself am happy with Keybase, and looking forward to using it with crypto. I don't think it's irrational for someone with a different set of concerns to raise this, though.
If people want to mess with cryptobullshit, that's on them, but the more code that's active and doing stuff, the wider the attack surface is. I don't want it and don't need it.
That's not to say you even have to use a payments feature if it's integrated into the primary Keybase application. You don't have to verify ownership of a domain or register a Bitcoin address, but both of them are options in Keybase right now.
An auditor who did not bug his or her eyes out at that and ask some very hard questions would be doing a bad job as an auditor.
It is harsh--but, one, I thought they were legitimately better than this, and two, it's a problem. Keybase wants to be infrastructure, and people have different needs for infrastructure. That's an argument for different tools, not a multi-tool that makes its use in some situations problematic.
Why would anyone install the Keybase app on production servers?
After the user system, they created a network filesystem, which their git system is based upon, and I'm guessing it's also something their team chat system uses too. The entire groups system is also based on their user system.
It looked like they were building out a dependency tree bit by bit.
Keybase is the first product/software of its kind (as far as what I've seen)
Maybe Keybase will be wildly successful. Maybe someone else will come along and build upon what they've started.
Either way, I'm excited to see its continued development, and if this partnership helps fund them and keep them developing the concept, then even better.
But I think for the average platform, taking money from cryptocurrency foundations is a lot better than taking VC money. This was seen recently with the Matrix funding by Status token. Cryptocurrency goals usually need the platform to be open: just having a big integration with your token or cryptocurrency system can be a massive boost to your ecosystem. On the other hand, VC goals eventually require the platform to be closed off to milk all their users with actual "monetization plays" like Slack has recently done.
Don't you think your prejudice against cryptocurrency is clouding your judgement here?
Keybase is an identity tool and it makes every sense for it to make a wallet. Also, you provided no reasons that being involved in cryptocurrency will undermine keybase's security. Do you think?
By adding cryptocurrency to a communication/identity client, a jurisdiction will probably classify your business as a money transmitter, financial institution, and/or stock broker. After reclassifying your business, they then fine you into the stone age for not registering and following all of the laws associated with that status. While technically, it might be no different than handling money via your bank, the law has not caught up with that yet in quite a few jurisdictions.
Granted, that's just the US, but..
For a moment, I put myself in the shoes of Keybase and thought “how would I respond if a user felt this way?”. I would probably reply with a respectful something like “I’m sorry you feel this way but here’s why we are doing this”, but behind all of that, I probably wouldn’t care that much. You just insulted my vision, so why would I want you as a user? You gave me money, but you clearly didn’t trust me enough with it. Is that my fault?
1. Is Keybase still a for-profit corporation?
2. No actual technology is announced here. Is the purpose of this post to announce funding? If so, how much funding is it and what are the conditions under which it is provided?
3. How is Stellar compatible with privacy? Keybase mentions MobileCoin in this blog post, but they are only using Stellar's consensus protocol, not the full Stellar protocol. I think that is because Stellar isn't private. What is Keybase doing to solve that if they are using the Stellar network?
1. We are now taking money from Stellar, so...
2. We will support UserA/FiatX to UserB/FiatY in app, whenever we're allowed to talk about it.
Isn't this disingenuous, to say the least? First, traditional banking uses more (for now) but also performs orders of magnitude more transactions. I'd be surprised if banking used more per transaction. Secondly, a bank does a lot of things that Bitcoin doesn't even try to do. I can walk into my local bank and get quarters for me laundry, Euros for my trip, a loan for my house, set up a retirement savings account and get advice on what to do with it, request help if I've been defrauded, and probably a lot more I haven't ever considered.
It's one of the rear cryptocurrency and "blockchain" technologies that actually make sense to me. They have a simple structure: you are able to issue assets/tokens on the network and you are able to send and trade them for other tokens. I think that this simplicity allowed it to gain a lot of credibility with bigger companies (Stripe, IBM, now Keybase, ...), while other technologies like Bitcoin/Ethereum are getting just more and more complicated with 2nd layer networks and locking up tokens in them. They stayed true to the original ideas without introducing a bunch of buzzwords around them and trying to avoid hype in their announcements[2]:
> Our agreement with Keybase entails many practical Stellar-centric deliverables. Rather than giving out a list now and spinning up yet another crypto hype-cycle, we’ll announce products jointly with them as they’re completed or near completion. We know the Keybase team very well and expect they will create critical Stellar ecosystem components over the coming years.
[1] https://www.kalzumeus.com/2014/08/05/harry-potter-and-the-cr... [2] https://www.stellar.org/blog/keybase-and-stellar-partnership...
> And Stellar's lightning network will launch this year.
"We see a future where, say, I can send my friend 100XLM, and, via Keybase, I can send it to her by knowing only her Twitter or Reddit handle."
[1] https://www.stellar.org/blog/keybase-and-stellar-partnership...
There's definitely a very real need for an anchored cryptocurrency that isn't a huge scam like Tether. It's cool that Stellar seems to solve this in a way that doesn't require me to hand over all of my trust to the currency creator.
Also, that FAQ was awesome.
[1] https://keybase.io/docs/server_security/merkle_root_in_bitco...
> Does Keybase itself have Lumens?
Thus far, SDF has supported us with cash — "dirty fiat" — which is what it takes to build software. But yes, we will hold Lumens later.
> But Stellar is not Turing complete
Ok
> Hodl on a second - aren't these anchored currencies the same thing as "tethers" (USDT)? I hear bad things about them.
Sort of. How Stellar's view of real-world currencies is different:
you choose which issuing parties to trust. No one seems to know if Tethers are redeemable. the exchange itself is decentralized; you can change your trust lines whenever you like, and you can trade away the rubbish. This is very different from being stuck in a centralized exchange with one questionable currency-pegged token.
> What about Keybase profiles' support of Bitcoin and Zcash addresses?
This won't change. We continue to be big fans of Zcash (for all the reasons mentioned here), Ethereum (for its flexibility), and Bitcoin (for its relative stability). We're also excited for Filecoin.
We really are pro cryptocurrency across the board.
> Where can I learn about Stellar?
Here's a Talk at Google about it. After the video, you could read the Stellar Consensus Protocol paper. And here's their blog post announcing their support of us.
> Won't this distract the Keybase team from its other work?
All of our existing product (chat, teams, files, identity, etc.) should only get better, with more total resources put into them.
> So are you launching a coin, like MobileCoin or Kik's?
No. We will be helping Stellar in general, not launching our own coin.
> Have you ever heard of the Dutch tulip craze?
It sounds familiar. Have you ever heard of proof by example?
> Any advice on storing cryptocurrency today?
Advice we've gotten is the Ledger Nano S.
> WHAT ABOUT MONERO??
...
There are plenty of other low-fee, non-PoW coins out there, that the article should have spent more time comparing to instead; So we know that stellar doesn't use PoW - what I want to know is why the Stellar consensus algorithm is better when compared to the other similar alternatives out there, and what makes it faster and more secure. They also leave an elephant in the room - how is Stellar more resistant to censorship? What I'd really be interested in reading is why they chose it based on technical merits, rather than talking down other projects.
Stellar will not remain fast, cheap and global. It has counterparty risk in the form of the trusted third parties that form its consensus nodes. These TTPs will censor transactions and introduce costly registration requirements for the same reason traditional fintech companies do: to comply with the demands of regulatory agencies.
The only networks capable of providing fast, cheap, worldwide payments are decentralized protocols without trusted third party intermediaries, like Bitcoin (Bitcoin Cash) and Ethereum.
> The only networks capable of providing fast, cheap, worldwide payments are decentralized protocols without trusted third party intermediaries, like Bitcoin (Bitcoin Cash) and Ethereum.
IMO it is a trade off between degree of trust and scalability. Bitcoin requires no trust but has a costly PoW consensus algorithm which does not allow instant transactions and has a very low tps limit. You can't have both (unless someone comes up with a better consensus mechanism)
>>IMO it is a trade off between degree of trust and scalability.
In my opinion, the right approach to managing this trade-off is to build more centralized platforms on top of the decentralized base layer. That way they have a highly immutable/trustworthy base layer they can all interact on.
An example of this approach is the POA Network, which uses a set of US public notaries to run high throughput validator nodes for a permissioned instance of Ethereum. This permissioned ledger is a side chain of the Ethereum main chain, which can interoperate with it, and has the advantage of being able to scale to 1000s of transactions per second. One could envision multiple trusted or semi-trusted ledgers operating on top of a decentralized ledger that acts as the settlement layer.
I've been using Keybase git and file storage for some time now. Really excited about this partnership!
Lumenette wallet, for reference: https://galactictalk.org/d/1159-lumenette-android-ios-stella...
I’m excited to see this, and hopeful that it takes off. However, I’ve enjoyed utilizing keybase as an identity tool. I’ve had a decent experience with the system as a workplace productivity tool (chat, git). I’m worried that the team will lose focus by branching into a third, and potentially fourth area of focus.
This made me smile.
Just confirms that Stellar is great platform.
>It sounds familiar. Have you ever heard of proof by example?
Well played!
Disturbed by energy consumption, their solution is to divide(shard) the blockchain graph. Does that result in a consensus though? Not in their own prior version.
Will the topology they are claiming emerge? There is no proof.
Since keybase is all encrypted, signed, and authenticated the fact it's centralized only matters as far as the service going down, but the content is all secure.