Bitcoin Forum

How?

Check out the papers

http://bitslog.wordpress.com/2012/04/16/mavepay-a-new-lightweight-payment-scheme-for-peer-to-peer-currency-networks/

and

http://bitslog.wordpress.com/2012/04/09/mave-digital-signature-protocol-for-massive-bulk-verifications/

Buy the new MAVEPAY P2P currency at a discount and be the first to own some mavecoins ! (this is a joke)

Disclaimer: I did it.
Apologies: I created a new thread because last thread title wasn't helping spread the curiosity. ::)

Best regards,
 Sergio.

You can edit thread titles, you don't need to make new.

Very interesting work.  700/s is nothing to sneeze at.

How do you reach the conclusion that a Bitcoin node is limited to 10 tps?

Modern (i series) CPU can process >80 tps per core and the bandwidth requirements for 80 tps is negligible.

To put it into perspective:
current:  0.1 tps
Paypal: ~50 tps (~$80 billion annually)
15% CPU load on quad core system: ~50 tps

I see from paper you put artificial limit on 50% of user's bandwidth and 15% of CPU power.  Those would be worst case scenario for Bitcoin and best case scenario for a cpu lite, bandwidth intensive system right?

Still even w/ "limit" of 15% CPU usage I don't see where you get 10 tps.  Is this a Single core ATOM processor?

I believe by manipulating numbers for the purpose of self promotion. 

I believe he is trying to compare apples to apples. If bitcoin were limited to 10 tps, what could mavepay do with the same cpu/bandwidth requirements. Though I don't think he did the greatest job of explaining that.

Well he is assumming 15% CPU and 50% bandwidth of "average computer user".


I just think that
a) limiting Bitcoin to 15% CPU usage and allowing MWAVE to use 50% of user's bandwidth is disingenuous.  Even at 100 tps Bitcoin only requires ~ 100 kbps.  I don't know how many users are willing to give up 50% of their bandwidth 24/7 forever especially in light of ISP bandwidth caps, throttling, and overage charges.

b) even if we assume the 15% CPU and 50% bandwidth limits are realistic I have no idea what CPU would be only able to validate 65 transactions per second.

c) computational power has (and likely will continue) to grow at a faster rate than bandwidth AT THE LAST MILE. 

mwave is still using less bandwidth than bitcoin on a per-transaction basis so I don't see how that's disingenuous. Bitcoin is horribly inefficient with its bandwidth.

http://www.hindawi.com/journals/ijrc/2011/836460/

I don't know how to get ebats to give ms but this guy wrote that a core 2 duo 1.4ghz (is that highly oudated? I don't keep up with hardware) can verify in 2.2ms which is 455/s * 15% = 68/s.
off by a bit but not an order of magnitude.

Thank all for the comments.

Really I didn't tried to measure myself Bitcoin speed, because that would mean to establish a reference computer for all tests which I cannot do (I didn't implement MAVEPAY and I try to analyze its theoretical capabilities).

