BitcoinTalk

Scalability

85
Satoshi-only
BitcoinTalk
#1
From:
jib
Subject:
Scalability
Date:
Am I correct in understanding that every node receives information about every transaction (as the technical paper says)? Doesn't that make bitcoin completely impractical for use as a currency on a large scale?
BitcoinTalk
#2
From:
laszlo
Subject:
Re: Scalability
Date:
Why do you say that?  Pretty much every P2P system works by replicating the information across all the participating nodes, even 100G movie packs for BitTorrent - we're talking about less than a kilobyte of information for a transaction.
BitcoinTalk
#3
From:
Gavin Andresen
Subject:
Re: Scalability
Date:
By the time Bitcoins replace the Euro  Tongue I think most people will be running lightweight clients on wireless smartcards in their (physical) wallet that don't pay attention to every single transaction.

But that's WAAAY down the road.  And who knows, by then maybe we'll all have a hundred-gigabits of bandwidth in our pants.
BitcoinTalk
#4
From:
Anonymous
Subject:
Re: Scalability
Date:
Quote
hundred-gigabits of bandwidth in our pants.


 Lips sealed
BitcoinTalk
#5
From:
jib
Subject:
Re: Scalability
Date:
Every other P2P system is replicating the information across a small group of participating nodes who are all interested in that content. On average each BitTorrent user downloads the movie once and uploads it once and that's it. And if you can't or don't want to download that 100G movie pack (like the vast majority of internet users) you can still use BitTorrent for smaller things.

Bitcoin, on the other hand, gives the whole world (assuming the whole world uses it) a live feed of the whole world's financial transactions all the time, and doesn't stop.

Say it becomes a popular payment method like Paypal or Alipay, which each process a few million transactions a day. That few million multiplied by "less than a kilobyte" makes at least a few hundred MB per day. That's more than the average person's internet usage. In some places it's more than the average person's available internet quota. And then that has to be distributed to millions of nodes, putting a significant load on some networks, not just individuals' connections.

I guess it's not quite as bad as I initially thought, but it's still enough to make it impractical for many people to run their own bitcoin clients in a world where bitcoin is popular. The likely scenario (assuming no change to how Bitcoin works) is that most people use big payment providers instead and those providers use Bitcoin between each other.

And then one of those providers ends up dominating and has more CPUs than the rest combined, and the whole "bitcoin is secure as long as the honest CPUs collectively outnumber any attacker" thing becomes moot.

Maybe.
BitcoinTalk
#6
From:
TopSoil
Subject:
Re: Scalability
Date:
This seems like a great idea but I also don't understand how it will scale? I'm assuming the goal of bitcoin is to be at least as big as paypal right?

I see 3 scaling issues:
1) Having every node need to know about all transactions that happened ever.
2) Keeping the network connected
3) Amount of coins scaling with increased economic activity.


1) This seems like the biggest issue. Is the hope is that bandwidth and storage will keep pace with the number of transactions? Like the OP said paypal has millions of transactions a day. This will totally clog a lot of users bandwidth if they all have to be notified of each transaction.
Is the plan to eventually have the chain drop off old blocks? or is there a way to split the chain into parts so only part of the network has to keep track of certain span of coins.

2) What happens when there are a few million concurrent users? everyone connects to IRC still? (Granted this is fixable as the network grows since it seems outside of the whole block chain system)

3) You have this clever method of slowly introducing coins by time but time isn't really the important thing. Shouldn't the amount of coins in circulation be proportional to the amount of users?  If you want to avoid inflation & deflation the number of coins shouldn't the number of coins be proportional to the number of users or number of transactions or some other metric that is closer to the size of the economy?
(Also I was able to figure out how/why the 21 million number was chosen?)

1 & 2 could be solved by using a distributed hash table:
You should really look at http://en.wikipedia.org/wiki/Kademlia
I haven't looked lately to see if someone has come up with a better distributed storage system but it was by far the best solution a few years ago. (and I've implemented it before if you have questions)

BitcoinTalk
#7
From:
SomeoneD
Subject:
Re: Scalability
Date:
As my first post, I would like to say I'm interested. Experimental Code is always running on this thing, having more won't cause any harm Smiley
BitcoinTalk
#8
From:
knightmb
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 13, 2010, 01:05:24 PM
This seems like a great idea but I also don't understand how it will scale? I'm assuming the goal of bitcoin is to be at least as big as paypal right?

