700 transactions/second now!

[Etlase2]

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

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.

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

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

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 ?

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.

[ThiagoCMC]

> 700 transactions/second now!...

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

[MoonShadow]

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.

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.

[Raoul Duke]

> 700 transactions/second now!...

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

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

[Etlase2]

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.

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.

[MoonShadow]

> 700 transactions/second now!...

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

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

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

[MoonShadow]

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.

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

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.

[Etlase2]

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.

[Raoul Duke]

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?

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

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?

[cunicula]

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.

[Technomage]

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.

[Technomage]

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.

[DeathAndTaxes]

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

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

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.

I'm not a cryptographer

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

[blueadept]

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.

[Etlase2]

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

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.

[DeathAndTaxes]

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.

... nonsense snipped ...

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.

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.

[DeathAndTaxes]

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.

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.

[Etlase2]

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

[Sergio_Demian_Lerner]

I think that claiming Bitcoin-enthusiasts are disliking MAVE because it threatens Bitcoin is an incorrect assumption.

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.

[Sergio_Demian_Lerner]

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.

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.