Hacker News new | past | comments | ask | show | jobs | submit | shea256's comments login

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.


But why would I build a new decentralized Twitter "simply" (it's the HN go-to "I could build that in a weekend" that none of us could build half of in a year if we were actually trying to clone actual Twitter) when all of the money and control is in the centralized version?

Also, if the best example you have is "you can make easily decentralized Twitter after you learn all of our brand new replacement technologies for the things that you're already familiar with" then I don't think that's much of a value proposition.

Also also, come on - "applications will resolve around users"? Great catchphrase, but what does that even mean? Like we don't have product teams already trying to build things people want?


Is Blockstack built on your proposed infrastructure and how the fullstack is built? In another words, are you currently dogfooding?




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


Well, okay, it "represents" a block size increase, so that you can put ~70% more transactions into a block. In reality, it is not a block size increase as the block size will stay at 1MB.

But I don't think that this is enough long term. I would much prefer an increase to 4MB or even 8MB.


Long term 4MB or 8MB (or even 32GB) won't be enough. SegWit enables more sophisticated scaling solutions necessary if Bitcoin wants to become anything more than money for a selected few enthusiast.


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.


That's not an increase in the size of the block per se, as much as it is an increase in the efficiency of encoding off-Blockchain information, no?


Not really. SegWit transactions are on-blockchain like any other - the only difference is that nodes which aren't keeping a full copy of the blockchain can save some extra space by discarding the witness part immediately after processing the block. (So I guess if you wanted to be pedantic you might be able to argue the witness part is off-blockchain in some sense, but even then the transfer of bitcoins still happens on the main blockchain.)


No, it is a space increase! Witness data is counted with a discount. Blocks can be larger than 1MB under SegWit.


Perhaps this is semantic?


It's not semantic, it is substantive. A maximally utilized SegWit block is larger than a maximally utilized current block.

I.e., if you were planning out how much disk space you needed years in advance, you would have to increase that figure non-negligibly if SegWit activates.


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


> But to say they reneged on providing a scaling solution is wrong.

Regardless of your position in the debate, to say that many well-known Core developers reneged is absolutely defensible, given than they signed this: https://medium.com/@bitcoinroundtable/bitcoin-roundtable-con...

The agreement between all these parties was that they'd all support a SegWit soft-fork if Core developers also provided code and support for a ~2mb hard fork.


> Block size doubling and cutting transaction sizes in half each double the throughput.

You can only cut transaction sizes in half once, but you can always double the block size again. Let's just double the block size?


SegWit does not cut block sizes in half it moves some data out of the main block and in to the SegWit block. Full nodes will need more disk space per transaction with SegWit not less.


There is nothing deceptive about saying Core did not deliver on their promise to increase the block size. We still don't have a block size increase. Saying that SegWit provides the promised increase is deceptive. SegWit provides a theoretical 1.7x increase but only if everyone switches to SegWit transactions. To send a SegWit transaction you must upgrade your software, understand how to configure it to send SegWit transactions and be sure that the receiver's software understands SegWit. The only conclusion is that SegWit's effective block size increase will not take effective immediately.

Regardless, Core signed an agreement with a majority of miners that they would implement a block size increase, not an effective block size increase but a real one. They reneged on this promise and are instead telling everyone that they are going to do as they please because miners don't control BitCoin.


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.


Thanks Ryan, these are good clarifications to the parent's post.

For full transparency, I [OP, author of the PDF] am currently contracting with (but am not employed by) Chaincode and am currently #39 by commits (#26 by additions though! ;)). I also think that SegWit is the best way forward; no one pays me to say that.

If Blockstream sent money to developers to endorse SegWit, they must have skipped me!


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.


> Former project lead Gavin Andresen (no longer associated with the project) is perhaps the most notable opponent.

This is incorrect. Gavin Andresen supports SegWit. Your facts are incorrect:

https://www.reddit.com/r/btc/comments/60i4jl/miners_we_are_a...


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.


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.


Then Bitcoin has to hard fork every time someone comes up with a new patentable idea. I don't see why people think mining must be fair. It only has to not become completely centralized.


Someone who can control the majority of the hashrate can enforce a transaction whitelist. Bitcoin's independence from the state requires the world superpowers are not able to control a majority of the hashrate.


> Bitcoin's independence from the state requires the world superpowers are not able to control a majority of the hashrate.

Too late. :-)


But if one miner has a significant advantage for a long enough time then mining will become unprofitable for everyone else, ultimately leading to nearly complete centralization.


People forget that profits can be reinvested. If one miner has 10% extra profits, they will have 10% extra hashrate growth. This leads to effective monopoly.


Hard fork isn't required to fix this issue.


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


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: