Topic: "APCXS" - Official Development Thread (Read 2138 times)

There are a couple of points that I just really don't understand in all these alt-coins. But mainly the block time.

All alt-chain still using the same Internet! With the same infrastructure! A block every 10 minutes and 6 confirmations tx acceptance are suggested by Satoshi with regard to estimated propagation time for a tx to reach the whole network and for it to be included and buried deep enough to be very hard to impossible to be double spent with specific types network attacks.

Does not that mean that for an alt-coin with a 2 minutes block time, 30 confirmations are supposed to be the recommended instead of just 6?

Secondly regarding this particular idea. You are trying to solve a problem that do not exist in my opinion. You are trying to solve the problem of bootstrapping an alt-coin in a world full of miners where some of them are big enough to hinder the growth out of infancy of an alt-coin.

Even if there is a problem that I don't see, there is another issue of a bad solution. So basically you are suggesting 2 block-chains and jumping back and forth between them? Even if that was possible is it feasible? we are already brainstorming and trying to the death to solve the problem of an exponentially growing block chain.

You are misunderstanding, this would be a feature of the client to reject blocks which exceed the limit per client.

If you have 12 miners doing a total of 6 GH/s pointed at a single client the client will reject additional blocks that exceed the limit for your hashrate tier.

However, I have been thinking about this and I think it may be better for the client to automatically enroll you into the proper chain based on which tier your hashing rate places you in.

So, for example if you have 12 miners doing a total of 6 GH/s pointed at a single client, the client would recognize the total hashrate being applied and would escalate you from one tier to the next until you reach the proper tier for people of a comparable hashrate.

