Topic: Looking for Partners to Dev the Ultimate Crypto - "APCXS" (Read 721 times)
bump
COPIED FROM OFFICIAL DEV THREAD AS IT CONTAINS RELEVANT INFO: https://bitcointalksearch.org/topic/apcxs-official-development-thread-175875
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.
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.
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.
Quote
Chain #1 limits the maximum number of submitted shares (found blocks) in a given period of time so that it is only viable for being mined by
users with 100 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
Chain #2 limits the maximum number of submitted shares (found blocks) in a given period of time so that it is only viable for being mined by
users with 500 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
Chain #3 limits the maximum number of submitted shares (found blocks) in a given period of time so that it is only viable for being mined by
users with 1000 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
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.users with 100 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
Chain #2 limits the maximum number of submitted shares (found blocks) in a given period of time so that it is only viable for being mined by
users with 500 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
Chain #3 limits the maximum number of submitted shares (found blocks) in a given period of time so that it is only viable for being mined by
users with 1000 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
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.
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.
Copying this from the official development thread at: https://bitcointalksearch.org/topic/apcxs-official-development-thread-175875
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 could imagine that, if the option were present, that there would be a market for low-priority and high-priority (confirmation time) sub-chains.
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.
Quote
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.
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.
Please see above
Quote
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.
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.
"APCXS - Advanced Parallel Crypto eXchange System" - Official Dev Thread: https://bitcointalksearch.org/topic/apcxs-official-development-thread-175875
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
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:
Code:
We have coin "A".
Coin "A" runs on an unlimited number of parallel block chains, they are unable to interact with each other.
Let's say for this example coin "A" has 2 separate blockchain forks.
User "IAmTheBiggestAssholeInTheWorld" hops on blockchain #1 with his brand new Avalon. Making the chain unstable and nearly impossible to mine
for anyone who isn't holding ASICs.
All other users then migrate to blockchain #2 and pay a negligible fee to "money-changers" who have coins on both chains to have their coins
"moved" from chain #1 to chain #2. (Realistically you are forfeiting your coins on chain #1 to someone who will provide you the equivalent
amount in coins on chain #2)
You can add forks as needed and "move" your coins (via the money-changers) between forks as necessary.
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:
Code:
We have coin "A".
Coin "A" Runs on 2 networks (one for mining and one for transactions).
The transaction network is where the user's balances are stored, spent and received. It has a single "blockchain".
The mining network has multiple blockchains which are "tiered" by hashing power.
For this example coin "A" has 3 tiered blockchains.
Chain #1 limits the maximum number of submitted shares (found blocks) from a single user in a given period of time so that it is only viable for being
mined by users with 100 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
Chain #2 limits the maximum number of submitted shares (found blocks) from a single user in a given period of time so that it is only viable for being
mined by users with 500 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
Chain #3 limits the maximum number of submitted shares (found blocks) from a single user in a given period of time so that it is only viable for being
mined by users with 1000 *H/s or less hashing speed. Anyone with a higher hashrate would just be wasting shares.
You can add new tiers with higher demands as necessary as technology advances and hashrates increase.
When you find a block on your respective mining network and it has been confirmed the mining network would notify the transaction network
and your balance would be updated respectively.
In that same fashion when you spend/receive coins the transaction updates the mining network and your tx is added to the next block in the
chain.
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
Jump to: