700 transactions/second now!

[Sergio_Demian_Lerner]

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.

[FreeMoney]

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

[nedbert9]

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.

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

[DeathAndTaxes]

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?

[Serith]

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

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

[Etlase2]

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.

[DeathAndTaxes]

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

Property Bitcoin MAVE-3
Maximum transactions per second (*1) 10 700
Average block confirmations per payment 6 at least 18
Underlying security ECDSA / SHA-2 truncated hash function
Fees in every message Yes No (*2)
Issue Payments during chain competition Yes No
Approximate client cost per month(*3) 13 USD 13 USD
*1 For an average home PC, using no more than 15% of CPU and 50% of
bandwidth, and replacing the hard drive not before 2 years.
*2 POW or similar defense required for some messages
*3 As of 2011, electricity, bandwidth and PC amortization costs in the U.S.
considered.

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. 

[Etlase2]

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.

[Sergio_Demian_Lerner]

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.

[Sergio_Demian_Lerner]

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.

[Realpra]

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.

[Sergio_Demian_Lerner]

How can there be no transactions during chain competition?

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.

[apetersson]

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?

[Technomage]

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.

[Sergio_Demian_Lerner]

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.

[Sergio_Demian_Lerner]

i wonder, is there already a working prototype out there as open source for testing?

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.

[wogaut]

Very interesting.

Subscribed!

I'd love to see an implementation of it.

[DeathAndTaxes]

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.

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

[DeathAndTaxes]

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.

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.

[finway]

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.

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 ?