I see 3 scaling issues:
1) Having every node need to know about all transactions that happened ever.
2) Keeping the network connected
3) Amount of coins scaling with increased economic activity.
1) Actually, from what I read in the PDF, I don't think it's necessary. It only needs to know that a transfer of *this* coin from Owner A to Owner B was valid. It doesn't matter if 1 year ago, Owner C gave Owner A that coin.

2) It's P2P, someone out there will be connected. I run a 24/7 Dedicated Server just for Bit Coin now on a Fiber connection. Not because I work with them, but because I see the need to donate the resources for the cause.

3) Don't let the 21 million limit fool you. It's more like 21000000.00000000 limit because the coin is so divisible, but for sanity reasons, it would make sense not to be trading coin in the Quadrillion Bundles  Wink
BitcoinTalk
#9
From:
TopSoil
Subject:
Re: Scalability
Date:
1) Well even if you are right and the system can forget about old transactions, it still is broadcasting all current transactions to all nodes which doesn't scale. And nodes will need to keep collecting blocks forever which also doesn't scale.

2) Yes I know it is p2p that is why you have to worry about how the network stays connected and not just assume everyone will be connected. There are issues like islanding that you have to worry about if you remove a central point like the irc channel is now. This issue is more minor because this problem has been solved before and you don't have to change the way the currency system works to fix it later. I only mention it because I think the solution to 1 will also help here.

3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?

BitcoinTalk
#10
From:
spaceshaker
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 13, 2010, 07:43:01 PM
3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?

I think we need to be clear to separate inflation/deflation from supply/demand.

Quote from: TopSoil on July 13, 2010, 07:43:01 PM
So that means that the value of bitcoins will have to change over time which isn't ideal.

What is the value of bitcoin? It has value only in that people perceive that it has value (the same as any fiat currency). Perceptions change all the time. If you want to see how this plays out look at the currency exchange market today. The value of bitcoin will float over time as supply and demand for it ebbs and flows. The important point is that the supply is fixed (once most of the coins are in circulation) and this serves to protect the value of bitcoin. Inflation erodes the value of currency and punishes savers; its a type of tax.

Perhaps this thread would be more appropriate in the economics forum.
BitcoinTalk
#11
From:
Bitcoiner
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 13, 2010, 07:43:01 PM
3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?

A currency with a fixed supply has 0 inflation/deflation by definition.

You are probably referring to price inflation/deflation, which is a seperate phenomenon and is unimportant as long as there is no monetary inflation/deflation. Even if you wanted to, there is no meaningful way to do it. Just look at how fudged the CPI numbers are.
BitcoinTalk
#12
From:
Strofcon
Subject:
Re: Scalability
Date:
I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.

Now the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that.
BitcoinTalk
#13
From:
Bitcoiner
Subject:
Re: Scalability
Date:
Quote from: Strofcon on July 13, 2010, 09:14:35 PM
I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.

Now the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that.

You have a point here; it would probably be good if there was a mechanism to regenerate lost coins, but I'm not sure how that could be implemented.

As Bitcoins become more valuable, people will increasingly take precautions. Therefore, the loss should decrease as time goes on. Losing 5000 BTCs worth $5 isn't such a big deal; losing 5000 BTCs worth $10,000 is!
BitcoinTalk
#14
From:
knightmb
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 13, 2010, 07:43:01 PM
1) Well even if you are right and the system can forget about old transactions, it still is broadcasting all current transactions to all nodes which doesn't scale. And nodes will need to keep collecting blocks forever which also doesn't scale.
That is a good point, one I didn't think about.  So, let me think out loud here. There are a possible 21 million coins. Every time a block is generated by someone, they earn 50 coins. Right now, I see 66,618 blocks have been generated since the beginning. So that's 66618 x 50 = 3,330,900 coins so far. To reach 21 million, we need to reach 21,000,000 / 50 = 420,000 blocks. 66,618 blocks take up about 56 megabytes of hard disk space. So, perhaps 420,000 blocks (if every single coin is created) would take up about 420000 x 56 / 66618 = 353 megabytes of hard disk space.

