Topic: 700 transactions/second now! - page 2. (Read 3525 times)

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://bitcointalksearch.org/topic/encoin-scrutiny-76750

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.

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 ?

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.

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

Very interesting.

Subscribed!

I'd love to see an implementation of it.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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. 

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.

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

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?

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

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