I would also like to incorporate a feature which RuCoin has that if someone on of the chains should gain 51% control of their tier the network would go into a defensive mode and would begin accepting blocks from each chain round-robin style (chain #1 finds a block, then chain #2, then chain #3 and repeat until the user no longer has 51%). In this fashion all the "attacker's" blocks would be rejected by the network at least until it was that specific chain's turn to find a block or until the "attacker" reduced his hashing power or left the network completely.

This should make the coin friendly to ASICs, FPGA, GPU and CPU users alike while also providing theoretical 51% immunity because the network will adjust to users with high hashrates rather than try to fight them, fast and reliable confirmation times due to a reliably consistent block generation rate (due to rapid re-targets preventing any single chain from stalling for an extended period of time due to dramatic loss of hashing power, dramatic increases in hashing power from a single source will be capped by the "defensive" mode and traditional "long rounds" are eliminated by multiple chains with varying difficulties) as well as a few other features I have in mind.

A miner with a high hashrate would not need to run multiple clients, they could simply alternate submitting blocks through various proxies.  This could be done for free using Tor.

The system would work by limiting the number of shares from a ip as well as from a single client. In order to exploit it the attacker would need to split his hashing power amongst multiple ips pointed at multiple clients as the network would reject extraneous blocks from each individual client as well as each individual ip.

It would still be possible of course but would be extremely resource intensive as you would need either multiple machines or multiple virtual machine instances since each client would need it's own listening and rpc ports communicating with the network from different ip's.

This is something I will put more thought into before beginning.

How is this enforced?  Big miners will just split their mining power between multiple IP addresses and become indistinguishable from a group of small users.

With my proposed currency each mining chain would have it's own separate difficulty respective to the amount of hashing power within that chain.

Chain #1 which is for very low hashrates would have the same target number for confirmations as chain #3 but they should still be generating blocks (confirmations) at the same rate because of the each chain's individual difficulty setting.

With each tier containing only miners with relative hashing power the set "time" for confirmations should be pretty consistent and fairly reliable since someone hopping on chain #3 with their avalon won't affect the lower tiers which will continue to generate blocks at the same consistent rate.

We will experiment with different re-target times for each chain but I think a single rapid re-target system (somewhere around 1 to 10 blocks) will be sufficient for all the chains to keep block generation (confirmations) consistent.

With this system I believe we would need no more than 6 - 10 confirmations for a tx and I believe we could consistently achieve those 6 - 10 confirmations within 5 - 10 minutes.


Please see above


With a single chain (like current coins use) it is very inflexible since if the network has a long round the network comes to a screeching halt.

With my currency you would have multiple chains to distribute the workload across, all working on the same block with different target difficulties, the likelihood of all the relevant chains with separate difficulties being simultaneously stuck on a long round is highly improbable.

I've often focused in on the idea of meta-chains when discussed on the forums.  (And I wish the term 'meta-chain' would be adopted by convention for the concept of multiple chains per coin)

I believe that such meta-chains can provide additional utility and not only as a means to normalize/restrict hashrate.

Bitcoin is missing the following

1.  Tier based SLA predictability.
Combine fixed block size to 10 minute confirmation windows and establishing an SLA is not reliably possible.  Many people are addressing this concern by inventing 'off-chain' payment channels.  Others are addressing it from a tx fee point of view.  Both of these types of solutions are either not entirely predictable or inelegant. 

IMO, 'off-chain' payment channels is a symptom of a coin that is unable to meet demand.  On other words, a failed coin.

I could imagine that, if the option were present, that there would be a market for low-priority and high-priority (confirmation time) sub-chains.

2.  Dynamic transaction volume / unit time scaling (regardless of hashrate)
When one thinks of a coin with a single chain being pressured to meet transaction volume demand the ideas of fixed block size and fixed confirmation time is a serious shortfall.

The lack of a memory pool pressure metric that is synchronized across all nodes leaves Bitcoin in a poor state to dynamically adjust transaction volume while ensuring sufficient transaction capacity scarcity to support a network that survives based on transaction fees. (Once coinbase subsidy is no longer sufficient for network survival.)

However, if one were to approach this problem by use of a meta-chain, or multiple sub-chains, with each having it's own transaction confirmation velocity, then that might work better than trying to fix a a coin with a single chain.

Though, I do have concerns about coin mobility through each sub-chain.  How sub-chains could be reconciled.


Still, even with a meta-chain I believe global memory pool pressure is an important factor.  If a metric that describes global memory pool pressure is known by all nodes some system could be established that dynamically adjusts velocity while maintaining scarcity.


IMO, Bitcoin lacks consciousness of network demand and without that it's too inflexible.  On the other hand, quite a few smart developers have pointed out how a demand-based dynamic system might be gamed in such a way to minimize tx fees.



Just food for thought.  Thanks.

"APCXS - Advanced Parallel Crypto eXchange System"

tl;dr is at bottom, skip to next bold section

I was originally typing this in response to another thread about an alt-coin (not going to say which one) which appears to be in it's death-throes, but as I was typing it I realized it was a good idea (in my opinion) and decided to actually put together a dev team and try to make it.

Looking around the forums I see coins with a lot of problems and I have had some ideas as to how some of these problems can be solved. Most notably however seems to be the alt-coins which are being attacked by ASICs users.

It seems to me that the most viable solution for any existing coin being attacked would be more forks of that specific blockchain, perhaps working on a tiered system. Picture this:



Alternatively, for new coins (not sure how easy it would be to integrate the following on an existing coin) what I believe would be the best solution
for any crypto-currency would be the following scenario:


Obviously, these ideas are not all-inclusive and there would need to be multiple security redundancies to make sure that all tx's on the transaction network are processed by the mining network and vice-versa when a purse balance is updated on the transaction network to make sure that the tx was actually processed by the mining network before adding or removing coins from a balance but I believe it can be done.

I would also like to incorporate a feature which RuCoin has that if someone on of the chains should gain 51% control of their tier the network would go into a defensive mode and would begin accepting blocks from each chain round-robin style (chain #1 finds a block, then chain #2, then chain #3 and repeat until the user no longer has 51%). In this fashion all the "attacker's" blocks would be rejected by the network at least until it was that specific chain's turn to find a block or until the "attacker" reduced his hashing power or left the network completely.

This should make the coin friendly to ASICs, FPGA, GPU and CPU users alike while also providing theoretical 51% immunity because the network will adjust to users with high hashrates rather than try to fight them, fast and reliable confirmation times due to a reliably consistent block generation rate (due to rapid re-targets preventing any single chain from stalling for an extended period of time due to dramatic loss of hashing power, dramatic increases in hashing power from a single source will be capped by the "defensive" mode and traditional "long rounds" are eliminated by multiple chains with varying difficulties) as well as a few other features I have in mind.

If anyone is interested in helping me to create an alt-coin with these features I would be more than happy to team up and have a go at it...

This will be done entirely in the public eye. There will be no pre-mine (all testing will be done on testnet and/or unofficial blockchain which will never be used by the official network). We will make an official announcement here in the forums with the official release date with plenty of notice so that everyone has the same opportunity to begin mining it at the same time.

I also have a few other ideas for the coin, some borrowed, others my own original concepts, contact me if you have relevant knowledge and are interested in creating a dev team...

EDIT: Basic Details/Features of APCXS (begin tl;dr):

1. Separate networks for mining and transactions
2. Multiple blockchains with separate difficulties on the mining network tiered by hashrate limitations
3. Reliably consistent block generation (tx confirmation) times
4. Short confirmation times
5. Rapid difficulty re-targets
6. Tiered approach makes this coin friendly for ASIC, GPU and CPU miners alike
7. Users are automatically enrolled into the proper tier based on their hashing power
8. 51%, double-spend attacks and difficulty attacks are theoretically eliminated