As stated in the paper, I used Crypto++ benchmarks (http://www.cryptopp.com/benchmarks.html).

Maybe Crypto++ implementation of ECDSA is slow (is takes 8.53 msec to do a ECDSA256 verification) on a AMD Opteron 8354 2.2 GHz.
But anyway, as DeathAndTaxes pointed out, I'm using the same benchmarks to estimate MAVEPAY performance.

I've also assumed a very slow Internet connection (1 Mbps), but that is the average Internet bandwidth in the U.S., as of 2011.

How many transactions can Bitcoin validate per second in my a Intel CORE2 CPU 4300 @ 1.80 Ghz ?
Has someone posted statistics? Maybe Gavin can release a simple benchmark application so we can make a poll.

Keep in mind that transactions are verified twice in Bitcoin, and the average inputs per transaction is around 2. So that makes 4x decrease in performance. (which puts Etlase2  68 verfications/second  down to 17 transactions/second )

MAVEPAY has none of  those problems since: It requires 3 hash evaluations per payment, transactions are verified once, transactions cannot have more than 1 input (this artificial restriction favors scalability and penalizes anonymity)

Sergio.

I checked the code that computes maximum Bitcoin transaction/second.

I found that the limiting factor was NOT CPU, but hard disk space. In requires the HD to be replaced every 1.7 years because it fills up with the block chain. (I assumed that disks should not have to be replaced before the 4.5 average computer lifetime).

Obviously, the Markle tree magic can decrease the space requirements, but I'm comparing Bitcoin as it is today, and MAVEPAY as it can be with a few hundreds lines of code. The paper clear states that I'm not considering possible Bitcoin improvements (there are so many!)

Sergio.

Going from 10 to 700 transactions for the computing power seems really good.
Something like this COULD be bitcoins undoing, it could also be irrelevant if BTC are already cheap enough - it would be like arguing your email client had better graphics or ran faster: irrelevant.

Still nice work though.


How can there be no transactions during chain competition?

Isn't the whole point that the chain competition is constant?


Proof of work for txs and such might be a good idea.

The fee system of BTC should work nicely enough though.


Will keep half an eye on this.

In MAVEPAY you should never submit the last command of a transaction (which commits the transaction) if there are two competing block chains that are 12 or more block long. That's is just unreal, since I find almost impossible that such competition arises if the network is not disjoint. So you can just forget that comment on the paper, as I does not imply any real limitation but only a warning:

 "Keep an eye on chain competitions. If they are too long, then probably the network was split for some time. Do not finish your transactions. Wait until one of the chains is 6 blocks longer than the other. "

Also, If you reduce the block interval from 10 minutes to 30 seconds (which could be possible, depending on the network diameter and propagation time) then a competition of certain length may occur from time to time.


Sergio.

there are many interesting ideas in this new protocol. currently reading it.
i wonder, is there already a working prototype out there as open source for testing?

One has to take into account that if Bitcoin continues to grow and become more mainstream, it's likely that at least 90%, possibly even close to 99% of Bitcoin clients will be lite nodes. Meaning that they are either client-server wallet solutions (such as Electrum) or E-wallets such as Blockchain.info. Therefore calculating how much it takes for a basic CPU to verify transactions etc is irrelevant. That stuff will be in the hands of non-average server hardware, which is much more capable than your average PC.

As long as anyone can run a server that helps verify transactions (Electrum is a nice example of this) and the hardware requirements aren't something that is entirely beyond regular people, I think this is completely fine. It's very much needed actually, the speed of Bitcoin as a full node will not be competitive with other payment methods otherwise. The clients themselves don't really need to hold anything other than the private keys. Of course there should always be a choice for people to run Bitcoin as a full node and there will be. That's why this is called voluntary centralization.

Technomage is completely right. Nobody should care if you and me can run a full node. Soon Bitcoin will be completely centralized, as banks. Nobody will be able to run a full node. Then banks will start changing the rules. Also, computers are disappearing, people will only use smartphones...
Then why are we doing all this?
Let´s just stop using Bitcoin and keep using USD or Argentinian Pesos. Or better, let´s use Google Wallet, whose app is really a thin client.

Why did I spend some many nights writing such a paper? I should have been playing tennis with a banker.  :)

Best regards,
 Sergio.

There is no prototype. (I programmed it in my mind).
You can easily take BitcoinJ, change the port, and add basic MAVEPAY functionality. I bet it can be programmed in no more than 300 lines of code.

If anyone is interested in programing it, I will help.

Very interesting.

Subscribed!

I'd love to see an implementation of it.

The world is full of gray and you are making ridiculous claims based on black or white.

Gold mining for example is decentralized.  No single entity controls more than ~10% of world's proven reserves (as in metal still in the ground) however it isn't decentralized to the point that every single person on the planet mines gold.  99.9% of people who want some Gold simply buy it.  The market is still decentralized though.

Central bank = absolute centralization.  A single unelected board of 12 sets monetary policy for 300 million people.  If Bitcoin full nodes consist of 1000 or so entities it is less decentralized than if every single person always ran a full node however it is many magnitudes more decentralized than a central bank.

Today a large number of users CHOOSE to not run a node and instead use 3rd parties.  That is when the requirements of running a node are trivial.  I don't see a problem in that because the "market" for 3rd party wallets is DECENTRALIZED and OPEN (there are no licensing restrictions to create barriers to entry and keep the number of players artificially low).

On a long enough timeline that may be true but I think we have some room to grow.  The trend in CPU has been the inclusion of GPU functionality.  Currently (w/ avg tps being <0.1) there has been little need to improve tx processing performance.   


One potentially untapped area is OpenCL & AMD APU series of chips.  APUs have a decent OpenCL capable "GPU" right on the chip.  They are targeted for lower end systems.  In SHA-256 hashing they acheive roughly 5x the throughput compared to high end quad core conventional CPU.  Like I said it is early as there is no need yet but if the same multiple holds true we are talking about hundreds of tps (given an OpenCL "aware" client).

Long before Bitcoin hits mainstream even low end computers will have access to relatively powerful OpenCL hardware in either their "on chip" GPU or low end discrete graphics card.  CPU/GPU power shouldn't be an issue for a long long time.

You should make a chain and let people breaking it .
MAVE , like ECDSA, needs to prove itself.
After 10 years, if it works, Bitcoin should switch to it.

Btw, is it opensource & free ?

You won't get too far insulting the protocol that is too holy around here. ;)

If you're interested in something different, this is the latest thread on encoin: https://bitcointalk.org/index.php?topic=76750.0

I was actually looking into one-time signatures (or the hash tree based ones that have many but limited sigs) as well as NTRUsign/encrypt to obtain a QC-proof protocol. It appears that you have designed something that is fast and has both small public keys and signatures, a combination of which is not really possible with hash tree sigs and NTRU. I'm not a cryptographer though so it is hard for me to grasp everything just based on a whitepaper.


tps is not bottlenecked by hashing, it is bottlenecked by ECDSA. They operate very differently and openCL/APUs will not help this.


ECDSA doesn't need to prove itself, it needs to stay resistant to cryptanalysis finding a direct vulnerability. Bitcoin won't do anything to change the odds of this happening as it is a tiny, tiny percentage of ECDSA use at large.
In the same vein, MAVE is simply using one-way hashing functions, so any vulnerability in MAVE would be either based on the fact that it uses truncated hashes, or a vulnerability in SHA2 itself. I'm not a cryptographer, but they should be able to figure out whether or not MAVE is vulnerable because of truncated hashes just based on the whitepaper. SHA2 is in the same boat as ECDSA.

> 700 transactions/second now!...

Bitcoin is one of the most powerful supercomputer on Earth... Why it can not handle >1000 transacions/second?!!

This is an excellent point.  Bitcoin is modular, so if Mave proves itself to be as robust as it's inventor might like to believe, bitcoin will just assimulate it into itself.  The fact that Bitcoin & Stratum actually exist, and Mave is vaporware, is a secondary point.  Bitcoin has the market advantage and the capacity to evolve using new tech, Mave will never make it out of the cradle before it's best innovations are replicated by Bitcoin or some overlay such as Stratum.

Because all that power is only used on hashing and not on transaction processing...
You should know that by now dude...
But this goes to show how much miners know about what they do with their GPUs lol

This one deserved a triple facepalm...

how is bitcoin modular exactly? besides the fact that you can hack on an altchain rather easily.

according to the wiki, it links this post: https://bitcointalk.org/index.php?topic=191.msg1585#msg1585

where satoshi basically says "yeah we'll just fork it if something goes bad"

Stratum cannot implement mave as mave would have to be secured in some way

So the likely best option is to make an altchain that implements mave and uses bitcoin as its coin via inter-chain transactions.

And now I need four hands to properly complete this one.  Hashing is transaction processing.  The OP's complaint is that a network node must verify each transaction (and blocks, including the transactions within) before relaying them or adding the new block to it's local chain; yet the current algo that bitcoin uses for this action is particularly slow, so there might be a limit to how fast the average computer can process the flow of the network (there is) before the network as a whole begins to choke on the delays of thousands of computers that fail to keep up with the flow.  This isn't an new observation, as the demands on bandwidth & cpu time are predictable with growth.  That is exactly why light clients are named in the whitepaper from 2008 and why clients that do not require or keep a complete local blockchain (Electrum, Stratum, BitcoinSpinner, etc.) exist now and will continue to exist.  As has been mentioned, there is no reason to expect the casual end user/consumer to need to run a full client.  There is every reason to expect that running a full client (or a Stratum server) is going to be a specialized commercial service for hundreds or thousands of individual users

