shea256's comments

In my view a big way to fix these problems is to allow for multiple clients to compete on the same underlying social network protocols. Semi-decentralized (federated) social networks like Mastodon have done great work here. Even better would be completely decentralized equivalents of Twitter, Facebook, etc. There are several impressive projects working on enabling these decentralized apps. One such project is IPFS. Another is one I'm working on called Blockstack.

> Today there’s a lot of work going into decentralized distributed storage keyed on blockchain indexes; Storj, Sia, Blockstack, et al. This is amazing, groundbreaking work… but why would an ordinary person, one already comfortable with Box or Dropbox, switch over to Storj or Blockstack? The centralized solution works just fine for them, and, because it’s centralized, they know who to call if something goes wrong. Blockstack in particular is more than “just” storage … but what compelling pain point is it solving for the average user?

Ryan here from Blockstack. Our goal with storage is to allow users to bring their own storage (e.g. Dropbox, Google Drive, iCloud, etc). We believe in re-using the best infrastructure out there and not reinventing the wheel.

The key is that Blockstack delivers a thin layer on top of all of these storage providers with a common interface and end-to-end encryption, reducing them all to dumb drives. This (1) removes the potential for vendor lock-in (2) puts pressure on all the providers to be more competitively priced (3) enables greater data security.

Additionally, Blockstack isn't just about storage. It's a full stack for an entirely new kind of internet and a new way of building applications. Developers can work with a new blockchain-based domain name system (BNS), a new user-owned identity system, and a new BYOS storage system. The dream is for developers to be able to create a decentralized twitter by simply publishing a bundle of html, css and JS. The app folder runs as a single page application in your browser and can exist and replicate and live beyond the developer without the need for server or database maintenance. Servers could be relied upon for push notifications and feed aggregation, but they wouldn't be critical for operation and they'd be throwaway.

All this represents a pretty massive shift away from the model today. Instead of users revolving around applications, applications will revolve around users.

