No no... the "special transaction" would allow miners to perform these transactions without needing the private key, but this would be the only type of transaction which the protocol would allow this to happen. It would be safe to allow it in this case since the coins wont be sent to a different address than where they originated, and they must also be of a specified age. So you don't need to bring any of this other stuff about people needing to refresh their coins (a highly controversial topic you will find), it can be done in an automated fashion by using the refresh transaction within the mining process, as you have described. I guess you could almost call it "defragging the blockchain".

EDIT: Well actually the fee does present a legitimate problem, and it would be hard to make this system work without any incentive like that. Hmm...

Fascinating, I started a thread the other day which suggests a solution to this problem which is based on the same sort of concept. However my idea would require a new alt coin to be made and it works a bit differently to bitcoin in a few areas to solve this problem. I didn't really think it would be possible to alter the blockchain in such a drastic way, but your solution for discarding the stuff we don't need and "scooping" up the "dust" does provide a viable solution (assuming we accept the consequences of changing the protocol in such a way). The solution I came up with sort of avoids having "dust" in the first place because it would use a decentralized database to track the balance of all non-empty addresses, as well as using a "mini-blockchain" (what you might call a "rolling-chain" but in a slightly different sense) to provide that layer of security the blockchain provides. I'd be interested to hear your thoughts on the idea: linky. The opening post is fairly half-assed and you need to read through the 1st page to understand how the concept of a mini-blockchain developed.

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.

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.

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.

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.

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.

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.

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

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

So summed up briefly, how does ripple solve the problem I described in the post above this one?

edit: Ok I just briefly looked into Ripple and it's extremely questionable imo.
It achieves what it achieves through centralization as far as I can tell.
Like the way XRP are issued doesn't seem decentralized or require any proof-of-work...

You're not understanding the problem... it's not just the transactions themselves which need to be transmitted which are the problem, it's the entire blockchain which is built up from all those transactions. In no way, shape, or form is it ideal to have this ever-growing blockchain which is becoming so huge most people don't even bother downloading it, the bandwidth required to download to blockchain is not small. The whole point of this concept is to solve the problem of decentralized money using some sort of system which cannot grow infinitely, the data required to keep track of the network should always remain at manageable levels.

lol that's a pic of my cat.

Sorry I must have left that pic in there accidentally after I did some testing.

Thanks for letting me know though. 

Thank you, I certainly believe our theorizing so far is leading to something which is extremely plausible... it definitely seems to me like a mini-blockchain could indeed work and provide us with that extra layer of security we need without bloating up the network too much. If only I had the programming skills to actually build this system, I am but a mere website developer. I'm hoping someone will give this a shot sooner or later and let us know how it went.

Uh huh... and what exactly is a "not-block"?

You seem to be drastically oversimplify the matter...

Yes but the transactions contains information about the "coins".

Having "just transactions" means a blockchain.

In the long run it wont be, that's the whole point.

edit: but my idea isn't to track the coins, it's to track the addresses.
It will start tiny and grow slowly, much slower than the blockchain.
It should also reach a reasonable upper limit based on a limited population.

Ok that makes perfect sense to me now... and also gives me an idea. Like bitcoin, the difficulty of the transaction block mining process would need to have a dynamic changing value based on the total network power to make it consistently periodic (where as the coin mining process would have hard-coded difficulty levels). But from what I can see this solves our problems... the true valid mini-blockchain will have a cumulative difficulty which is still way beyond anything an attacker could hope to achieve, and it would constantly get harder and harder to outmatch as old weaker blocks are pruned from the start and new stronger blocks added to the end. Let me know if I'm correct on this, I believe I am...

But anyway I really do need to get some sleep now so I'll check in later to see what you think.