Blockchain-less P2P Currency (theoretical idea)

[bitfreak!]

...the data required to keep track of the network should always remain at manageable levels.

1) you can track only unspent outputs.
OR
 2) you can simply don't track transactions.
OR
 3)

1 and 2 are not going to help us very much overall.

3) Design a system like what I have described here.

[bitfreak!]

What do you think : how much transactions
per second your system can reliably handle
 permanently ?
This is an important bottleneck for
 scalable money-transmitting system.

Since transactions would be solved in blocks like bitcoin it would be limited to the max block size and how fast those blocks were generated. For bitcoin it's one block every 10 minutes and each block can hold a max of 1MB if I'm not mistaken. Although this can be increased with a planned hardfork.

My system would probably be able to process blocks much faster than every 10 minutes and since we don't need to be worried about an ever increasing blockchain we don't really need to worry about putting a small cap on the block size, it could be much larger than 1MB and not cause problems.

edit: however we still need to keep the mini-blockchain at a reasonably small size so the max block size couldn't be too big, maybe 10MB or something. The max size of the blocks would obviously depend on how fast the blocks were processed and how long the mini-blockchain was.

[bitfreak!]

what matters is the MAXIMAL number
 of txes, which system can handle
 w/o hassles PER second.

As I just explained... the transactions are processed in groups periodically like bitcoin, thus the maximum number of transactions per second is determined by the max block size and the rate at which blocks are solved. At the very least this system is capable of handling more transactions per second than bitcoin without problems.

[Come-from-Beyond]

What do you think : how much transactions
per second your system can reliably handle
 permanently ?

I think as many as necessary. Every mini-blockchain could be used to handle only a subset of accounts. Nothing prohibits us to build 1000 mini-blockchains simultaneously. It's called merged-mining.  Of course, we need crosschain transactions in this case.

[bitfreak!]

What do you think : how much transactions
per second your system can reliably handle
 permanently ?

I think as many as necessary. Every mini-blockchain could be used to handle only a subset of accounts. Nothing prohibits us to build 1000 mini-blockchains simultaneously. It's called merged-mining.  Of course, we need crosschain transactions in this case.

I don't know if this has the potential to work but it would add another layer of complexity which we don't necessarily need. I think a single mini-blockchain would work well enough and save us the trouble of dealing with multiple mini-blockchains.

[bitfreak!]

Let's assume we have 10 billions of humans.

Let every human (on  average) earn/spend 20$
 per every day. <-- cuz we must fight with poverty on the world-wide scale.

Assume that average transaction in the system is 0.5$

So, we have 40 tx/day per person.
-----------
After simple calculations :
we must handle ~ 4 629 630 tx/sec total.
And this is w/o any reliability margin.
-----------
How much mini-blockchains do we need ?

What you're saying applies to bitcoin too. I don't think we are designing these systems to handle every single transaction ever, but we need to get as close as we can. Bitcoin can still handle a fair amount of transactions per second as it is, but my system would be marginally quicker even with one mini-blockchain. Having multiple mini-blockchains defeats the purpose of having a mini-blockchain in the first place.

[Come-from-Beyond]

I don't know if this has the potential to work but it would add another layer of complexity which we don't necessarily need. I think a single mini-blockchain would work well enough and save us the trouble of dealing with multiple mini-blockchains.

A single mini-blockchain can't solve the scalability issue. Look at http://en.wikipedia.org/wiki/CAP_theorem. U can't have Consistency, Availability and Partition tolerance at the same time, that's why u have to impose some restrictions, like separation of data using multi-mini-blockchain approach.

[Come-from-Beyond]

If your system will be unable to handle
 5 mil. tx/sec ,
we here at CIA will destroy it (cuz we can).
Think twice about it. )

This makes no sense. Why does CIA need to destroy a geek toy that can handle only 7 tx/sec? But CIA does need to destroy a system that can handle 5000000 tx/sec to avoid the collapse of USD.

[bitfreak!]

Why the hell would it need to handle 5 mill transactions per second? According to the bitcoin wiki PayPal only need to handle a max of 100 per second. VISA has an average of 2000 tps with a capacity for over 10,000 tps for their busiest times. I think matching PayPal would be enough honestly. This is only a rough guess based on some rough calculations, but my system may be capable of handling 50 tps or maybe close to 100 tps if we're lucky.

[Come-from-Beyond]

Why the hell would it need to handle 5 mill transactions per second? According to the bitcoin wiki PayPal only need to handle a max of 100 per second. VISA has an average of 2000 tps with a capacity for over 10,000 tps for their busiest times. I think matching PayPal would be enough honestly. This is only a rough guess based on some rough calculations, but my system may be capable of handling 50 tps or maybe close to 100 tps if we're lucky.

Aren't u currency supposed to replace all payment? For 7 billion ppl making 1 transaction a day it's almost 100.000 tx/sec.

[bitfreak!]

Why the hell would it need to handle 5 mill transactions per second? According to the bitcoin wiki PayPal only need to handle a max of 100 per second. VISA has an average of 2000 tps with a capacity for over 10,000 tps for their busiest times. I think matching PayPal would be enough honestly. This is only a rough guess based on some rough calculations, but my system may be capable of handling 50 tps or maybe close to 100 tps if we're lucky.

Aren't u currency supposed to replace all payment? For 7 billion ppl making 1 transaction a day it's almost 100.000 tx/sec.

Why would it be supposed to replace all payment? It's supposed to capable of handling what it'll need to handle. There are always going to be other money systems, centralized and decentralized. It seems to me like the most obvious solution if we need to handle these ridiculously high transaction levels, is to simply have multiple clones operating. I'm sure all these alt coins help take a lot of pressure off bitcoin as it is. We don't exactly need to have one SuperCoin when we can have a bunch of different virtual currencies which together help facilitate the total transaction demand.

[Come-from-Beyond]

Why would it be supposed to replace all payment? It's supposed to capable of handling what it'll need to handle.

OK. I thought you were developing a universal currency.

[bitfreak!]

Why would it be supposed to replace all payment? It's supposed to capable of handling what it'll need to handle.

OK. I thought you were developing a universal currency.

As I stated in the opening post, the main goal is to simply solve the problem of an ever-increasing blockchain. The capacity for transactions faster than bitcoin is just a side-effect of the system I have proposed, it wasn't designed on the basis it should be faster than bitcoin. It was designed on the basis of long term viability.

[bitfreak!]

Again, if you can not handle ALL cash
 transactions in the world within your system, why waste your time ?
There will be better system built by someone else, and yours'll quickly become outdated.

Ask PayPal why they waste their time if they don't handle every single transaction in the world... I for one would like to see someone design a system capable of handling every single transaction in the world, especially a decentralized one.

[bitfreak!]

Ok I've been thinking about the specifications of the mini-blockchain some more and I think the main thing which we need to determine is how many blocks will be in the chain and how often blocks are solved. It seems to me we need to have a mini-blockchain which is at least 20 to 30 days long to provide enough security, but I'm not exactly sure. Assuming we go with 30 days, we could make it so 1 block was solved each minute and each block could hold 1MB. So the maximum amount of transaction data which could be transmitted in an hour would be 60MB. Assuming every single block on the mini-blockchain was maxed out for 30 days in a row, the size would be about 42GB. Although I assume this can be compressed down to an even smaller size, the bitcoin blockchain seems to be compressed in some way.

So even with the mini-blockchain maxed out the size should never grow beyond 30 or 40 GB. Typically it would be much much smaller, but to handle a large amount of transaction traffic the mini-blockchain still needs to be able to grow to a substantial size even if limited to a period of 30 days. And even using blocks with a 1MB capacity which are solved every single minute we still don't have a transaction capacity anywhere near as high as the maximum transaction capacity of VISA. It would be either 34 tps or 68 tps using those specifications. I'm not exactly sure because the wiki says bitcoin can handle 7 tps but for that to be possible the max block size should be 2MB (not 1MB) if they are solved every 10 minutes, according to my calculations... so I might be missing something.

Another thought: perhaps the max block size could be dynamic, based on the size of the blocks before it. If the average size of the previous blocks is less than 1MB, the next block to be inserted may have a max size larger than 1MB, where the increase will correspond to the average size of the previous blocks, such that the average block size would never increase beyond 1MB even with these extra large blocks. This would help provide more room for large transaction bursts by making use of the unused space from previous blocks in the mini-blockchain.

[bitfreak!]

The speed of the ECC algorithm is not the issue here, the secp256k1 algorithm is capable of processing many thousands of signatures per second. It's really the size of the blocks which hold us back... the sheer amount of data which needs to be saved into the blockchain when we are talking about several thousand transactions per second is huge, and I see no realistic way it could be managed in a decentralized way, even if the blockchain was cut down to 30 days of history.

At very high transaction rates each block can be over half a gigabyte in size.
Bitcoin Scalability

[Come-from-Beyond]

1) Use another elliptic curve
curve25519 (for faster tx processing)

Can it be used for signing?

2) Use not ECC, but some sort of
 hash-based digital signatures.

Their signatures are very long, like a couple of KiB.

3) Use something else ( with very fast verification time ).

Ed25519 seems to be the best short-n-fast signing combo.

[aaaxn]

I had been thinking about similar idea independently and think it's possible. See here:
https://bitcointalk.org/index.php?topic=169311.msg1976355#msg1976355