Bitcoin Forum

Hi All:

I'm new to bitcoin, but understand its philosophical basis very well (anti-Fed, pro free-currencies, etc).

I've been playing around with it today, sending payments back and forth between computers and trying out some of the vendor sites....all in all very very cool.....but there is something I'm confused about.

Why can't I send fractional cent payments?

Perhaps its something that I don't yet understand, but to me that seems to be a fairly glaring omission. How can true price discovery happen on a single item (say a PDF) unless fractional cents are possible (ie. maybe access to some digital file is only worth .001 BTC).

As I said, perhaps I'm missing something basic, but I can't seem to figure out how to make the Mac or Linux client send fractional cents.

Regards.

The protocol supports precision up to eight decimals. The client does not yet expose this much precision.

Here's a high-precision transaction, for example:
http://blockexplorer.com/tx/c7033a2693d18979c49dce4414582b0f241e38b99ef339586e3c284069aeaf5a#o0

Thanks for the info.

Do you know of any plans to update the clients to support that?

The reason I ask is I have a few ideas that I think could be interesting, but if currently 1 bit coin is approx .25USD, the idea is not feasible since it would be cheaper for people to pay in traditional currency.

Thanks.

The current two-decimal precision is not enough for your needs? 0.01 BTC = 0.0025 USD.

The high precision is to deal with deflation, not for extremely low-value transactions. Currently the vast majority of generators won't even accept sub-0.01 transactions. The full precision will probably not be widely available for decades, if ever. Another decimal or two might be added sooner.

Even if most generators did accept sub-0.01 transactions, I expect a transaction fee of at least 0.01 to be required for all transactions in a few years, which would defeat the point.

Where can you send $.0025 or less?

Updating a client to display the additional decimal places is the easy part.  Convincing the network that you really need that kind of precision is more difficult.  If you have an idea that you can articulate that might require additional precision, let us know, but you can currently send fractions of a cent.

Thanks all for the info, I was mistakenly under the impression that a bitcoin was .01 instead of the whole integer (yes, silly mistake)

So, for my purposes .01BTC is fine.

I had nearly the same mistake! Thanks for helping!!!

The reason the min tx is 0.01 BTC is to avoid the network being flooded with tiny requests, it's an anti denial of service measure.

I can understand that completely, especially for not allowing .00001 style transactions.

However, why not allow 10.123 to go through? (I know the protocol supports)

Currently, in my 401K I own 1524.34 shares of a mutual fund that is valued at $10.25 each....yielding a total worth of 15,624.485 for that fund.

That's a good point, actually.  I'm fairly certain that 10.12345678 would be processed without a transaction fee required, as it should be a greater than comparison.  However the vanilla client doesn't support it at present. 

I doubt that micropayments will be possible and sustainable long-term through the Bitcoin network, so long as every node must learn about every transaction.  There's just not enough bandwidth on a typical internet connection to receive 100 bytes each time anybody anywhere in the world buys a snack or a sword in a game or seeds for their farm.  Micropayments are feasible now while there is unused capacity for free transactions, but as soon as Bitcoin's user base grows to fill that, the transaction fees needed to balance supply and demand of network resources will make micropayments from stand-alone clients infeasible, if for nothing else, the transaction fee will be too high.

Services like Mybitcoin.com are about the only way micropayments are going to be possible long term.  Such services would aggregate them and complete micropayments "off the block chain", and standalone Bitcoin protocol would be left as the backbone for large transfers of money - and the digital equivalent of the "gold in the vault".

Agree. I think it's cool how bitcoin is bootstrapping itself potentially all the way to a global reserve currency.

There just isn't a need to settle over the network for every little thing once that has some cost. It still makes sense to denominate in bitcoin so that you CAN settle when/if you need to. Centralized database keeping isn't a problem and has a few advantages if people can snap leave like bitcoin allows.

Well I think a set of small changes could make the bitcoin network scalable and add the ability for micropayments. First of all a structured network is needed since the just broadcast to everybody method used now is incredibly network intensive, then we have to split the network in two parts, one is composed of all generating nodes (they need to know all transactions) and non-generating nodes (just publishing blocks with aggregated transactions is enough for these). Also one might start thinking about segmenting the network by adding a second smaller difficulty which aggregates transactions in a small cluster which would then be aggregated and signed off by the core network composed of the current implementation.

The current network design does not scale at all, we need to either change it or build a micropayment system around it :D

No.

In practice, Mybitcoin.com is essentially already one such "super node".  It just happens to interact with its users via a web site.

Care to elaborate?

See previous posts in same thread, bitcoin banks will handle that much better than any blockchain.

In the current design, yes, a bitcoin bank handles micropayments better.  I was more concerned with the "does not scale" phrase I quoted.

Where can I find a careful performance analysis of bitcoin?  How does it scale with millions or billions of users, in terms of such things as transaction speed, computational and memory requirements per node, network bandwidth requirements, ...?  

An ideal system would allow a billion human users all to issue 0.0001 BTC transactions at the same time, and have all such transactions (for those users whose local network and computer resources function adequately) to complete in under a second.  I presume that neither bitcoin nor any other system we are aware of can reach this ideal.  But I doubt bitcoin can succeed unless it has a performance analysis (http://www.greenteapress.com/compmod/html/book003.html), preferably of peer-reviewed research paper quality, and a clear strategy for dealing with whatever manner and way it falls short of the impossible ideal I described.

But I'm new here; so likely such a performance analysis exists and I just have not noticed it yet.

It does not scale well for micropayments as every single transaction has to be written down forever in the blockchain stone.

You are mixing up different things.
 - Performance of the bitcoin client algorithms used for transaction verification
 - Performance of transaction processing

The former is described in satoshi's PDF.
The latter is, by design, subject to the market (see transaction fees)

You have to define more clearly what you mean by "completed" for a transaction. Bitcoin transactions are broadcast instantly to the network and currently propagate pretty fast (seconds). Is that a "completed" transaction ? Or is it "completed" when it's buried under three, six, a million blocks ?

I think the community is eager to get reviews on satoshi's paper, I won't call it peer review because it has never been stated anywhere (to my knowledge) that satoshi is a researcher, he might even be a group of people.

See previous answers, and welcome :)

That transaction processing is subject to the market does not eliminate the requirement (in my view) to understand its algorithmic performance characteristics.

That transaction processing is subject to the market does not eliminate the requirement (in my view) to understand its algorithmic performance characteristics.
[/quote]

 - I'm a client, I broadcast a transaction to the network and all of its miners,
 - I'm a miner, I get the transaction, I include it in my merkle tree (inexpensive), and I keep mining. The mining algorithm is basically brute force SHA hashing on a fixed size message, so it's o(1) in relation to the number of transactions that are included in the currently mined block.
 - If I find a block I broadcast it (see research on P2P technology in relation to performance/thoughput/you name it)
 - A block is broadcast to me, I update my merkle tree and root and I keep crunching (every 10 minutes on average), I would (maybe naively) assume that the merkle tree update is o(n) in relation with the number of transactions that were previously included in the candidate block

Hmm, writing this post I'm starting to think it might be nice to have a full fledged, peer reviewed, detailed, and thorough analysis of all the factors that need to be balanced for optimal performance but that doesn't change my main opinion which is that bitcoin won't be good at micro-payments.

So ... how does this work after bitcoin has been successful for several decades, and we have trillions of past transactions, but only hundreds of millions of active users providing meaningful compute power for mining?

In other words, does the cost of mining increase over time with a higher exponent than the number of computationally useful mining nodes?
 

I am quite willing to agree that bitcoin as currently conceived is not well suited for micro-payments, without some additional supporting infrastructure, outside of the core bitcoin mechanism.

However, it might be possible, once such a full fledged analysis of these factors had been done that this would illuminate the way to core algorithmic improvements in this or other useful regards.

See http://www.bitcoin.org/bitcoin.pdf chapters 7 and 8

You seem to assume that it is desirable that bitcoin be good at micro-payments, I don't think it has any importance whether the core protocol is inefficient at it or not.

Good - thanks.

Of course I think it is desirable.  Why would I think not?

I agree that it appears out of reach, at least given our current understanding.

But if the core mechanism provided perfect security and instant validation of millions of simultaneous payment requests of value from tiny fractions of a BTC to billions of BTCs, why would that not be desirable?

The closer we can push the core mechanisms to that ideal  imaginary  goal, the better, all else being equal.

First however we need to reverse engineer the protocols, validate that specification with the successful implementation of alternative, fully compatible, clients, and subject the network behavior to a rigorous algorithmic complexity analysis.  I presume there are others with similar goals, who have already made some progress in such directions.  As I read through old posts on this forum, I will likely find postings mentioning such efforts.

I think we need to clarify 2 issues, which are really distinct. Since I started this thread I'm responsible for not clarifying this. When we are talking about "micropayments" (a bad choice of a term on my end) there are 2 issues:

• Payments that are an order of magnitude less than normal "useful" transactions (eg. .001 USD)
• Payments that happen at greater than 2 decimal places precision

These are actually 2 distinct concerns, and it is the 2nd issue that I'm most concerned with. Mainly because BTC is by design a natural deflationary currency (its value of BTC relative to USD has already gone up 5x since July).

Even if Bitcoin only achieves a moderate success of having 200K active users, given the fact that only 5M BTC are in existence, this is going to lead to heavy deflationary pressure.

I don't have an economic concerns about this - as the Keynesians have been consistently been proved wrong with regard to liquidity concerns - double so since as a purely electronic currency its trivial for us move a decimal place over.

So, my point is that inevitably *all* transactions are going naturally require moving one decimal place over. We are going to have a sort of reverse Zimbabwe problem on our hands, particularly how to on-the-fly add more decimal places.

Honestly, I think the choice of only having 21M possible BTC was a design flaw. Precisely because its going to force us into an unnatural and unwieldily situation with regards to decimal places. What do you even call .00001? Why introduce this complexity in the first place? In retrospect I think it would've been better to have a 2B maximum cap, solely for the reason is it would help keep notional representations into the whole integer range.   

I don't know what your desires are unless you express them.

Perfection would be nice of course. But it would be just as nice to me to have mechanisms handling that outside of the core mechanism.

That's not realistic, you'll always have trade-offs.

Yes, there is a documentation of the protocol.

This is a non-issue, make a client that displays your balance in nanoCoins and BOOM, your supply is now 21,000,000,000,000,000 NTC
Protocol and client evolutions will introduce 10 extra decimal places if it ever becomes a need.

Just because something doesn't seem realistic at present doesn't mean we should not prefer it, were it available.

It may be a non-issue to the minority of us who can shift decimal points about with ease, but for the majority of humans, currency units need to be scaled to practical values.

My point is : I do not think bitcoin will be good at handling lots of micro-payments, it is by design. Nor do I desire this capacity. Of course, if someone removes limitations without impacting the core functionality, sure!

But from my experience and the information I gathered from different sources it seems to me that it can't be achieved in such a way, therefore I think micro-payments will be handled by bitcoin banks, not by the block chain. And from my experience, this position seems to be a consensus amongst the bitcoin community.

We're in agreement.  I just understood your "not desire" position to mean "it would be wrong even if we could", whereas I take it now that you meant "it is not something I seek, because it almost certainly cannot be found."

Peace.

You misunderstood, nanoCoins would be integers displayed to the user handled under the hood as 1e-9 BTC.
Transferring 1 BTC to this client would display a balance of 1,000,000,000.
This really shouldn't be worried about

Technically it won't need to be worried about, logistically it will.

You want Amazon to eventually support BTC right? Does their current system support .000001 precision?

People do not work in isolation, seeing BTC's only via their BTC client.

They also talk about them, read about them, see such values displayed on potential offers to buy and sell, ...

Human factors absolutely should be worried about.

Whether merchant X or Y supports bitcoin is up to them, if they see a profit opportunity, they will make it happen, no matter how many decimal places bitcoin has.


You guys are worrying about something that could only happen if bitcoin was widely adopted, fearing that it would prevent its adoption by new users. You see how it is a non-issue ?

You're changing your tune, from
  "It should not be worried about -- it's a non-issue because users would not  notice if their clients were displaying nano-bitcoins",
to
  "it should not be worried about now, because it will not matter for a long time."

Well, if it will matter in a long time, then (1) it might be easier to address now, while bitcoin is young, (2) if it is not addressed, it could harm acceptance, as some savier people will not adapt something in the short term that doesn't have a long term path to success, and (3) you're still wrong that users would not notice whether their client displayed bitcoins or nano-bitcoins.

I'm merely presenting two sides of the same coin and two reasons to not worry about something that is in no way an issue.

Nobody knows whether it will actually matter, maybe bitcoin will be used the same way as gold, to store value, maybe it will be used everyday by my girlfriend, maybe it will be used to back other currencies.

What could really harm acceptance is a weak economy where it is hard to get a hold of real goods and service in exchange for your currency, no matter whether this currency is called "bitcoin", "bitcent", "nanocoin", or "john mac douglas the third".

I never said users wouldn't notice, I said they wouldn't care, as long as they get to manipulate almost-integer values.

It's not how many bitcoins are issued that matters, it's whether it's possible to order 24/7 sushi with them that matters.

Educate yourself about the protocol, you'll discover that it's future-proof in lots of ways.

You're free to keep worrying, that would suck though, I don't like worrying.

Well and there I was assuming the really nice part of Bitcoin was it's being completely decentralized, by letting "banks" do the aggregation you not only create single points of control but also single points of failure. It's nice that they also act as aggregation points, there's no discussing this, but the system should be developed in a direction where it becomes better scalable and may potentially handle all transactions natively, as long as we're not there I'm be fine with having aggregation points but the ultimate goal should always be a currency handled only by the peers.

P.S.: micropayments is not the only place this applies, basically the network does not care if I move 0.01 Bitcoins or 100 Bitcoins, but we'll incur the same problems when growing in the near future.

In its current capacity and form, I don't think Bitcoin can be used for micro-payments in the manner as being suggested here.  I am quite certain that the current restriction on payments less than 0.01 BTC is going to be relaxed... indeed I would make a call for that to happen now simply because when parity hits for 1 BTC == 1 USD that fractions less than 0.001 BTC are going to be necessary simply to function with the Bitcoin economy.  I also think that within the standard Bitcoin client there ought to be a way to "adjust" fees and set up rules for how you (or I) would accept transaction fees based on a number of criteria.  For the most part, barring some huge crushing load on the Bitcoin network, I would like to hope that a cent would be allowed to be transferred without fees or certainly for marginal fees somewhat less than a cent.  It is something I think most miners would be willing to incorporate into their fee structure too.

This is built into the network protocol, but the current standard implementation doesn't permit the inclusion of these smaller transactions and certainly doesn't account for the deflation of the currency as is happening right now.  That is a big deal that does need to be addressed. 

The current "standard" restriction of charging 0.01 BTC for transactions less than 0.01 BTC is something that ought to change, but that still doesn't deal with very small micropayments that are less than the rough equivalent in 2000 inflation-adjusted U.S. Dollars of less than $0.01 USD equivalent in bitcoins.  I think that is the main thing being suggested here on this thread and that is to me indeed something that ought to be included, but it would require a slightly different protocol than currently exists for Bitcoins.  Regardless, I see the day that Bitcoin might be used routinely in such a way that miners are going to be expecting fees on the order of what is now about 50 cents or maybe even a buck in terms of the current value of FRNs and it is still useful to think of how to accomplish microtransactions using Bitcoins, because it has value in and of itself.

Two approaches that I can think of basically involve either a peer-to-peer system or a central server for interchange of micropayments.  Both approaches essentially follow this basic principle:

Micropayments are "authorized" for a certain Bitcoin address and transmitted to an accounting system of some sort.  When somebody "owes" past a given threshold (as established through some sort of protocol... either an agreement of sorts or perhaps the threshold is set by the person receiving the micropayments), their "account" will have to be settled by transmitting Bitcoins in presumably a large enough quantity that transaction fees won't eat up the cost of transmitting the payment.

The idea here too is that those who go past the threshold are simply kicked from the micropayment system, so there is an incentive to settle up accounts.  This threshold, if it is kept low enough and depending on what is being offered for the micropayments, isn't going to be the end of the world if somebody simply refuses to pay up.  Many on-line services usually have a trial period trying to encourage people to sign up, so you can say that this payment threshold is simply the freebies that you would give away anyway to entice people into using the service in the first place.

In terms of a central server system, the largest problem there is that you give up anonymity as the server at least knows your IP address (discounting proxies and other by-passes.... those can still be traced BTW) and other ways to trace who you are can be done with such a system.  In a peer to peer system, anonymity can be stronger but it would also be easier to "cheat the system".

As a way to keep hardcore "cheaters" from gaming the system, you can even have "tiered" services where you must maintain at least some sort of account, where those who routinely settle up accounts can have access to a broader range of services.  It doesn't stop somebody from ripping off a whole bunch of people, but you have an investment into your account by doing so and keeping those who would generate random new accounts by the thousands from being able to leech off of the system.  In order to get "the good stuff" you need to show at least some resemblance of a history of making payments... a "credit history" as it were and a "credit score" that shows that you can be trusted within the network.  A new account would obviously lack such a history.