There are 'hooks' in the code that are intended for future algos to be added to the existing process, or be replaced by them, by consent of the network.  The larger the network grows, the less likely this is going to happen for trivial issues, but if someone 'breaks' ECDSA then the network would have to migrate to another cryptographic signing algo.  There is a known path for this; in fact, it's expected from the start that bitcoin will not always use the same algos.  For example, bitcoin currently uses SHA256 in hashing the block, but it uses it twice.  At some point, another hashing algo will be added in place of the second SHA256; thus reducing the bitcoin network's dependency upon this single algo.  In such manner, even the complete breakdown of SHA256 wouldn't compromise the security of the blockchain; for both types of hashing algo would have to be broken at the same time in order to compromise the blockchain security model.  Right now, there isn't an alternative hashing algo to compete with SHA256, but several are being developed and tested presently.  Once one of those comes out one top, whichever is considered best by the network (and is different enough from SHA256 that they won't likely share a fatal flaw) will likely be added to the code by the developers.  The vote on the matter then comes down to whether or not users choose to upgrade, or stick with what they have, or simply choose a forked client to upgrade to (written by a developer who prefers a different algo that the other developers rejected, and decided to take his ball and start another team).  Your participation (or lack thereof) is your vote.  Whichever outcome results in the greatest hashing power overall overtakes the rest of the network and becomes the defacto standard.

Moonshadow, there are a dozen or so other algorithms that compete with SHA2. SHA2 is just the US government sponsored algorithm.

Your "known path" argument is bunk. Any change to the double SHA2 hash breaks bitcoin. Every client would have to upgrade. Whichever chain gets bigger is irrelevant. Clients will not accept an apparently invalid chain just because it's longer.

Now I'm not saying that this is an impossible process, but it is certainly not modular.

Well, MoonShadow, that would be true if EVERY GPU/CPU/FPGA/ASIC that's mining had a bitcoin node connected to the network, which ISN'T the case, given that most of them are connected to a CENTRAL node called a minning pool ::)

Network total hashing power can increase infinitely without increasing maximum tps capacity.

Also, you lack reading skills as I was pointing the flaw on ThiagoCMC's statement and wasn't talking about the OP.

But given that you are so smart why don't you answer to ThiagoCMC?

Oh, that's right... transaction processing is limited by every single node capacity and not by total network power...
Too bad all the power of the "most powerful supercomputer on Earth" only goes to bruteforce the solution to a problem while being useless to process transactions... ::)

Do I need another set of hands now?

There is no chance that you will be able to convince a significant mass of bitcoin adherents that your idea is necessary or should be implemented. Theoretically useful is the best you can hope for. This is not a criticism of your idea itself, but a comment on the community's attitude towards ideas which can be perceived as threatening bitcoin.

I'd recommend bundling MAVE with other significant improvements and releasing it as a new blockchain. If you introduce a bunch of different things at once (and they are beneficial), it will be well-nigh impossible for bitcoin to ever overcome inertia and infighting in order to implement them. If you don't add enough new stuff to attract major interest, then MAVE will probably never gain traction even if it is a superior protocol.

There is a significant problem of the new blockchain gaining traction. Like the proof-of-stake improvement, increased txn processing efficiency is not immediately needed, so there is no strong reason to switch now. You will need to bundle the new blockchain with features that offer immediate benefit and facilitate non-speculative adoption. I have ideas for this, but they don't belong in this thread.

I think that claiming Bitcoin-enthusiasts are disliking MAVE because it threatens Bitcoin is an incorrect assumption. I would be quite fine with switching to another cryptocurrency if it proved truly superior (taking into account the network-effects as well) to Bitcoin. However, I wouldn't dismiss the possibility that Bitcoin makes significant changes to itself once they become really necessary. For example, the multisig implementation BIP16 was far from critical to Bitcoin and it still went through, with some pain but it was enabled nonetheless. If we ever need something critical to go through, I have faith that it can be done.

With this particular "problem" I honestly feel that it might not need fixing, not now and not ever. First of all full nodes are a clear usability problem for Bitcoin and should not be in use by anyone else than geek libertarians and corporate interests. The problem here is more with the size of the blockchain and the time it takes to download and verify the chain. Even now, when tx/s is fairly low, it's very significantly slower than using a lite client. I can't see how MAVE would do anything other than make this a little easier and delay the problem. It's not a critical fix.

