Blog author from Keybase here. Always game for a Hacker News discussion!
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.
Didn't the "tokens backed by something off-chain, and then a fork happens" already happen with Digix?
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.
Indeed, I don't think it's a deal breaker as well. There is a huge potential for scams, here, though (people buying invalid tokens for near than nothing on ethereum classic, then luring unawared people to buy them at full price misrepresenting them as the real thing). In this case, forks basically create counterfeits.
I don't understand how the stellar case and the bitcoin case differ in a network partition. You said "if Stellar fell apart and became partitioned, you would stay on DB's side."
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.
Note that in general there is no way to name a particular branch of a blockchain fork. In cases with a protocol change coordinated well in advance, a counterparty anticipating the fork could announce that their tokens on one branch will be useless. However, if you just have two competing mining pools duking it out with the same protocol, there will be no way to name the branches ahead of time.
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.
I'm not familiar with the "trustlines determine partition choice" feature of Stellar, but I am with trustlines in general; they are explicit app-level concepts that you define on your wallet, which in this case would say something like "I trust DB to redeem up to 1m worth of EUR credits".
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.
Your justification for the Th/s being an issue for electricity consumption is one I have seen bounced around a bunch but other than the justification of the environment there are other issues. But, the idea of cryptocurrencies is that without some kind of artificial scarcity you will have other incentives. If you are really concerned about electricity consumption what about using a ledger technology that is designed for low resource consumption such as Sawtooth? I'm not sure how Stellar helps you in this regard. Also, why are you seeking more funding in the first place?
"Also, why are you seeking more funding in the first place?"
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 mean that artificial scarcity is enforced by a distributed ledger system is by using the concept of a miner. The best implementation we have so far that is electricity consumption because this makes people consume electricity which costs them money. If you don't have this piece then people will subvert the proof of work some other way.
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.
i wouldn’t say that’s true at all. proof of work isn’t the only “artificial scarcity” that we can have... its paying money to compute some thing to get a vote... why not just put money for a vote? or better yet, prove that you have the means to pay a lot of money for a vote.
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
I think scarcity is a bit of a red herring. The key is that it has to be more lucrative to play fairly than to cheat (well, it also has to resist attacks that are simply trying to destroy the service). Proof of work by itself is not enough. It's the scaling of the difficulty to the potential gain -- the implication being that more people mining == more money to be gained by cheating.
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.
Regarding electricity consumption, what do you think of the argument that mining is so competitive that it can only be profitable by subsidized electricity, and that electricity is only subsidized when the local jurisdiction is creating more of it than it needs anyway? In other words, mining doesn't actually create new demand for electricity, it just soaks up the remainder already available.
"electricity is only subsidized when the local jurisdiction is creating more of it than it needs anyway?" is false - there are a few cases of negative spot prices, which nonindustrial customers can't get, but all the rest of the time electricity subsidies are for economic and social reasons.
Normally surplus electricity results in a curtailment of fossil sources.
There is no such thing as "excess electricity". If that power wasn't being wasted on useless cryptocurrencies, then we could have used it for useful purposes, such as processing aluminum.
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.
That argument makes no sense to me. It essentially boils down to "people can choose whatever level of security they want, so given that they chose the current level of security that must be the most energy efficient -- and since merchants have to pay for this system they always choose the cheapest fees which must therefore mean they choose the miner with the cheapest energy source". I'm not sure what this argument is meant to prove other than PoW chooses the most energy efficient way of doing PoW, but it doesn't prove the PoW isn't an energy hog.
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).
I’m not going to spend a bunch of time reading this particular whitepaper, but not one of the three proof-of-capacity “mining” systems I’ve looked at are Sybil resistant and decentralized.
This is a vast oversimplification, which only sounds plausible if you pretend that energy production scales linearly with demand. In the real world, if there's a plant producing more than its consumers demand, the reason for the excess capacity is to accommodate spikes and future growth. If you come along and build a BTC mining rig next door, that "future growth" has arrived sooner than expected, forcing the utility to build new capacity years ahead of schedule (presuming it's feasible to build it at all), resulting in significant price increases, their refusal to sell you as much electricity as you want to buy, or both.
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.
Hydroelectric is one of the oldest electrical storage systems there is -- you can store more electricity as gravitational energy by pumping the water back uphill, and then letting it flow back down during peak times.
There's a reason why hydroelectric plants and dams go together.
Very few dams have the capacity to pump water back uphill.
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.
With massive regional grids like what's present in North America, it's not just as simple as that. Someone on the other side of the continent could use your 10TWh excess and curtail their own fossil fuel use instead.
I was wondering the same, why not add more options, just make it easy for people to get paid by whatever they want. Its also possible to simply just put a .txt on your public shared library and you can always list everything and anything you want there. Its just nice to see all that nice verification in the public profile nice and easy to see for everyone else.
Perhaps they'd be worried that their tool would be used primarily for narcotics trade. Oh wait, they already have zcash. Well, perhaps it's the redundancy between those two.
This doesn't exist right now, but theoretically a network like Ethereum whose tokens exist as state within Turing-complete contracts, could solve "counterparty redemption across forks" by simply allowing each contract to react to the fork "event" independently on each resultant forked chain. It'd be a lot like how the actual POSIX fork(3) call works!
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.)
I think this would create a bunch of security concerns and make the state of the contracts not immutable and would result in even more problems. Even though the contracts are deployed on a chain it they also take resources to execute (which is represented by gas) so at the end of the day if this occurred you would basically have one master contract with all the resources which would be a huge security concern since who is enforcing that people are honest?
Contract state isn't immutable. Or am I misunderstanding what you mean by "state" here? The storage slots in an EVM contract can be freely written to by said contract. That's how ERC20 tokens work—the balances of the token in people's accounts are simply storage slots, that get updated by the contract when the tokens are moved around. (Yes, actual slots. EVM arrays are weird; they actually expand out into the contract's storage-slot keyspace by hashing all the array indices together and storing the result at the slot identified by the hash.)
> 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.
I've been convinced by Mazières and the Stellar team
As someone who's been in the cryptocurrency space for a long time I can guarantee you got swindled. Countless investors I have seen move to centralized "blockchains" due to buzzword powerpoint presentations and floating_nodes.jpg bootstrap landing pages.
This is no different than what current financial institutions do other than a new UI.
Are you saying this after having read up on Stellar[1] in particular or is anything other than "full" decentralization a deal breaker for you?
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.
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 don’t understand this comment. It doesn’t seem to address any of the key technical points behind the Stellar project as it is actively used today, but instead tries to imply that the foundation is some group of fly-by-night scammers that have won over keybase by nothing more than a twinkle in their eye.
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?
the foundation is some group of fly-by-night scammers
Never said that. There are plenty of institutionalized and heavily trusted ventures on wall street that rake in billions and buy their way to the top.
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.
It's possible more than one system could replace SWIFT, but why would it be Stellar/Lumens who are still in the gate with their fork when Ripple/XRP seem to be already round the first bend with seemingly very large momentum in terms of interest, trials and actual production use by financial institutions?
How is Stellar still "in the gate," more than two years after deploying their decentralized Byzantine agreement algorithm?
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.
Yes, but perhaps your framework for approaching this is a little too old school?
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.
While I generally agree, there is a difference between what bankers are doing atm with their ledgers and SOME projects in the private permissioned ledgers space. The difference is that they are not Byzantine fault tolerant, and distributed. If even just between each other, so there isn't the sort of robustness that you would have otherwise. It reduces a lot of overhead they have atm, with their ACH system. Which works, but it is not perfect.
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.
Last time Keybase came up I made sure to post about how great using it is and that I am super-duper enthused about Keybase. I entreated 'malgorithms to let me give him money for Keybase. And I have recommended Keybase to a ton of people and a bunch of my clients, using it in a bunch of workflows. Now those people and those clients are going to have cryptocoin bullshit stuffed into a work tool?
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.
Harsh. Nothing about this post implies a monetization play. The whole point of Keybase is identity verification. How is it not a natural evolution for them to explore trusted cross-border, multicurrency transactions?
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.
Maybe it would be helpful to consider what it means to have a crypto wallet (because that's the likely endpoint here, otherwise why would they have to partner with Stellar?) on production servers. Consider explaining to a client that, no, it's totally fine, it doesn't do anything. I promise. Doable, I'll grant you. Consider explaining that to an auditor. No, nobody can ever compromise this, nobody could use this for shenanigans, it just doesn't do anything!
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.
Given that the protocol is open and the app code is available, I imagine there will be plenty of cli clients that just do not implement the currency stuff. Or at least I hope so, given that I share the above concern.
Keybase started out with an identity system because it was the key foundational module to create their entire e2e encrypted software system.
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.
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?
The main problem is that dealing with money has all sorts of legal implications for businesses.
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.
Google wasn't the first search engine. Facebook wasn't the first social media site.
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.
I recommended Keybase to people as a security tool. This isn't security. There is no reason for cryptocurrency bullshit to exist in tools I rely upon. There is no reason for cryptocurrency bullshit to exist things that I use in production capacities.
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.
I could maybe see your concern if Keybase were announcing an ICO for their own token, but that is not what this is.
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.
There's nothing wrong with reverting a recommendation. Sounds like you have a great explanation for why you would revert your own recommendation, as well. Just like every other startup in the world, Keybase doesn't "owe" anything to you and might make business decisions that affect your own.
I'm sorry, maybe I misspoke--is there something in my post that suggests that they can't do it? I'm saying that them doing it sucks, and explaining why. And, yes, of course I can change my recommendation--what would make you think that I'm not aware of that?
Rofl, I definitely share some of the sentiments you have regarding crypto is a scammers paradise. That is pretty much due to ICO's imho. What you might want to do, if you do use this in production servers, and I am sure the keybase team will add the option not to use it, it is open source. So you can easily simply remove that, I know that creates a bit of work and will therefore make it harder. I am just saying if this is being used in something that you find as useful, than the extra effort is definitely worth it. There simply isn't a tool like Keybase out there anyway. They literally solved the WOT issues related to PGP, and now they are adding some extra features which can potentially lead to other use cases. There are always upsides and downsides to anything. Imho, the upsides here might be justified, given the unique position that keybase is in.
Otherwise known as "things that make ordinary consumers (ones without the time or desire to get deep knowledge about something) choose competing alternatives".
To put it bluntly, this seems like your own irrational biases against a technology than any real issue. Having a crypto wallet tied to an identity management service does make perfect sense because of the reasons detailed in the article.
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.
That's great--but I don't care about what value you see when making cryptocurrency transactions. I care about the security and uptime of my services, which is why we started using Keybase in the first place.
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 don't understand why you're upset (genuinely, I don't understand) about them adding new features. Are existing features reduced or worsened in some way I don't understand?
Let's say you recommended Slack and your company started using it. Then Slack adds PornHub integration. Wouldn't you be upset? Would you say: "just don't use it"?
So adding a distributed change/audit log - don't forget, that's all any blockchain really is - is the deal breaker and will cause you to fail audits or break production systems? How is it different from the GPG chain that is the Keybase changelog?
What is it about this change that makes you assume you're going to have to deal with cryptomining et al?
Nobody said they'll be injecting anything in their apps, where did you read that?
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?
"All while integrating certain Stellar features directly into Keybase's apps."
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?
Because cryptocurrency has a very high potential for propagating failures or legal risks. It's like being given a free piece of asbestos with your sandwich.
It's also prone to reputational risks; basically everyone who hears about cryptocurrency almost immediately either loves it or hates it.
> It's like being given a free piece of asbestos with your sandwich.
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.
If 1Pass added an optional bitcoin-browser miner, would that make you feel better about its security? What if it partnered up with BonziBuddy and pinged you during the installer? Just simple choices, they don't affect the security profile at all.
I assume that the incentive already includes “the sorts of files people typically bother encrypting include wallets and private keys”, whether or not the file encryption service itself integrates cryptocurrency directly.
It would be kinda nice if keybase had a setting to turn off features. My mom doesn't care what git is, but she is a regular for chat and interested in keybasefs. Same with a wallet, if a user could hide it and forget about it there wouldn't be any reason for it to bother them.
I think the reverse: Keybase should be aiming for a minimal feature set and allow for extending it.
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.
I read the GP, and some other comments, as equivalent to:
* 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.
Clumsily putting cryptocurrency features in their app will look bad, I agree. Hopefully it won't be "jammed in" and in-your-face: just another feature among many (besides, doesn't it make sense to manage your keys for things, including cryptocurrencies or any other application, on something called keybase?)
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.
Gosh, really unfair to Keybase. From the moment I became aware of Keybase I've been thinking about where and when would be the nexus with cryptocurrency and smart contracts. Keybase does a nice job of relieving pain for me and my business and until proven otherwise I give them the benefit of the doubt.
This is an interesting comment as I’m not sure what the goal was aside from wanting to vent to the internet.
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?
I don't see what the issue is of a development tool supporting blockchain development. Like it or not, this tech is here to stay, and blockchain devs need very similar tools.
This post is very oblique in a way that makes me suspicious.
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?
> And traditional banking, with its branches and offices and free dog treats, uses even more electricity than Bitcoin.
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.
I first heard about Stellar from Patrick's (patio11) Harry Potter post around 3 years ago: Harry Potter And The Cryptocurrency of Stars[1]. I have been following Stellar closely since then and am also running one of the biggest Stellar communities.
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.
Stellar is a postgres database under the hood and its just the stellar concensus protocol (SCP) that determins which queries/transaction to apply to your database in tandem with all the other nodes
I've stopped recommending keybase since they removed all references to being able to do operations directly with gpg (which is a real shame - it worked incredibly well and was the best example I've ever seen of web/CLI integration). The whole thing is becoming very opaque and startup-y and hey-we're-an-app have-you-downloaded-our-app why-not-app-our-app app-app-app-app... I'm really not a fan of these "minimal" growth-hack-y websites which seem so popular these days.
Just curious, around how long ago was this change made? Can you find web.archive.org links for a page which was changed? I'd find them useful for discussions with my peers.
The gpg approach was available in September 2017, when I used it to setup my account. I can't tell you any better than that though, and that's part of the nature of opaque aggressive growth startups today. Things just disappear or change with no acknowledgement of the past unless it's part of the story the company wants to tell about itself today. It's reasons like this that I tend to lose all interest in a project as soon as I hear they've taken VC.
You get a sense of positivity by just going through the stellar website and documentation (eerily similar to Stripe). It is beautifully designed and easy to understand. Kind of gives the feeling that they are in it for the long run unlike many other get rich quick Ponzi cryptocurrencies out there.
I recently had extensive contact with someone on their support staff(Robert) regarding issues with my stellar coins(issued back in 2014 which I had completely forgotten about until a month ago). We exchanged probably 10-20 emails trying to resolve my issue, which was eventually satisfiable resolved. I came away with a very positive opinion about the seriousness of the team.
The thing I love the most about Stellar is how its founders want it to become "the SMTP of payment". It's kind of amazing we still haven't such kind of protocol widely available, and have to rely on private companies like Paypal, Stripe or any bank's IPN to send money on the internet, decades after its creation.
Very cool news. It's always exciting to see Keybase introduce new features, and the thought process behind them is usually pretty interesting to read.
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.
How does this change the threat model for using keybase? It would seem to increase the target value of compromising the client. Is that immediate impression wrong?
what does prevent you from storing your private keys today? Nothing. The association with Stellar might imply a higher likelyhood of something valuable crypto related being there. However, I don't care, if the security of keybase is somehow broken, I'd rather find out early on and with the increased exposure, they may be getting free pen testing.
The FAQs are the bottom are amazing. Seems to cover just about every HN objection ever:
> 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?
I <3 Keybase, though I wish I could generate my device keys with pgp rather than only having keybase do it for me. And of course, I'd love to store an ssh key with keybase...
I wasn't convinced about Stellar in that article. Some arguments given were strawman like, especially when attacking proof of work (PoW) or other things that are irrelevant because Stellar is something completely different. Besides, I found the overall tone to be somewhat condescending, especially due to the Monero snide at the end.
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.
Isn't Keybase a for-profit corporation? What does it mean for a non-profit to support a for-profit? An emtry in the FAQ explaining this would be appreciated.
>>We think Stellar can fulfill Bitcoin's original goal of fast, cheap, worldwide payments.
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.
Only the third party issued tokens have counterparty risk i.e you trust the issuer to redeem them somehow. Is that different than an ethereum ERC20 token? The native asset itself (XLM) has no counterparty risk.
> 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)
XLM and everything else on a ledger like Stellar's has counterparty risk, because consensus on these types of ledgers is established by a set of trusted third parties. The TTPs are counterparties, and if they fail, the ledger fails.
>>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'd be really interested in adding Twitter (etc) support to Lumenette with help of Keybase, if possible. Hoping there will be an API for other wallets to interact with the features Keybase is working on.
I've been using Keybase git and file storage for some time now. Really excited about this partnership!
Given that stellar/lumen is a fork of ripple/xrp, and ripple/xrp seem to have a massive head start with what 100+? bank and payment providers already on board - are stellar/lumen not just competing head to head with Ripple with essentially the same technology but with a handicap of being behind in terms of development and not having an in-use production network and settlement solution?
I feel like there's a very real synergy possible here. Keybase has a solution covering security, identity, chat and multi-device usage that could be very interesting when combined with a crypto-currency like Stellar Lumen. I wonder what they have in mind in terms of features. Any guesses?
Attaching a transaction history and wallet to an identity perfectly positions keybase as a player in the credit scoring industry.
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.
Sorry if this question is a bit stupid but could somebody enlighten me on why Keybase seem to regard Monero quite poorly? From what I've heard it seems that its anonimity is more trusted than that of Zcash at least, and both it and Zcash are proof-of-work coins anyways. Is it simply because they already had Zcash, so they'd rather not put something similar in there?
That's a very good partnership! Since Keybase maps social media identities to encryption keys in a publicly auditable manner, as well as Stellar implements Lumens as a digital asset designed to work as a medium of exchange that uses cryptography to secure its transactions, to control the creation of additional units, and to verify the transfer of assets
this is going to be awesome. I need to look at that now. So many coins to be aware of and to study to navigate a seemingly confusing new world, though.
I was just thinking this morning how keybase would be useful as a tie-in for crypto identity on blockchain, when this is desirable. This is fantastic news.
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.
Because it's end-to-end encrypted for just the people in the chat. Slack and Hipchat store the logs in the clear for themselves and the contents could be revealed if they were ever hacked. Since they're also centralized this poses an issue because they're an easier target than say a member of the chat's device.
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.
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.
[2] https://news.ycombinator.com/item?id=16125920