This is something that I think is important to work on, but it would be outside of the scope of the main Bitcoin protocol except for settling up accounts and acknowledging payment.  Payment to a given Bitcoin address certainly can be verified.

I actually think we're going at it the wrong way, the problem is not so much that micropayments are prohibited by the current implementation, that was just a reaction to people voicing the concern of a DDoS, which then actually was carried out (don't remember the thread right now).

The thing is that the current network topology and message routing is not scalable and a large number of transactions will actually bring it to its knees. It just so happens that using a nanobitcoin makes it really easy to put heavy load on the network, hence the code avoiding small transactions. But I do see a huge increase of the number of transactions in the near future, and we will see the same limits be hit again.

One of the very frequent questions I have to answer to is "how scalable is the Bitcoin network?" and my usual answer is that it isn't at all scalable. Simply the fact that every transaction is broadcast in a random fashion is incredibly wasteful. Were we to adopt a nicer system (pulling transactions only when a block is found, upstream aggregation, DHT style responsability sharing, ...) it would work so much nicer and would scale better.

The current limitation on the size of transactions is just trying to cure the symptoms but the root cause can only be cured by a better structured topology, improved routing mechanisms and a reduction in message complexity!

Flood-fill scales in practice, because interested network parties keep upgrading to handle the load.  DHT is pointless, as you could lose information to network partitions or simply if an unlucky set of participants disconnects.

Overall the current system is designed for Big Players With Capacity to survive on the P2P network long term.  It is simply not meant for small players.

Unfortunately we continue to await the development of the much anticipated "lightweight client" that will not need to receive every tranasaction and echo it, etc.  satoshi added the "getheaders" network message recently in order to better support lightweight clients, which permits casual connectivity, pulling only the block headers needed since last connection.

I would rather we just remove the "fee for < 0.01 transactions" rule.  If people want to spam, they can spam with 0.01 BTC transactions, and fill up the free-TX area in each block.

If they can change the text next to the field to say BTC then they can make it say NanoBTC too. This is a non-problem.

Not really a good argument, why impose the need to keep up, if simple changes can lower the barrier? Remember that if we can think of it, others will too, if we don't implement it, others will. And if they do you can be sure they'll start a new block chain, eventually surpassing our community in size, because of the added flexibility, and thus making all our hard earned Bitcoins worth less.

Which is basically the implementation of a 2 hierarchical system as proposed earlier. It is by no means the definitive solution to everything, since even the inner network will eventually become too busy to handle the message complexity.

Making everyone else pay? To be really resilient we have to make the network Dos proof, and while there is no definitive solution to this, we can make steps in the right direction.

What we really need is a way to write a digital "check" and digitally sign it.  Perhaps this can be done with the regular client, but the receiver simply can't know if the sender has modified his client to permit double spending this way, so we get back into the trusted third party issue.  A Mybitcoin.com variant that issues each user a unique ID number and matching keypair for the purpose of signing said checks, any online vender or individual receiving these checks could simply collect all of the checks that he has received over a period of time for the same bitcoin 'bank website' so that he can be paid in one bitcoin transaction.

If you want to design an alternate bitcoin, hey, go for it.  But what you're talking about isn't really bitcoin at that point.

The current system is designed to devolve into (a) Large Mining Conglomerates, and (b) lightweight clients that simply "sip" the necessary parts of the block chain.



Do you have any hard data that even remotely backs up these "too busy" claims?  One block header every 10 minutes remains fixed at ~80 bytes, regardless of 10 or 10,000,000 transactions per block.  Lightweight clients only need block headers and transaction data directly relevant to their wallets, as the system is currently designed.  Lightweight clients do not need to listen to, nor relay, all-network transactions and all-network completed blocks as do full nodes.



Define "DoS" proof, and then review how the current system works.  :)

People can DoS the tiny free TX area, and then they must start paying transaction fees.  That's the system working as designed.  TX fees make the system more expensive, as transaction rates increase, making DoS and spam more expensive, the more data sent.

The answer is to have a billion banks.... :D

What if opening a bank was as simple as installing a client?  ;)

It might become very easy when the bounty for an open source trading platform raises a respectable amount ;)

Yeah, but then you're back at 0, since you'd have to convince users that they can trust you.

I don't think it's worth worrying about core network load for a long time yet. BitCoin can easily scale up in the core. Let's do some back of the envelope maths to prove it.

VISA handles on average around 2000 transactions/sec, so call it a peak rate of 4000/sec. Let's take that as starting goal. Obviously if we want BitCoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand transactions/sec.

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

Receiving a transaction isn't that expensive, as software operations go. Basically the big cost is the crypto and block chain lookups involved with verifying the transaction. It'd be best to time Satoshis actual implementation, but as I can't be bothered doing that right now here's a best guess as to how expensive it is:

http://www.cryptopp.com/benchmarks.html

This claims that on a 1.8Ghz Core 2 Duo an ECDSA verification with the library BitCoin uses takes around 8msec. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds, clearly it's dwarfed by the cost of the ECDSA.

The bulk of the rest of the time in verifying a transaction today probably goes on disk IO, but in our hypothetical future the entire block chain would surely be stored in RAM (or flash). Reading from RAM or even flash is cheap.

Even if you assume a gigantic block chain, it's quite feasible to hold the whole thing in RAM. Consider that Google holds large parts of the web in RAM today if you don't believe me.

So the slowest part of verifying a transaction is verifying its inputs, which is probably 8-10 msec per input on todays hardware. It seems like in the current blockchain most transactions have only one input, and a few have more like 5/6 inputs. Let's call it an average of 2 inputs overall.

So this means a single core today can probably, with tuning and the block chain held in RAM but no special hardware beyond that, verify and accept about 50 transactions/sec. Writing data out over the network to peers is cheap and can be done largely by the NIC itself so that's not a concern.

If I'm in the right ballpark, it means a network node capable of keeping up with VISA would need roughly 80 cores + whatever is used for mining (done by separate machines/GPUs). Whilst building a single machine with 80 cores would be kind of a pain load balancing inbound "tx" messages over multiple machines would be very easy. Certainly a single machine could easily load balance all of VISAs transactions to a small group of verification machines which would then send the verified tx hash to the miners for incorporation into the merkle tree.

For receiving and handling all the "tx" messages, you could build a rack of 10 8-core machines that would keep up easily. And if hardware acceleration for ECDSA signature verification can be found/built, it's probably possible for only one (beefy) machine to do it!

That leaves the inbound inv messages. The cost of handling an inv is basically reading a small message from the network and then doing a RAM lookup to see if we already have the transaction. This is really, really fast. A single core could easily handle several thousand inv messages per second before breaking a sweat, even assuming it needs to read from a sharded in-memory block chain index.

The tl;dr summary is that with some adapted software, you could build a distributed BitCoin network node that could keep up with VISA with probably 2 or 3 racks of machines assuming the block chain and associated indexes are either kept in regular RAM or (more likely) flash storage. So not something a hobbyist is going to do, but quite feasible for a small company or organization today - not even taking into account the falling cost of computing over time. If BitCoin is ever as large as VISA there'll be plenty of people willing to run such rigs.

Well, done.  But I don't think the overhead of verifying transactions is what he was concerned about.  The bigger issue is the bandwidth required to echo every new block to every bitcoin client when transactions average 2000 per second.

I don't think that's a big concern either.

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but from looking at the block explorer it's probably averaging half a kilobyte today. So let's assume the way people use BitCoin gets more complicated and call it 1kb per transaction.

A solved block will then be around (1kb * 2000tps * 60 * 10) / 1024 / 1024 = 1.14 gigabytes per block.

But you only have to transmit a solved block to your connected peers. If we assume these big futuristic supernodes have something like 40 or 50 peered connections, that means in the worst case scenario where you solve a block OR you receive a block but none of your peers have it yet (unlikely), you have to send ~57 gigabytes of data (call it 60).

Shifting 60 gigabytes of data in, say, 60 seconds means an average rate of 1 gigabyte per second, or 8 gigabits per second.

The real question you want to know is how much does that sort of bandwidth cost? Well, bandwidth prices are a very tricky thing as some of the largest consumers pay the least due to how peering agreements work. The Googles and Akamais of this world will pay way less for a 10G wave than a small operator would. And, you wouldn't be hitting the 8Gbps very frequently .... only when you solve a block, really, as when relaying a block the peers you connect to will likely have already received it from some other peer anyway so only a subset would need to receive it from you.

But you can take a look at this random example of a colo provider to get a feel for it:

   http://icecolo.com/colocation-packages

If you wanted to run a distributed supernode that held the block chain in flash/ram etc, you'd probably buy an 11u quarter rack from them at 250 pound sterling a month, which also gets you 3T of data transfer per month beyond just power and cooling. So you could potentially do a full block broadcast 50 times per month. Certainly you could negotiate that up if you needed to.

It's very unlikely that a hypothetical VISA scale BitCoin network would have nodes which win a block every single day, at least, a healthy network would hopefully not have hash power concentrated so tightly into single miner nodes.

So basically with the technology of today running a BitCoin node capable of keeping up with VISA will not cost you an arm and a leg by any means, and if one day BitCoin is actually that big all the prices and numbers we've been discussing will have improved dramatically anyway.

Wow, nice analysis, it really makes me confident that we do have considerable room to grow. Being a distributed systems guy, I'm a bit concerned however about the waste of messages. As each transaction results in potentially O(n^2) messages (random broadcast) being sent around the network. Even if small that might result in quite a lot of traffic.

My point is that we could easily create a hypercube structure with forced node membership (hash the IP and join the hypercube vertex that uses the same prefix) where each transaction is sent to the nodes sharing the prefix of the transaction hash. Should the number of nodes in a vertex grow too high just make a longer prefix (add a dimension) and splits the vertex. Scales well, transactions are sent to specific storage points and the winner of a hash can collect all transactions he needs when reestablishing the network consistency.

Am I shooting completely over the target or is this a reasonable idea?

Note that the only thing broadcast for transactions and blocks is their hash.

Whenever a P2P node receives a new TX / block, they tell people "I have $HASH"

And only nodes without that $HASH will then request "give me tx or block with $HASH"

Thus, each node should ideally only receive the data once.

Not sure. A hypercube based network sounds interesting, but it's potentially a lot of complexity to solve a problem that might be easier solved with brute force. In particular it sounds like it could make the network more fragile and vulnerable to particular nodes falling offline - but I don't have a good understanding of the proposal so maybe I'm wrong.

Yep, that's the main downside, the complexity increases. We'd have to introduce a voting mechanism to collectively decide if a split should be done. Then we'd add selectively forwarding a broadcast to it's destination. and then a mechanism for the hash winner to collect the transactions he's going to sign.

Basically I think we can already modify the client, without touching the protocol, just switch a few inner workings. As for the fragility of the network, if we have about 50 nodes at each vertex that decide to split the vertex should they reach 100 nodes or join together when going below 25 nodes we'd have a really stable network.

Basically we can look at the current network as such a hypercube of dimension 0.

As for the size of the messages, yes I know they are small since only hashes are broadcast, but when comparing a 32 byte hash against a transaction of 100 byte, that's not really much of an improvement, but its pull based design is really nice, and might help keep transfers low, and first of all it helps keeping size deterministic.

Would someone please explain why sending solved block with raw TXs is needed? Isn't it possible to broadcast lighter version of solved block with only TX hashes (32 bytes each), bringing above number to ~32 megabytes (instead of a GB)?

It's not so much the block, but the collecting and verifying of the transactions. AFAIK only the merkle root will be in the block (source http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1#block).

I could of course be wrong since I'm only starting to implement the block verification now, and haven't dedicated much time to it yet. Please correct me if I'm wrong.

A lot of info on that page is wrong. The transactions are also sent in block messages.

I think you are probably right m0mchil. In theory that could be done and then nodes would request the transactions they did not see. Not worth doing today but a nice protocol improvement for the future.

Is there a convention on which the transactions are ordered in the block? That might allow users to selectively fetch branches in the from other in order to get the same result as the block generator. Simply check if we by chance have the same merkle root, if not ask for the two child hashes, repeat. That might actually get the size down a constant length, but would put strain on the clients in order to check which transactions are in a block.

Edit: might be time to split the thread in order to collect ideas for network improvements?

Is this useful? These guys at ISU use this software to check for bugs/races/code integrity/network integrity/etc.
It takes a snapshot of specific executions and hashes it, then compares it to previous ones. Any inconsistencies could be graphed and redflag DOSes prior to when they affect the network.