The rest would be transaction history to make sure the owners are valid and older transactions are pruned after a while, so perhaps at full scale, this application could eat up as much as 1GB of hard disk space. So, someone correct me if I'm wrong, but even at full scale, the clients would need about 1GB of hard disk space to contain a fully generated coin network?

Quote
2) Yes I know it is p2p that is why you have to worry about how the network stays connected and not just assume everyone will be connected. There are issues like islanding that you have to worry about if you remove a central point like the irc channel is now. This issue is more minor because this problem has been solved before and you don't have to change the way the currency system works to fix it later. I only mention it because I think the solution to 1 will also help here.
From what I read in the release notes, the IRC is just a bootstrap, the new version can work around IRC failure as it has an alternative (but slower) ways to sync up the first time users to the network.

Quote
3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?
Well, imagine if you will, the US and our national gross. It's somewhere in the multi-trillions last I heard. So, if everything had to be converted to dollars, that would be a trillion dollars in circulation (ignore how a complex system like a countries currency, this is way over simplifying).  No imagine all of that was to be transfered into Bit Coins? Well, there are only 21 million Bit Coins, so a 1 to 1 conversion is out of the question. Basically it would have to be scaled back to the decimal points (probably 4 places) to fit all of that in. That still leaves 4 more decimal places in which any economy working in the Quadrillion range is probably out of scope of any country in the world (or all countries combined really)

So, if you don't think of a 1 to 1 conversion for Bit Coins, because even I want to think of Bit Coins as dollars for example. But it isn't. It is it's own currency within itself whose value is only dependent on the people that use it and what value they give it. It's like that for any currency really, the only difference is, instead of the bank or government in XYZ country being the one who controls how it's created and distributed, WE *all* control how it's created and distributed.

We are *minting* the coin (through CPU cycles to generate the encryption hashes) and at the same time using it for trade and value. The only difference is, this isn't a USA currency or a Swedish currency, it's all completely electronic. The bank, the teller, the minting; is all of us at the same time. Basically, all of our clients have agreed upon certain rules to follow and as long as each client follows those rules, it can participate. Any client that doesn't (through hacking, cheating, etc.) is basically ignored by the rest. It's like playing a game of soccer where you have two teams competing and one guy just up and grabs the ball, runs down to the other side and throws the ball in. Dances up and down that he scored a point. Well, everyone else will just ignore him and his point, he wasn't playing by the set rules.  Grin
BitcoinTalk
#15
From:
TopSoil
Subject:
Re: Scalability
Date:
Well The economic discussion probably belongs in a different thread so I'll leave it at that. Oh I went to make a new thread but this guy has made my point better: http://bitcointalk.org/index.php?topic=57.0

knightmb: the number of coins per block is set to go down as time goes on so the number ends up being quite a bit larger than that. Also you have to include the transactions. There have been way less transactions during these first 67k blocks than there will be if millions of people start using the system.

Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.
BitcoinTalk
#16
From:
spaceshaker
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 13, 2010, 09:37:33 PM
Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.

I will second this. I am investigating whether this is a project I want to invest time and energy into (I am a professional C++ developer) as I see the potential for a revolutionary technology. However if the solution doesn't scale to millions and millions of transactions per-day (and a very large number of blocks) I fear this solution is destined to become more of an interesting research project rather than something that will have longevity and practical usefulness.
BitcoinTalk
#17
From:
knightmb
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 13, 2010, 09:37:33 PM
Well The economic discussion probably belongs in a different thread so I'll leave it at that. Oh I went to make a new thread but this guy has made my point better: http://bitcointalk.org/index.php?topic=57.0

knightmb: the number of coins per block is set to go down as time goes on so the number ends up being quite a bit larger than that. Also you have to include the transactions. There have been way less transactions during these first 67k blocks than there will be if millions of people start using the system.

Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.
Thanks for pointing that out, I wasn't sure how that would scale over time, was just making some guess. Given that the formula for coin generation should be known somewhere, can't someone just calculate how much disk space X amount of coins will take given XYZ transactions, etc.

