Scalability

[Red]

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?

lMAO!!!

[1715455524]

1715455524

[Gavin Andresen]

What's funny?

A server lying about whether or not your transactions are valid would be like your ISP lying about whether or not your HTTP requests are valid or not.

If they lie, you'll very quickly find another service provider (or download a Bitcoin iPhone app that doesn't suck and say that your transactions are invalid).

[Red]

What's funny?

I'm in agreement on your points. However you have to admit that what you wrote at the end sounded funny!

Gee, why would an anonymous server lie about my money?  :-)

In reality you are correct. There are very few things to lie about. I could think of a few things though.

[eugene2k]

What's funny?

A server lying about whether or not your transactions are valid would be like your ISP lying about whether or not your HTTP requests are valid or not.

If they lie, you'll very quickly find another service provider (or download a Bitcoin iPhone app that doesn't suck and say that your transactions are invalid).

If you are a merchant and the server tells you that your transaction with a certain client is valid when in fact it is not, then the goods or services you provide, you provided for free. Now suppose this person buys a Ferrari... You're screwed. And that's, in fact, one of the well known types of attacks: an attack on trust. You will of course find another service provider, but the damage will already be done.

[Bitcoiner]

What's funny?

A server lying about whether or not your transactions are valid would be like your ISP lying about whether or not your HTTP requests are valid or not.

If they lie, you'll very quickly find another service provider (or download a Bitcoin iPhone app that doesn't suck and say that your transactions are invalid).

If you are a merchant and the server tells you that your transaction with a certain client is valid when in fact it is not, then the goods or services you provide, you provided for free. Now suppose this person buys a Ferrari... You're screwed. And that's, in fact, one of the well known types of attacks: an attack on trust. You will of course find another service provider, but the damage will already be done.

If you are a merchant, you will be your own server, no? Now if your own server gets hacked somehow with a dummy placed in between, this could be a problem...

[lfm]

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.

I suppose this might be a good reason to make www.mybitcoin.com or an equivalent your primary bitcoin account/wallet. All you need for it is a browser.

[bootfast]

I think then now would be a good point to work out a separate "server" and "client" for the next release.

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.

When these "client" or "lightwight client" will be released? Or something like sample code?
It would be interesting to implement it on, say, java smartcard environment.

[mizerydearia]

Has there been any progress or further discussion on establishing better scalability for future of Bitcoin?

[nimnul]

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)

 

Well, I don't see problems with trust if properly implemented.

The whole idea that downloading zipped blocks is faster than downloading "from network" means performance problems in BitCoin client.

I know that long time ago bitcoin client utilized very little of available bandwidth because of cache flushing after each single block or something like that. But Satoshi fixed that. Did someone test how much bandwidth (of available bandwidth) is used and how much data is downloaded when a new chain is downloaded?

If bandwidth is underutilized - then networking code must be rewritten. If zipping helps to compress chain (I'm not sure because chain contains a lot of hashes and those are random and thus incompressible) - then compression must be built in.  If chain is downloaded many times - then trust scheme must be changed to Emule AICH or similar:
---
Newer versions of eMule support AICH - Advanced Intelligent Corruption Handling. It is meant to make eMule's corruption handling competitive with BitTorrent. SHA-1 hashes are computed for each 180kb sub-chunk and a whole SHA-1 hash tree is formed. AICH is processed purely with peer-to-peer source exchanges. eMule requires 10 agreeing peers regarding the SHA-1 hash, so rare files generally do not benefit from AICH.
---

So instead of asking each peer for blocks, Bitcoin client can ask for block hashes and even for hashes of block ranges (to save hash traffic) to download each block only once.

Also, transaction clearinghouse function can be easily be built in the current network. We can have a "trust network to validate transactions" setting.

Also, blockchain is not needed to generate blocks, so a purely generating node can ask other nodes for hashes needed to build its block instead of asking for chain. And people will be able to contribute either bandwidth or CPU or both. Now they are forced to contribute bandwidth.

I am for example in a remote village in Nigeria connecting over EDGE. 30 MB of chain costs me 9 NGN that is 0.06 USD. But with terabytes of traffic that will not be affordable. Even now 30 MB is not affordable because a lot of people earn less than $200 a month and 0.06 USD is the cheapest possible wholesale price because I pay $80 a month for a 3 GB cap at 120 kbps down / 80 up I measured.

Debit/credit cards industry is not developed here, but everyone has a cheap fake Chinese phone with J2ME and thus capable to run some client software.

[nimnul]

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.

Is it possible to generate blocks if a lightweight generator  ask many nodes for hash of previous blockchain and transactions in current block?

[BASE10]

This has probably been discussed allready but it seem to me that the scalability and performance problems may be relatively easy to solve.

Consider a peer to peer file sharing app. A file is split into a collection of blocks. Each peer downloads the blocks they need in order of priority. Even if none of the peers have all the blocks (original source has gone offline) it is still possible for the peers to piece together their collective copy. I suppose the point is that no one bitcoin node needs to have all the blocks and transactions at any one time for the collective to hold a secure and trused copy between them. So a bitcoin client could have a set limit on the amount of resources that it will use, based on the hardware availiable and the users preference. An indiviual user can hold the information of highest priority to themself and use the remaining resources for other randomly chosen blocks. I suppose this is where transaction fees come in, encouraging users to commit more resources by rewarding them financialy for processing certain transactions of high priority.

I hope that made some sense. I think that is how it is supposed to work, but that comes from reading beteen the lines, so I may be way off.