Topic: 700 transactions/second now! (Read 3525 times)

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.

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

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

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://bitcointalksearch.org/topic/m.1585

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.

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...

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.

> 700 transactions/second now!...

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