Topic: Blockchain-less P2P Currency (theoretical idea) (Read 3065 times)

Mea culpa !
Of course, for signing one want to use Ed25519.

But curve25519 could be used too in cryptocoin system for various purposes:

http://cr.yp.to/ecdh.html

----------
if OP is interesting about Ed25519:
http://cryptojedi.org/peter/data/nancy-20120320.pdf

2) There are options )
Also hash-based sigs are postquantum.
But ECC will suffer from QC.

3) yes, maybe the best option for now.
 Though it offers only ~ 128 bits of security.
There are similar EdDSA curves (more secure), but there are no ready libraries for them (

So now you can see , that with Bitcoin type of Blockchain + ECC we won't get
 really good number of tx/sec, right ?

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

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

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

PayPal is a parasitic layer upon CC.
They get as much suckers money as they can.

But Bitcoin ( and your system ) is universal
 analog of cash.
If one mini-blockchain can not take over the world, there needs to be a lot of mini-chains.
Then there will be bridges between them,
with all additional exchange back and forth
 costs for end users.

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.

I had been thinking about similar idea independently and think it's possible. See here:
https://bitcointalksearch.org/topic/m.1976355

Can it be used for signing?


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


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

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.

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.

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.

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.

OK. I thought you were developing a universal currency.

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.

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

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.

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.

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.

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.

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.

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.