Blockstack (https://blockstack.org/)

Hi! This post really resonated with me because of my experience with how previous efforts at re-decentralizing the web have failed.

In my view, adoption will always be held back as long as there's:

a. a UX gap (in both software and dev skills)

b. a lack of innovative open source business models

c. an absence of completely novel apps that couldn't have been done before

We're trying to tackle all 3 at Blockstack with our developer platform but it's not easy. Would love your thoughts sometime on whether we're on the right track and how else we could help you out as a developer.

SegWit does in fact represent a block size increase. Here are some of my thoughts on the matter: https://news.ycombinator.com/item?id=14075274

You're right, I mean that he's opposed to the "segwit only for the near term" plan. IIRC, he is in favor of segwit plus a block size increase.

Absolutely, and thank you for the post! And congrats on working with Chaincode, I didn't know that. I can no longer edit my post unfortunately but at least people can see this follow up. Keep up the great work.

SegWit does in fact represent a block size increase. It results in 1.7x the # of single-signature transactions per block and 4x the # of multi-signature transactions per block.

Unlimited block size? There are many reasons that's a very bad idea but here are a few:

1. It would put immense pressure on the network in terms of latency between miners, leading to less stable mining, a higher rate of reorganizations, and a massive advantage for the larger miners, resulting in increased mining centralization.

2. It would result in a substantial increase in the amount of bandwidth that each node has to handle. Modest increases are OK but unlimited blocks means the vast majority of nodes will die off. Remember that nodes have to check blocks as they come in, so this would be an insane DDoS vector. Imagine putting a funnel in someone's mouth instead of a straw and being able to force whatever you want in there.

3. It would result in a substantial increase in the amount of data that each node has to store. Remember that in Bitcoin 100% of data must be stored by 100% of nodes. Imagine "unlimited emails" with Gmail meant that you had to store all of the emails in the world for EVERYONE. Not a good idea.

> Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged.

This is not true at all and highly deceptive. They originally were supportive of doubling the transaction count via an increase to 2MB blocks and then realized they could accomplish this without a hard fork via SegWit.

SegWit does in fact allow for 1.7x the number of single-signature transactions per block and 4x for multi-signature transactions.

Core absolutely could have handled the communications around this better. But to say they reneged on providing a scaling solution is wrong.

It's also important to keep in mind that what matters is not the block size but the number of transactions that can fit into a block. Block size doubling and cutting transaction sizes in half each double the throughput.

A few red flags came up for me with this post. I feel I have an obligation to post a response to this to clarify some things, lest people less involved in the community come away with a misinformed view.

A few facts on the core developers:

-- There are hundreds of developers who contribute to Bitcoin Core. Over 50 of them have 10+ commits to Bitcoin Core.

-- Blockstream employs 7 of these developers, including Pieter Wuille, Luke Dashjr, Greg Maxwell, Jorge Timon, Patrick Strateman, Warren Togami and Mark Friedenbach.

-- By number of commits, the developers Blockstream employs are ranked #2, #8, #13, #14, #19, #35, and #50, respectively.

-- Another company called ChainCode Labs employs 3 of the top 50 developers, including Alex Morcos, Suhas Daftuar, and Matt Corallo (formerly employed by Blockstream).

-- By number of commits, the developers ChainCode employs are ranked #5, #11 and #12, respectively.

As for SegWit, it is a multi-faceted gold-mine of an update with many, many benefits to scaling, security and efficiency:

1. It fixes the substantial transaction malleability problem once and for all.

2. It improves the efficiency of signature-hashing so it scales linearly rather than quadratically.

3. It 1.7x's the # of single-signature transactions per block and 4x's the # of multi-signature transactions per block.

4. It enables second-layer scaling solutions like Lightning.

5. It upgrades pay-to-script-hash transactions from 160-bit hashes to 256-bit hashes.

6. It makes it safer for hardware wallets to sign transactions by explicitly hashing input values.

7. It reduces the growth of the system's most burdensome resource: unspent transaction outputs, which are ideally kept in memory.

8. It introduces versioning for the scripting language to allow for more easy upgradeability.

Here are some facts on the developer consensus:

-- Out of the top 100 committers to Bitcoin Core, almost all of them believe that SegWit is the best way forward. There is near unanimous consensus on that front. Former project lead Gavin Andresen (no longer associated with the project) is perhaps the most notable opponent.

-- Out of all of the wallet providers, almost all of them are supportive of or at least OK with modest block increases. Almost all of the major wallet providers have prepared themselves to be ready for SegWit.

Exactly, I'd go further and say that if a particular technique is patented and cannot be matched by a related technique, giving a permanent unfair advantage, it is up to the community to change the proof of work and work around the advantage imposed by a state monopoly.

The assumption is there are nodes already running from previous releases.

No bitcoin never had a rollback. Bitcoin was forked before to fix bugs, but no state was ever reversed and no prior protocol rules were ever violated.

If you dig below the surface you might see why it does.

For example, how would you imagine a system could implement key revocation and signed statement revocation?

Yes, I responded to your helpful feedback. Thank you.

Hi author here. Thank you for pointing this out and sorry, I meant to mention that I edited it.

Oh I love that idea.

As far as Django, Blockstore is on Pypi so you can just install and import the library.

I think it'd be great to have modules for Rails, Node, etc.

I saw your tweet and I'll shoot you an email. Also feel free to open an issue on github.com/namesystem/blockstore and we can discuss the idea openly there.

Love this.

The post mentions using the blockchain for unique username registration and mapping to public key hashes, and as it turns out there's a project I and others have been working on that does exactly this called Blockstore.

Here's the link if anyone wants to check it out: https://github.com/namesystem/blockstore

The way it works is there's a mapping between a unique name and a hash in the blockchain, and then there's a mapping in a DHT from the hash to the data to be associated (which can be a plain old public key and can also be a JSON file that references a public key and other identity information).