I'm curious myself to how much space it will take.  Smiley
BitcoinTalk
#18
From:
Insti
Subject:
Re: Scalability
Date:
Quote from: knightmb on July 13, 2010, 10:08:58 PM
Given that the formula for coin generation should be known somewhere, can't someone just calculate how much disk space X amount of coins will take given XYZ transactions, etc.
I'm curious myself to how much space it will take.  Smiley

From the pdf:
"A block header with no transactions would be about 80 bytes."
and
"Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space."

so 80 x number of blocks + average transaction size * number of transactions.

Practically, from my disk:
77428 transactions in 66663 blocks is about 46,752,464 bytes.
which works out to about 600 bytes per transaction (including block headers + database overheads)



BitcoinTalk
#19
From:
Gavin Andresen
Subject:
Re: Scalability
Date:
Quote from: Insti on July 13, 2010, 11:34:03 PM
77428 transactions in 66663 blocks is about 46,752,464 bytes.
which works out to about 600 bytes per transaction (including block headers + database overheads)
That sounds about right.

So a million transactions a day would be 600 million bytes.  600 megabytes a day, 18 GB a month.

That's not bad.  Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers).  You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month.  And 18GB isn't much disk space in these days of terabyte hard drives.

A million transactions per day is a LOT!  For comparison, in 2006 there were about 60 million credit card transactions per day in the US.

Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be some fancy IPV6 multicast protocol or something).  And they'll implement a couple of gateway nodes (running on really fast connections) that shuttle transaction and block traffic from the current Bitcoin network into the super-efficient network.  And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

You know, kind of like how we have those Big Routers in the Sky that handle Internet backbone traffic (or the ultra-fast DNS root servers).  The Internet didn't start out with astoundingly fast routers zinging packets around.
BitcoinTalk
#20
From:
spaceshaker
Subject:
Re: Scalability
Date:
Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

Is this possible? What would this look like? From a technical perspective what does a "lightweight client" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.

I am just thinking out loud here...

Although the peer-to-peer model is certainly novel perhaps it seems to me to be somewhat utopian. Bear with me for a minute here (I am not trying to troll). Consider banks. Banks have a system whereby they can work together efficiently. I take take money out of a ATM from bank X even though I bank with bank Y. Banks loan money to each other. They are generally cooperative. Instead of every Tom, Dick & Harry having a Bitcoin client on his/her PC (or smartphone) participating in an open P2P network, perhaps there is a collection of Bitcoin "banks" who provide the service of hosting and "peering" the Bitcoin block chain. These are large enough organizations that they can afford the bandwidth and hardware needed to maintain an infinitely long block chain with a million (or more) transactions a day. These banks would still be peer-2-peer, and hopefully also completely open. Ideally anybody could participate in the peer-2-peer network, its just that the average person won't because of the barrier to entry. These banks still operate using the same fundamental technology we have to day. All of the beautiful facets of Bitcoin are preserved, except that the number of active participants is somewhat reduced. Anybody that _wanted_ to participate still could.

The problem remaining would be the typical "last mile" problem. How does Tom (or Dick or Harry) perform transactions? Well the issue becomes much more straight forward at this point. Now the trust only has to be between two parties (the "bank" and Tom). This really becomes more of a proxy issue. Now Tom has to send a transaction request through his "bank". It might even be possible to bake into Bitcoin a protocol for proxy transactions.

Anyway...This is just my 2 cents. I would really like a tangible answer to this problem because it seems foundational to the success of this endeavor to me.
BitcoinTalk
#21
From:
jib
Subject:
Re: Scalability
Date:
I think a lightweight client would need to trust the fast node it talks to that sees every transaction.
BitcoinTalk
#22
From:
TopSoil
Subject:
Re: Scalability
Date:
Quote
That's not bad.  Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers).  You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month.  And 18GB isn't much disk space in these days of terabyte hard drives.

Not bad? huh? That seems totally broken to me.
I'm less worried about storage space than the bandwidth and time it will take a new node to enter the network.
Like you said the blocks are duplicated so a given node must download some multiple of the transactions a day. That is a tremendous amount of downloading.
Also any new node must download 216GB for each year the network has been this large!

Doesn't the system also just completely break at some point when the rate of transactions is too high? I could be wrong since I'm not sure exactly how it is decided which transactions go into a particular block. Again the pdf is kind of lacking.

Also isn't there a problem when 2 computers both solve a block before they realize the other one has? This will become more and more likely as there are more nodes.

Quote
Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be

But it seems like a lot of these things aren't just issues of network structure. They seem inherent in the cryptographic design so it wouldn't be that straight forward to replace. Plus why not address these issues now if only to instill faith that the system is well thought out rather than just wave hands and say "computers will be faster" or "we'll tack on some better networking later"


Again I think the general idea is great and I hope the developers have good answers for all these questions. I just want to understand it/make sure it has been thought through carefully enough. I sincerely hope that it actually can work. I'd love to never have to use paypal again.

BitcoinTalk
#23
From:
Gavin Andresen
Subject:
Re: Scalability
Date:
Quote from: spaceshaker on July 14, 2010, 01:52:00 AM
Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

Is this possible? What would this look like? From a technical perspective what does a "lightweight client" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.
I'm imagining:

A lightweight client would have a wallet with coins in it (public+private key pairs).

And a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.

The lightweight client sends money by:
  creating a transaction (signing coins with the private key)
  sending the signed transaction securely to the ultra-fast server, which puts it on the network.
  receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)
   (or getting a "you already spent those coins" error from the server)

The lightweight client receives money by:
  Either polling the server every once in a while, asking "Any payments to these BC addresses that I have in my wallet?"
   ... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees
    a relevant transaction with N confirmations)
  When transactions occur, the lightweight client updates its wallet (adds the coins).

You don't have to trust the server; it never has your private keys.

Well, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?

BitcoinTalk
#24
From:
knightmb
Subject:
Re: Scalability
Date:
I think then now would be a good point to work out a separate "server" and "client" for the next release. Those want to run servers that sit on fast fiber connections and run 24/7 (like myself) can do this for the good of the service. Those that just want to send money from point A to point B can use the client which either function as a full blown node server (like it does now) or give the option to connect to "trusted" servers in the network and just have the server do the hard work and report back to the client when coins are transfered around properly.

Since the network can be participated by both dedicated server farms and Joe Blow with his laptop, you still maintain the open network and crypto security that you need, but also offer another solution for those less technical and wanting an easy click and send interface that they have now, website payments, etc.

I mean, I'm seeing stories about Bit Coin all over the web now, so the popularity is coming quickly and people are going to poke around the source code and program, then come here to make suggestions/complaints/worship/etc.

Might as well get a head start.  Grin

It's win/win because people can run thin clients, people can run servers, and those that don't trust either can run their own client/server/p2p application themself, but it all benefits BitCoin one way or another.  Wink
BitcoinTalk
#25
From:
Gavin Andresen
Subject:
Re: Scalability
Date:
Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.

There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:
Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.

I think Satoshi has done an amazingly fantastic job; over the last two days of Bitcoin being "slashdotted" I haven't heard of ANY problems with Bitcoin transactions getting lost, or of the network crashing due to the load, or any problem at all with the core functionality.

Yes, it's annoying to have to wait for the block chain to download (especially with the Microsoft Security Essentials weirdness), and yes it would be nice if all the pieces of Bitcoin functionality were already nicely separated and ready to be rearranged and extended in all the ways we all want to rearrange and extend it.  But I've been poking at the Bitcoin code for over a month now, and the more I learn the more impressed I become at the thought that's gone into it.

This quote seems appropriate:
"We reject: kings, presidents and voting.
We believe in: rough consensus and running code."  -- David D. Clark
BitcoinTalk
#26
From:
spaceshaker
Subject:
Re: Scalability
Date:
Quote from: gavinandresen on July 14, 2010, 04:22:49 AM
Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.
Quote from: gavinandresen on July 14, 2010, 04:22:49 AM
Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.

I agree with both points but they also seem to be somewhat mutually contradictory to me (this may be because of ignorance more than anything). Perhaps you can illuminate what steps you think need to be taken to "make it easier for merchants to accept bitcoins and users to pay using them". In my view, having a lightweight client, build on fairly open standards would facilitate making transactions easier. Ideally this lightweight client would/could be implemented in a number of languages/platforms.

Quote from: gavinandresen on July 14, 2010, 04:22:49 AM
Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.

This is certainly good advice: "beware of premature optimization". I would like to point out though that optimization and system architecture are different beasts. Planning for scalability is a system architecture task. The whole "Don't overengineer" paradigm is more of an implementation & design principle and suggests that we should be agile in that we only implement what we need today. An agile perspective does not preclude thinking about and planning out the system architecture, at least testing assumptions mentally and ensuring that "it could scale" when the time comes for that ability to be added. I have been involved in a number of projects that failed not because the underlying technology was bad, but because scalability was never considered or tested up front. Everything worked perfectly until the system was put "to the (scalability) test". A lack of planning and foresight up-front was usually the cause.

Quote from: gavinandresen on July 14, 2010, 04:22:49 AM
This quote seems appropriate:
"We reject: kings, presidents and voting.
We believe in: rough consensus and running code."  -- David D. Clark

I like this quote. There is certainly something to be said for having something that works. I tend to struggle with being a bit of a purist; I have to work at pragmatism. Having said this, you can say: "we have great software. It has very few bugs and it hardly ever crashes" and that all sounds well and good until the day it becomes untrue. Scalability issues can hit you quickly and silently, especially in this day-in-age.

My preference would be, for a project like this, would be to continue to have "working software" but also establish a well defined road-map of where we hope the software is going. This road map needs to discuss scalability and how we envision a system with a million transactions a day would work and looks, not just today but 20 years from now. A currency needs to be resilient. For people to assign value to Bitcoin they need to perceive that it has value and that it is safe. This means they need to be able to trust that the infrastructure & design is (and will be) perpetually reliable. Unfortunately I don't Bitcoin, if it is to be successful, as the luxury of being just another hacked together open source project (I'm not implying that it is hacky...I'm implying that the prevailing mindset and practice in open source tends to be a "hack it together" mind set).
BitcoinTalk
#27
From:
TopSoil
Subject:
Re: Scalability
Date:
Quote
There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:
Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.

He is also talking about a website. The scalability issues with websites are well known and solved and can be easily tacked on as you get bigger. So yeah you don't need to worry about them when you start. bitcoin is a whole new beast.

Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system. And I think isn't necessary if you design the system right in the first place.

It seems like the best thing would be to lay the system on top of a DHT like kademlia. Maybe you can do this later I'm not sure. Again the documentation is lacking so it is hard to tell if you can easily break the chain apart in order to stick it in a DHT later. I was hoping the devs would stop by and answer maybe they are too busy improving the docs...


BitcoinTalk
#28
From:
spaceshaker
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 14, 2010, 12:39:51 PM
Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system. And I think isn't necessary if you design the system right in the first place.

It depends on how it was implemented. I don't think having transaction clearing houses necessarily excludes p2p. It depends on how the network was implemented. Assuming things remained open, the transaction clearing houses could still be p2p. Anybody could join in and work to clear transactions. It's just that it wouldn't be required in order to send/receive transactions. It would actually be extremely beneficial if there were literally thousands of transaction clearing houses or if some regular users did participate in the full system to prevent the established clearing houses from conspiring together to cheat the system. That is one of the beauties of bitcoin IMO.

Quote from: TopSoil on July 14, 2010, 12:39:51 PM
It seems like the best thing would be to lay the system on top of a DHT like kademlia. Maybe you can do this later I'm not sure. Again the documentation is lacking so it is hard to tell if you can easily break the chain apart in order to stick it in a DHT later. I was hoping the devs would stop by and answer maybe they are too busy improving the docs...

Although DHT is an interesting concept I don't know if it really solves the problem. Smartphones are a good use case:
  • You don't want to be acting as a peer on a p2p network with a smartphone. It hurts battery life and it could be costly in cellular data charges.
  • Smartphones don't have the processing power or storage capacity to either process blocks or store even parts of the block chain.

The future is not desktop PCs but is "thin" machines like smartphones, tablets and netbooks. These lightweight devices will vastly out-number PCs in the years to come. It isn't tenable to participate in p2p from a thin device, at least in the forseeable future. I think Gavin's ideas of a lightweight bitcoin client seem to address this issue.
BitcoinTalk
#29
From:
D҉ataWraith
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 14, 2010, 12:39:51 PM
Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system.

Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).

Edit: Even more closely related: Kazaa and Gnutella work the same way, too. You connect to a supernode that then searches for files on your behalf.
BitcoinTalk
#30
From:
TopSoil
Subject:
Re: Scalability
Date:
Quote
Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).
Sure it can work that way but is that the ideal? Doesn't that make the network less robust and more vulnerable to attacks and manipulation? What happens if some attackers start running a cluster of supernodes? The main point is why rely on this more vulnerable architecture when you don't have to? It isn't easier to implement.

Quote
Edit: Even more closely related: Kazaa and Gnutella work the same way, too. You connect to a supernode that then searches for files on your behalf.
Yeah and I would argue neither of those systems are very well designed. Limewire replaced the gnutella routing with Kademlia actually.

spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.
BitcoinTalk
#31
From:
Jman
Subject:
Re: Scalability
Date:
Having to download the entire chain also causes issues with new user acceptance.  I installed bitcoin on an older box I have and it took about 4 hours to download the entire chain.  As time goes on this is only going to get worse.  While this is a minor annoyance for most people here with fast connections and servers, if bitcoin were to actually get wider acceptance outside the tech circle it would be a deal breaker.

Say your neighbor wanted to buy something with bitcoins.  You tell him to install the program, then go to the exchange and buy some coins.  Sounds great, right?  How do you think he will feel about the transaction when he has to wait 8 hours after installing the program to get his bitcoins because he has to download a chain with 200,000 blocks?  Do you think he would recommend it to his friends?  To gain more widespread acceptance, initial transactions would need to overcome this factor.
BitcoinTalk
#32
From:
knightmb
Subject:
Re: Scalability
Date:
Quote from: Jman on July 14, 2010, 04:06:13 PM
Having to download the entire chain also causes issues with new user acceptance.  I installed bitcoin on an older box I have and it took about 4 hours to download the entire chain.  As time goes on this is only going to get worse.  While this is a minor annoyance for most people here with fast connections and servers, if bitcoin were to actually get wider acceptance outside the tech circle it would be a deal breaker.

Say your neighbor wanted to buy something with bitcoins.  You tell him to install the program, then go to the exchange and buy some coins.  Sounds great, right?  How do you think he will feel about the transaction when he has to wait 8 hours after installing the program to get his bitcoins because he has to download a chain with 200,000 blocks?  Do you think he would recommend it to his friends?  To gain more widespread acceptance, initial transactions would need to overcome this factor.
I agree, I've been looking into packaging "blocks" for download so that you can install the client, unzip a fresh stack of blocks and let the client finish off the rest to get people up and running faster. I'm experimenting with Windows and Linux clients (don't have a Mac that can run the Mac client, sorry folks)

Hopefully that will help with the issue.

Of course, the trust factor comes in (should I download these from this guy instead of letting the network do it for me)

 Wink
BitcoinTalk
#33
From:
D҉ataWraith
Subject:
Re: Scalability
Date:
Quote from: TopSoil on July 14, 2010, 03:59:18 PM
Quote
Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).
Sure it can work that way but is that the ideal? Doesn't that make the network less robust and more vulnerable to attacks and manipulation?

Not really. If you're worried, you can always run your very own server.

Quote
What happens if some attackers start running a cluster of supernodes?

Nothing. Unless you happen to use one of those supernodes, which you don't have to, because you can run your own supernode. Or use a trusted one, much like people trust Google with their E-Mail.

Quote
The main point is why rely on this more vulnerable architecture when you don't have to? It isn't easier to implement.

It isn't easier to implement? I'd like to see some proof here.

Counterexample: The totally distributed E-Mail system developed at Rice University is a hell of a lot more complex than running a (network of) semi-centralized mail server(s).

Quote
spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.

Um. That's exactly what a supernode server would do.
BitcoinTalk
#34
From:
knightmb
Subject:
Re: Scalability
Date:
I've had luck with testing of packaging blocks into a zip file and dumping them on a new Bit Coin to speed up the block download process. I'll leave the link in my signature and if anyone finds it useful or time saving, feel free to donate.  Wink
BitcoinTalk
#35
From:
spaceshaker
Subject:
Re: Scalability
Date:
Quote from: D҉ataWraith on July 14, 2010, 04:42:16 PM
Quote
spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.

Um. That's exactly what a supernode server would do.

Um. Sure. I think I've gone full circle. I think Gavin said it best:
Quote from: gavinandresen on July 14, 2010, 02:20:45 AM
A lightweight client would have a wallet with coins in it (public+private key pairs).

And a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.

The lightweight client sends money by:
  creating a transaction (signing coins with the private key)
  sending the signed transaction securely to the ultra-fast server, which puts it on the network.
  receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)
   (or getting a "you already spent those coins" error from the server)

The lightweight client receives money by:
  Either polling the server every once in a while, asking "Any payments to these BC addresses that I have in my wallet?"
   ... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees
    a relevant transaction with N confirmations)
  When transactions occur, the lightweight client updates its wallet (adds the coins).

You don't have to trust the server; it never has your private keys.

Well, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?

In this scenario, the Bitcoin client could remain largely the same as it is today, although the focus would be that it is used on the "super-nodes" or "transaction servers" or "proxy servers" (these systems would probably serve all three roles) or by anyone wishing to play in that game. If the Bitcoin client was augmented to use DHT then that may be improvement but there is still a need for a "lightweight client" as Gavin described above. It seem's Gavin's "lightweight client" concept obviates my scalability concerns somewhat.
BitcoinTalk
#36
From:
BitLex
Subject:
Re: Scalability
Date:
Quote from: gavinandresen on July 14, 2010, 02:20:45 AM
Quote from: spaceshaker on July 14, 2010, 01:52:00 AM
Quote from: gavinandresen on July 14, 2010, 12:42:32 AM
And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.

Is this possible? What would this look like? From a technical perspective what does a "lightweight client" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.
I'm imagining:
....

you don't even have to imagine , actually it's already possible to "remote-control" the node, so just create ur own little lightweight-client, that just sends and gets some info to/from your (highspeed-connected, hdd-packed) homeserver.

some kind of "managed server-client-version" already exists in MyBitcoin, you could run something like that on your own webhost and connect to it from wherever u are on whatever connection-speed.

the "lightweight client" doesnt have to be one, but connect to it and tell it what todo.
we can do that with JSON.
BitcoinTalk
#37
From:
InterArmaEnimSil
Subject:
Re: Scalability
Date:
I second the DHT idea for maintaining a client list - we can't have millions of people relying upon an IRC channel, etc.  As far as the scaling issue goes, the issue is not at all HDD space, its network bandwidth.  Everyone is forgetting, its not bytes_per_transaction*transactions, which is the number everyone is using.  That number, as everyone has said, is fully manageable.  No, the number we're interested in is bytes_per_transaction * transactions * number_of_clients * total_hops_beyond_first_between_all_clients_combined

THIS is the amount of bandwidth which the protocol for BTC consumes as the network scales.  We're not just talking about sending one copy of each transaction to each client - we're talking about multiple clients broadcasting potentially redundant data to one another, and doing it across numerous hops, meaning numerous rebroadcasts.  Much larger number, much more difficult to handle.  However, it is manageable, just not in the current incarnation of network handling in the client.

Perhaps in the "popular" phase, BTC chains could be broken up by region, similar to the purviews of domain name authorities now - and there could be an alternative protocol for transactions across these regional boundaries?  This would help the raw numbers of the problem, and also cut down on latency and related issues.  Not that I think this is an excellent solution - but P2P flooding across all active clients is obviously out barring some massive breakthrough in quantum computing or whatnot.
BitcoinTalk
#38
From:
satoshi
Subject:
Re: Scalability
Date:
The design outlines a lightweight client that does not need the full block chain.  In the design PDF it's called Simplified Payment Verification.  The lightweight client can send and receive transactions, it just can't generate blocks.  It does not need to trust a node to verify payments, it can still verify them itself.

The lightweight client is not implemented yet, but the plan is to implement it when it's needed.  For now, everyone just runs a full network node.

I anticipate there will never be more than 100K nodes, probably less.  It will reach an equilibrium where it's not worth it for more nodes to join in.  The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.