Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> So doing even 1000/sec means around 1.8Mbps (plus overhead) just to get the flow of transactions.

Huh, maybe we should come up with a cryptocurrency where you are awarded new blocks for the storage and bandwidth you contribute to the effort, rather than for how many hashes you can calculate per second.

After all, if we're hoping to handling transactions on the scale of Visa, and we don't like centralization, we need to think about decentralized storage of all that information sooner or later. SegWit might not be the perfect answer, but you can't keep requiring everyone to store every transaction that ever happened. We need a solution that is both distributed and publicly verifiable. Something like IPFS comes to mind.

And in order to incentivize people to contribute storage and bandwidth, there would have to be a way to reward those who do so. I think this would be much more useful than the current situation where we basically reward people for wasting a lot of energy.



They don't need to store everything. All that's needed is the list of addresses and balances (UTXOs), and the last few blocks. A hash chain of 10 years of 10 minute blocks is only a few MB, so it should be something we can distribute reliably. UTXOs are a couple GB but will grow.


But, now you have a stateful application running in the cloud, vs an immutable blockchain. And that implicitly means you are now trusting authoritative nodes to hold that state. This is basically moving closer and closer to just a bunch of nodes running a database with some consensus mechanism, rather than an actual blockchain.

(I'm not personally sold that this is actually a distinction that matters - after all, we are already implicitly trusting "authoritative nodes" to deliver the blockchain, and the same mechanism that prevents alteration of the blockchain right now would also prevent altering the database state. Namely, that nobody else is going to accept the version of history where I own infinity bitcoins, regardless of how we record that state.)

A middle ground might be to have the full state available to nodes that want to verify, but also implement a "checkpoint/epoch" mechanism on top for "fast clients" who aren't overly concerned about a massive concerted-but-silent attack on Bitcoin escaping notice.


It's not THAT hard to run a full node, even with 32MB blocks. But for people that want to kickstart a local node, they don't need the entire history if there's a trusted checkpoint mechanism. So they can participate, validate new blocks coming in, while they never or slowly download the historical blockchain.

A hash chain of every block is only a few MB so it's not that big of a deal to make sure the chain is immutably stored.


> It's not THAT hard to run a full node, even with 32MB blocks.

Not at present, but if you increase the block size then you ramp that up pretty fast. Let's say there's a block every 9 minutes (nominally 10 but the network is reactive to increased hash power so it's a bit less in reality). That's 58400 blocks per year, which with a 32 MB block size would translate to 1,868,800 MB per year.

A growth rate of 2 TB per year would very quickly take you past the point where "anyone can have a copy". Yes, it would still be feasible for power-users who could dedicate a whole HDD or some NAS space to it, but that's implicitly conceding the whole "anybody can have a copy" point, and the growth would still be continuing unabated.

And the problem is - Bitcoin's transaction rate is currently so slow that 32 MB is not really a big enough block size. Going from 7 tx/sec to 224 tx/sec is still pitiful for a global network, again Visa does 50k tx/sec at peak.

I agree that it seems highly plausible that some form of "checkpointing" mechanism could be securely implemented.

In fact if you "trust the network" then there's no reason to download the blockchain at all, you can run the Electrum client. And if you think all the nodes are lying to you... how do you ever get the blockchain securely in the first place, regardless of a checkpoint mechanism?


Power users that could dedicated a $50 drive? Storage just keeps getting cheaper. Bandwidth is more likely to be a limiting factor. But looking at dedicated servers, $50/mo gets you 8TB of disk + plenty of bandwidth.

Checkpointing cannot be hard. The hashes of 58400 blocks is not even 2MB. So with a few dozen megs you can checkpoint every single block. Then you can download blocks on-demand if you need to find particular transactions or whatever. What is really lost if we tossed the previous blocks after a year and just kept balances?

But you're right: who needs to run a node?


There are no balances in bitcoin. It's all deltas.




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

Search: