Hacker News Reader

Comment by VMG | Hacker News Reader

None of the coins can scale realistically on-chain as a peer-to-peer system. If you run the numbers, the transaction volume of 1B people making one transaction a day goes into the terabytes. If you externalize the costs of verifying that to third parties, you lose properties that make Bitcoin interesting to begin with.

For many people it was clear that off-chain transactions are the only feasible way to solve this. Small purchases in particular do not need to be broadcast to the whole network and can be routed in payment channels. Lighting Network is the most promising solution at the moment.

View on HN

Nothing prevents a sharding as long as you have some way to prioritize in case of conflicts and you require delays from moving money into and out of accounts, but even that's not really needed.

You don't need to store Terabytes per day for 1B daily transactions. BC does it differently, but you could get away with 4 byte time-stamp, 4 byte amount, 32 byte source public key, 32 byte destination public key = unique transaction + 32 byte signature demonstrating sender with correct private key signed that transaction. Now, 1 billion of those = 100GB per day = 36 TB per year which sounds like a lot but most nodes don't need the full amount just current state + verifiable hash + new transactions.

But even that's not needed, suppose every node includes a subset of the account amounts so every K nodes allows you to recover the state of all accounts. That way you don't need a full database just the most recent K nodes and they have complete state. Some people can keep a historic archive, but the system operates even if that information was lost. (You would want some GC as well so accounts must either be larger than A or have a transaction within the last Z steps.)

Granted, managing pending transactions increases bandwidth needs, but nodes can manage reputations based on only forwarding valid transactions. Some metrics so their is some statistical chance of conformation and you end up with ~2x overhead for unconfirmed but likely transactions.

PS: You can also have the protocol grow so if the 11 of the last 20 nodes where full the new node is 1% larger.

> "36 TB per year"

Satoshi made a similar argument in Nov 2008 in response to a claim about Bitcoin not being able to scale:

"The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices."

"If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal."

https://www.reddit.com/r/btc/comments/6navjt/very_first_disc...

Note: this was before the DoS attack in 2009 where hackers tried to freeze the network by creating blocks of uneven or massive size. Which is why in Oct 2009, satoshi imposed the 1MB block size limit (I presume was intended as a temporary stopgap measure) to prevent future similar attacks.

Long after the 1 MB limit was put in place, Satoshi wrote:

>>The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.

-July, 2010

>>It would be nice to keep the [block chain] files small as long as we can.

>>The eventual solution will be to not care how big it gets.

>>But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore. (note to readers, "client-only mode" refers to SPV mode)

-August, 2010

and in an email to Mike Hearn:

>>The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling.

So your explanation for his reasons for putting in place the 1 MB limit are not consistent. Others have said that he was afraid that someone would soon come out with GPU miners and be able to DOS the network with large blocks, so put the limit there as a temporary measure. Now that mining hardware evolution has slowed, and the mining ecosystem matured, this kind of threat is non-existent.

> "So your explanation for his reasons for putting in place the 1 MB limit are not consistent"

Actually the reason I stated is consistent with what satoshi said:

"In 2010, a block size limit of 1 MB was introduced into Bitcoin by Satoshi Nakamoto. He added it hidden in two commits[1] in secret, when challenged publicly he said it is a safety measure to prevent miners from creating large spam blocks." [1]

[1] top of: https://en.bitcoin.it/wiki/Block_size_limit_controversy

But not consistent with what he said after the limit was put in place (see the quotes I provided). The motivation I suggested is consistent with all of his actions and statements.

You missed a factor of 1,000. 100 bytes * 1B = 100GB/day. You Still got the 36TB/year part right though.

Another thing to keep in mind is 100GB/day / (86400s/day) = 9.2MB/sec ~= 90Mbit/sec Internet connection. That's not a small potatoes connection...

Yea, noticed the typo. Anyway, you can get 1,000Mbit connections in much of the world for under 100$ per month which should be able to handle a full node.

Also, most people don't need to actually run a full node to be a miner. Assuming you trust someone running a full node and the block is signed by hash of hash of (node + random value ) < some value then most miners need only get that initial hash from the trusted party which is under 1kb. You can also send back the best hashes you find to the full node to demonstrate you actually have that hashing power.

It's appealing to have a lot of full nodes backing things up, but in practical terms I don't think it makes much difference if there is 1,000 or 100,000 full nodes. The important bit is for anyone to be able to trust the network not just to waste as much computing power as possible. And for that you can verify some random collection of transactions with less than full bandwidth which lets you verify the full node you're supporting.

PS: You could also set things up with shards, but again I don't feel it's nessisarily worth it.

Where do you live? In the US, Canada, Australia, many African countries you aren't getting 1Gbit fiber for under $100!

Don't need home internet connection that fast. Just rent a server at a datacenter near an internet exchange point, and could get plenty fast bandwidth.

Google fiber charges 70$ a month for Gigabit network speeds without throttling in the USA. And get this it's profitable for them without subsidizing it.

https://fiber.google.com/cities/atlanta/

>Nothing prevents a sharding as long as you have some way to prioritize in case of conflicts

That's a pretty big leap - that's one of the biggest problems that Satoshi solved in the original white paper.

If you externalize the costs of verifying that to third parties, you lose properties that make Bitcoin

Isn't that what "off-chain transactions" and the "Lightning Network" are?

Lighting Network is a trustless protocol

If lightning network includes tech that can support billions of transactions, can it be used without bitcoin? Why not use lighting with an uncongested coin?

Yes, any coin that has segwit or a comparable fix for malleability can use lightning. Litecoin is already supported. You can even have atomic swaps between both over lightning channels.

Bitcoin is the most popular with the most resources behind it, so it makes sense to leverage off it. There's nothing stopping similar networks occurring on other coins.

Are there any real world implementations of LN?

Can it operate on it's own, or does it need to be a layer on top of a cryptocoin network?

What incentive do LN node operators have to operate?

Yes, there are three interoperable implementations

https://cdecker.github.io/lightning-integration/

It runs on top of Bitcoin-like Blockchains that have segwit or something comparable.

If you run a LN node you can charge fees for routing payments.

If I pay for something using LN am I going to find it a superior experience to paying with cash or card, or am I going to find it a cumbersome experience for which I am charged an exorbitant fee?

There is upfront work (first you need some bitcoin, then you need to make an on-chain transaction to open a payment channel) but after that, lightning payments are trustless, instant, and with small fees (it's designed to support micro-payments).

But right now this is still VERY early in development.

The goal is to make it simple and inexpensive. Since it supports microtransactions in the sub-cent range and is irreversible, it would beat credit cards in those regards.

The most expensive step would be opening a channel, but there is work on reducing that cost.

Nobody has figured out how to do this yet... nor should they have. You shouldn’t over optimize before you need to and you’ve seen where the real bottlenecks are. But now we need it, and we’ve seen where the bottlenecks are. New technologies and techniques will be needed to match Visa and Mastercard in speed and reliability.

Actually, we should totally have scaling figured out in the design stage. You can’t buy it as an add-on

Reply on news.ycombinator.com