As D&T well explained, it will take a long time before tx/s reaches amounts where basic CPU's are unable to do it fast enough. Here it's important to understand that the capability of a basic CPU doubles every 18 months (still valid, afaik). So it will take time. Eventually running full nodes will centralize to the point where it's run only by powerful home computers and server hardware. As D&T already said, this doesn't make Bitcoin centralized, it will still be decentralized. Not as decentralized, but still very decentralized. As long as it's not completely out of reach for a regular person to run the full node, there is no problem whatsoever. From a usability standpoint people should use thin clients more already, so I don't get the point.

I will probably always be running a full node somewhere, simply because I'm a slightly geeky libertarian type of person. Right now I even use full node clients when I need to send bitcoins. I have a couple of thin wallets as well but I haven't used them as much. But I qualify myself as a power user, I don't recommend anyone to ever download a full node client when I talk to them about Bitcoin. That's the last thing anyone in their right mind wants to be doing, unless they are geeky types like me, in which case I might recommend a full node client.

People need to get their heads out of their asses and realize that most people don't, and will not, care if they run a full node client or a thin client. They care how fast and easy to use it is. Geeky and/or libertarian types might care about this and with Bitcoin they will have the freedom to use a full node client and there is no foreseeable future where they could not do that. I believe there are enough users out there, just like me, who would want to run a full node as well. That's why I think that Bitcoin will be very decentralized even if none of the regular Joe's are ever running a full node.

I would like to add that I have nothing against MAVE and I think that it's fairly interesting. It just happens to target one of those issues that are in my opinion very minor. Even I admit that Bitcoin has bigger issues than this one (although even those are long term problems). MAVE is something that clearly belongs to a competitive cryptocurrency but cunicula said it best, that currency better have other significant benefits over Bitcoin if it wants to be truly competitive. This alone will not attract a lot of people. Bitcoin's network effect should not be underrated, it might be a niche technology but compared to other cryptocurrencies it is gigantic.

So you have already written a ECDSA Kernel for OpenCL and can confirm that unlike virtually all other cryptgraphic functions it is impossible to accelerate ECDSA?  What was the throughput you saw in terms of ECDSA verifications per second? Care to share your findings on what makes ECDSA acceleration infeasible?

Still I did say IF the same multiple holds true.  If it doesn't then Moore's law will still provide some help.  The OP "benchmark" is bullshit.  Today bitcoin tx processing is on the order of 300+ tps for a modern CPU (quad core @100% load).  If we limit to 20% load that is "only" 60 tps.  60 tps is 600x larger than the current network and roughly Paypal sized.  If it takes us a decade to grow to Paypal scale network the average computer will have roughly 30x as much computing power per watt.  Even without OpenCL the "tx bottleneck" (600x current tx volume) becomes less of an non-issue.


However you are an expert OpenCL kernel developer with extensive research on the limitations of OpenCL for acceleration cryptographic functions?

Using MAVEPAY, would it be possible to add multi signature payments where two or more parties, not knowing each other's keys, must sign a transaction for it to be valid? I'm not sure how that would be done with the type of one time signature you're proposing, yet one of Bitcoin's major innovations is the potential for network- enforced contracts that require multisig.

You know, I have tried to be civil. But when somebody is insulting in the face of their own stupidity, it gets harder and harder.

Logic breakdown:

A) SHA-256 hashing is capable of being highly parallelized
B) It is unknown* whether or not ECDSA is capable of being highly parallelized
C) SHA-256 and ECDSA have the fact that they are forms of cryptography in common but are otherwise unrelated
D) Therefore, ECDSA is capable of being highly parallelized
*) It is probably well-known among people who are proficient in this sort of thing. And additionally, as ECDSA is a far more intensive process than a one-way hash function, it is highly likely that businesses with significant use of digital signature algorithms would have investigated this. You know, since it's kinda the whole point of CUDA and OpenCL.

BZZt. WRONG. FAIL. EPIC FAIL. DO NOT PASS GO. DO NOT COLLECT $200. GO DIRECTLY TO THE JAIL OF PISS POOR LOGIC.

You made a gross leap in logic and used that to draw a conclusion based on no evidence of any kind. Then threw insult after insult at me for pointing out this logical fallacy.

PS BRO-


I elected not to point out the gross error in your logic of 100 tps being 100 kbps. This, unfortunately, only holds true if you have 1 incoming connection and 0 outgoing connections. If this were the case for the network, there would be no network. There is the reason the wiki comes up with 8Gbit/s for 4,000 tps instead of 4Mbit/s.

