Bitcoin Forum
October 16, 2021, 10:16:48 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 05:44:12 PM
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:
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.
2  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 02:06:05 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.

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.
3  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 11:31:16 AM
Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.
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.

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.

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).
4  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 14, 2010, 01:52:00 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.
5  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 13, 2010, 09:45:39 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.
6  Bitcoin / Development & Technical Discussion / Re: Scalability on: July 13, 2010, 08:13:11 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.

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.
7  Bitcoin / Bitcoin Discussion / Re: Block vs Transaction vs Coin on: July 13, 2010, 06:49:19 PM
what happen if millions of transactions occurs during the block generation, would be block size huge ?

I really love the concept and technology here but I am still trying to wrestle with the implications. I see two potential problems if bitcoin was to become a very popular currency/system.

  • The number of blocks is infinite and the history; the complete chain is important. Even though blocks are small (at least today) I am concerned that this system relies on each peer having a complete record of the entire chain. After many years and supposing hundreds of millions of people generating blocks, wouldn't the size of the chain become untenable?
  • Closely related to the above point: As the number of transactions per-second go up the size of the blocks also go up. If the system ever got to the point of having hundreds of thousands of transactions per-second the model seams unsustainable. One could argue that the number of blocks generated would also increase but this only exacerbates the the issue I pointed out above.
8  Bitcoin / Bitcoin Discussion / Block vs Transaction vs Coin on: July 13, 2010, 03:42:07 AM
I'm a new comer to bitcoin but I am intrigued by the idea and the implementation. I've read the whitepaper twice now and scowered the wiki and the forums but I still find myself confused regarding some basic concepts. Hopefully I don't belabor your patience but perhaps this is a hint that maybe we need to work on the documentation a bit more.

My confusion revolves around the relationship between a block, a transaction and coins. Here are a statement of facts as I understand them:
  • Blocks form a chain.
  • Blocks form the backbone of the Proof-of-Work: a block must be "solved".
  • Blocks contain a header and a tree structure containing transactions.
  • The first transaction in a block is special. The person who solves the Proof-of-Work for the first transaction gets rewarded with the coin value of the block (currently 50 coins but decreases over time).
  • There is a finite number of blocks: 21,000,000
  • I assume there is only a single chain, starting at block B0 and eventually ending at block B21,000,000 - 1.

Question #1:
I guess a lot of my confusion revolves around what a transaction is. Perhaps I have missed something but it seems to me that any documentation I have read seems to gloss over what a transaction is. If blocks form a chain and must be solved, and if the solution of the block depends on the hash of the block, doesn't adding a transaction to a block invalidate the solution? If the number of blocks are finite and blocks are not mutable (transactions cannot be added to them), doesn't that imply that the number of transactions is also finite.

Question #2:
In the context of blocks and transactions, what exactly is a coin? If a newly created block has a single transaction containing 50 coins (as they currently do), how is a coin represented inside a transaction/block?

Question #3:
The whitepaper says, in section 7: "Once the latest transaction in a coin is buried under enough blocks, the spent transactions before
it can be discarded to save disk space." The wording "transaction in a coin" confuses me here because I would have thought it should have said "block" instead of "coin". Perhaps this would be answered by question #2.

I fully expect I am missing something here but I can't seem to find the answers in the existing documentation.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!