Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keybase is now supported by the Stellar Development Foundation

keybase.io

Post reply on HN
Print view View original

111–120 of 170 posts

Re: Keybase is now supported by the Stellar Development Foundation

#111

Post by andrewjw »

ris wrote: post #62

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" growt…

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.

Re: Keybase is now supported by the Stellar Development Foundation

#112

Post by zitterbewegung »

derefr wrote: post #107
malgorithms wrote: post #2

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,…

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…

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?

Re: Keybase is now supported by the Stellar Development Foundation

#114

Post by floatboth »

ghostwreck wrote: post #82
koko775 wrote: post #59

Welp, time to uninstall. I like Keybase a lot, but there are zero ways in which I want my crypto to mix with my cryptocurrency.

Probably should have done some more research before you installed the first time. Keybase has been mixed with cryptocurrency since 2014 [1] [1] https://keybase.io/docs/server_security/merkle_root_in_bitco...

eh, publishing audit log hashes into the buttchain doesn't really "mix" it on the users' side

Re: Keybase is now supported by the Stellar Development Foundation

#115

Post by 0xCMP »

johnny_1010 wrote: post #21

Why someone use this kind of chat? Same Slack, Hipchat it's look to me like expansive irc. And this "blog post" is more Stellar commercial.

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.

Re: Keybase is now supported by the Stellar Development Foundation

#116

Post by derefr »

zitterbewegung wrote: post #112
derefr wrote: post #107

Earlier quoted context omitted.

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…

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 w…

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.

Re: Keybase is now supported by the Stellar Development Foundation

#117

Post by mankash666 »

zitterbewegung wrote: post #3
malgorithms wrote: post #2

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,…

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…

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

Re: Keybase is now supported by the Stellar Development Foundation

#118

Post by bigcoin »

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

Re: Keybase is now supported by the Stellar Development Foundation

#119

Post by tristanho »

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?

> Any advice on storing cryptocurrency today?

Advice we've gotten is the Ledger Nano S.

> WHAT ABOUT MONERO??

...

Re: Keybase is now supported by the Stellar Development Foundation

#120

Post by giffarage »

eropple wrote: post #8

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 d…

lol
Post reply on HN