Bandwidth, imo, has always been the greater bottleneck of the bitcoin system. You are correct to point out bandwidth caps and throttling and that computational power is likely to grow faster than bandwidth. Even if it isn't, you can always build "up" with more processors or computers, whereas you cannot just lay down an extra pipe of fiber to your house.

Actually I said IF the same performance increase is possible while you said definitely that OpenCl won't help ECDSA acceleration.

The reality is ECDSA acceleration already exists.

https://raw.github.com/samr7/vanitygen/master/calc_addrs.cl

Vanitygen acceleration ECC public/private keypair generation.  There is nothing to indicate that verification couldn't also be accelerated.

Also of course ECDSA can be parallelized.  SHA-256 doesn't have intra hash parellization it uses macro-processes parallelization.

Simply put it doesn't try to make processing a single hash faster it processes multiple hashes at the same time.

Likewise since each ECDSA signature is independent one can process multiple signatures at the same time without needing to speed up the intra-hash process.

Now Vantitygen is a "bad" benchmark because it performs multiple tasks:
ECC public/private keypair generation
RIPEMD-160 hashing
SHA-256 hashing
Pattern matching

However computationally the ECC keypair generation takes much longer than the other three tasks combined. 

I will modify the vanitygen kernel to just perform ECC keypair generation since obviously nothing short of a definitive benchmark will make you realize that OpenCL acceleration is at least POSSIBLE.  Nobody has looked into it simply because for Bitcoin that "bottleneck" won't be hit for likely a decade.

BTW ECC accelerations exist in the business world too.

Good point totally blanked on that. 

The wiki assumes tx size will increase from ~500 bytes to 1000 bytes due to more complex tx but that is no longer a valid assumption due to p2sh.
It does show why p2sh was such an important change.  Very long multi-sig addresses would only make the problem worse.  p2sh neatly bypasses the entire expanding address size issue by decoupling the complexity of the script from the address size.

Compressed keys can reduce the address size by ~50% however implementing them in the protocol would be a breaking change so currently they are only used locally and decompressed to full length keys for broadcasting.

So:
50 tps * (500 bytes - avg 2 input tx) * (20 peers) * 8 bits/byte ~=  4 Mbps.

If we consider Paypal sized network an achievable medium term goal (over next decade) we are talking about a full node needing ~ 4Mbps.  Using less peers (which should be fine for non-merchant nodes) would require roughly half that.

The good news is that bandwidth outside last mile is much cheaper so even if one reached a point they couldn't host their own node but didn't want to use a 3rd party wallet they could put an node like electrum on a VPS and then connect their local lite clients to their dedicated trusted node.

here you go: http://www.emsec.rub.de/media/crypto/attachments/files/2010/04/da_szerwinski.pdf

point multiplication on the NIST P224 curve for 8800GTS: 1412.6/s
point multiplication on an intel Pentium II 400MHz: 950.6/s

better watch out for those 10 year old processors, they might one day rule the world

Without joking, I admit that Bitcoin does not require MAVEPAY now and Technomage is completely right.

And the fact that I posted the paper in Bitcoin forum proves that I do not want to make another block chain. I'd like to point out that Bitcoin can grow stronger, whenever it needs to.

I'm telling Bitcoin users: don't worry about scalability, when time comes, the we can switch to this protocol.

BUT still some ideas keep spinning in my mind...

What if Bitcoin is not growing fast enough as it could?

What if Bitcoin could grow 100X in a year if used as de-facto online coin for trading in virtual worlds?

What if peer-to-peer poker could be played on the Internet without e-casinos, and each bet is made with a Bitcoin transaction?

What if we are in the edge of a disruption?

Everybody says, we are at 0.1 tps, and Bitcoin community do not need more. This "Community" could grow from 50K users to 5M users in a few months if suddenly one of the things I say becomes real.

The future, is unknown.

It is much easier, since in MAVEPAY there are "accounts", you just create an account with two key-chains.

Every enhancement will be much easier for a scheme with user/group accounts, than with transactions only.

Yes, I now need a fifth hand.  Go back and actually read what I wrote before typing something else.  I specificly noted that we were talking about (and likely confusing) two differnet subjects.  I know full well that tps bottlenecks are related to network latency and not hashing of blocks.  I stated as much, if you had bothered to read it.  You have a right to your opinion, and a right to be wrong, but continue to be an ass and I may just choose to exercise my privilages.