Topic: For consideration, next-gen coins... Gen-3 - page 2. (Read 3247 times)
I like this thread already.
Isn't the semi-decreased reward employed with PPC?
Enjoyed reading the thoughts either way.
Enjoyed reading the thoughts either way.
I am working with several people to release a crypto currency that remedies many of the problems I see with the current implementations. I'm hoping that in the next week or two to have something to submit for community discussion. I'm hoping to launch it with several ancillary services, so that there is some use to it at launch. It's not yet set in stone, so I'll be checking this thread to see if there are other ideas that I agree with.
Not trying to supplant BTC. Or ltc. I'll agree that bitcoins gold, litecoin a silver, and don't think those two need to be encroached on. So just saying, please don't knock it til I ask for input
Not trying to supplant BTC. Or ltc. I'll agree that bitcoins gold, litecoin a silver, and don't think those two need to be encroached on. So just saying, please don't knock it til I ask for input
lol... I get that a lot...
I find that response flattering, as well as your confession to consider reading it.
This is what I love about open-source... Often, it only takes an observation, a suggestion (even a bad one), and someone-else to agree or have a better idea, or counter-point, for advancement. {Hello run-on sentence.}
If all of this was just left up to me... We would all be screwed! I am an average programmer, at best. I can make components to test each individual component, but when it comes to throwing it all into one program... You would be better-off with a windows 3.1 spread-sheet and a check-book.
I spend too long hacking my own crap, just to see what it does, and if I can stop myself from breaking it. That is more fun to me.
P.S. That was the short version... Let me get my notes! JK
I find that response flattering, as well as your confession to consider reading it.
This is what I love about open-source... Often, it only takes an observation, a suggestion (even a bad one), and someone-else to agree or have a better idea, or counter-point, for advancement. {Hello run-on sentence.}
If all of this was just left up to me... We would all be screwed! I am an average programmer, at best. I can make components to test each individual component, but when it comes to throwing it all into one program... You would be better-off with a windows 3.1 spread-sheet and a check-book.
I spend too long hacking my own crap, just to see what it does, and if I can stop myself from breaking it. That is more fun to me.
P.S. That was the short version... Let me get my notes! JK
Ugh ugh,this was my first impression:
I have read the start of it, a few sentances, will sure read the rest in time.
I have read the start of it, a few sentances, will sure read the rest in time.
To start-off, I would like to clarify what I believe are the two generations of coins here.
First, as I see it, Bitcoins, Litecoins, Feathercoins, Mincoins, Worldcoins, etc... are all POW (Proof of work) Gen-1 coins. You mine them, you find blocks, you make tx's.
Second, as I see it, PPcoins, Bottlecaps, and other POW/POS (Proof of work/Proof of stake) Gen-2 coins. You mine them, you find blocks, you make tx's, and you gain rewards for holdings through staked coins.
Third, as I see it, would be a coin that does additional work, beyond POW/POS, like Primecoin, which (forgive my lack of knowledge here on the coin) seems to be additionally generating or solving portions of prime-calculations, but with no actual reward for that work, directly. (Not to the miners, though I am sure the programmer is getting credit or use from the calculations.)
Or...
Third, as I see it, would be a coin that takes previous knowledge of other coins short-falls and strengths, and finds alternatives to subdue the bad and enhance the good, in a semi-dramatic way. (Eg, not just changing values of times, blocks, rewards, or logos.)
My suggestions, as poor as they are, are for Gen-3 coins. As I am sure the suggestions would surely disrupt the long-standing value and familiarity with existing coins structures.
##############################
Feel free to skip past my observations (Marked below)
##############################
To this, I have to add the following observations...
- Block-time targets of less than 1 minute are not good for the network. They do not propagate fast enough, leading to many avoidable and undesired forks/orphans. This is partly due to the nature of mining, which anyone can find 10 or more blocks within the first-find, well before the first block has traversed the net. Each new block is a new lotto-ticket, and a 1000000-diff block has as much chance of being found as a 1-diff block. Though it is more rare... when 10 DO get found, that instantly creates a fork on half the network. Half mining on the 10-blocks ahead, and half mining on the 10-blocks behind. Issue also related to retargeting block times...
- Block retarget times of a fixed-length of blocks, which is non-adaptive per-block, is bad for the network. With the known issue of coin-jumpers, this becomes more clear, mostly to any new or slower coin. Waiting for x-blocks before a diff-change after a coin has been mined to hell, into the ground, makes constant miners leave. They do not want to stay and mine a coin that once offered them 200 a day, but now only offers them 50 a day, which it will offer them for the next x-blocks. The diff-adjustment would be fine, if the coin had a constant x-miners STILL hashing away at that speed, but they all leave once they drive the diff through the roof and value into the ground.
- Block rewards that decay with more power, or are too high. This, I have mixed feelings about, because this seems to be one of the most abused and least knowledgeable areas of the programmers focus. Sorry, but there are only about three coins that I have seen, with true "economic planning" with relation to this major core element of the coins. They just throw values into the program and "hope it all works out". I only see two instances where this is sort-of true, but it is an illusion hidden by denial. lol. The three instances which have taken this major issue into consideration, just failed to capture the reality of what they intended to do, though they did it the best they could, without having to rewrite the whole program.
- Single-chains that allow you to MINE while disconnected from "the majority", creating forks and allowing, time-warp attacks, 51% attacks, stall-attacks, and various other exploits. Not to mention tx's being delayed, ignored, dumped, erased, because of some of the above issues.
- Block-spending and tx-spending, without consideration for age of tx-origin or age of block-origin. This issue goes beyond user issues, and into exchanges. Naturally any tx from any block that appears on "the chain you are on", which is valid, is accepted. However, if there is a fork, and that young-tx comes from a young-block on this fork... The TX has a good chance to be erased, along with the block it originated from. However, and older block, and tx, even if it was in the fork... would simply just move to the other fork after a correction. (I believe), as those coins were not generated in the fork, and thus, have the ability to move. Having the ability to say, when a fork is detected or not, no I will not give you credit for this exchange until the fork has resolved... due to that specific coin coming from a block that is not below the hard-code... yet, still accepting a coin coming from a block below the hard-coded block... would greatly reduce a lot of spending issues.
- Fixed IP's never "trying" for more than the ones you constantly connect to, without regard for others being closer, or attempting to "confirm" that the ones you are connected to, have the correct chain. This is another problem that aids to the issues above. There does not seem to be any "trying" for more connections. There is no "stay connected to one slow connection", while also "staying connected to the "one closest and fastest responding connection". There is no warning about, "multiple block-heights detected, mine with caution.", or "Which block-height would you like to connect to." (For instances where selection is critical, or can be used to choose not to RISK mining on a wrong chain.)
###########################
End of observations
###########################
My suggestions for consideration... and why... (Not that all suggestions are good, or worth throwing into one coin, or clearly extrapolated.)
1: Non-decentralized block-height tracking and block-height confirmation. (Every n-th block, you check if the block-height you are mining is correct. If not, you get a link to someone with the correct block-height. The correct block-height is simply the tallest one, that audits-out correctly, which has been reported or tracked by the centralized sources, and spread through the decentralized mining network of nodes.)
2: Minimum block-time of 1 minute, from last block. Forget diff-settings. The best diff submitted, after 1 minute from the last blocks time, gets the solution. (Waiting for 30-seconds of mining, before attempting to submit solutions. Submitting the best of what you found, while you race yourself.) If a solution is submitted, you have to beat that solution, before the minute is up. The first best solution after a minute, is the new block solution you want to build off of. (The other best solution is dynamic diff adjustments. Using the target of 1-min, after every block, it adjusts to compensate. EG, one fast block found in 0.5 seconds, forces a diff for the next block to be real high. About half-height, since this was obviously a "lucky shot", but someone-else may have a "luck-shot" on the next block, and it would again adjust higher, to compensate. If not, then it reduces by half, and half again, and half again, until the target of 60 in the hour have been reached.)
3: Mandatory minimum and maximum tx volume, and mandatory minimum and maximum tx-fees. Except for internal moves, within your own wallet. (See below.) This would be as follows... Assume the minimum unit is 0.00000001 (8 decimals). Minimum tx being 0.00001 (5 decimals), with a minimum tx-fee of 0.00000001 (8 decimals) or 0.1%. {for the minimum tx volume, that would be 0.00000001 or 0.1%} Also having a maximum tx volume of 10,000 to limit theft and make attacks that spend fraudulent coins, less of an impact. EG, they would have to create TONS of fake transactions, not one giant transaction of 100,000,000. This fee being deposited into block 0, which can never be withdrawn from, but is always tracked. Used to eat-up coins, so creation of coins can be off-set by high-volumes of tx's, and also for block-height confirmation, for auditing.
4: Wallet-2-wallet moves, being a zero-tx move. One that is done by the wallet, without instruction, to consolidate coins to one location or address within the wallet, to reduce dust. No dust transactions. If dust is detected, then auto-move the funds into one address, prior to sending, without the dust-fees. It is the wallet that made the dust, beyond our control, but we get charged a penalty for the system creating dust. That is not needed. Nor is a "tax" on moving coins from one address in a wallet, to another, for consolidation and dust-removal.
5: Multiple chains, linked as one. I would personally use 8 or 10 or 16 or whatever, related to the last digit of the "sending" account. This way an attacker would need that many MORE computers to attempt to actually attack a network. All transactions moving forward, first withdrawn, if available... then in the next up-coming block, the deposit is made, which matches the initial withdraw. Each hashed to the block below, of the same ID... 2, 2, 2, 2, 2... as a column, and that also hashed to the adjacent block... 2->3->4->... 9->0 (0 of the next row, from 9 of the last row.) Like a giant knitted scarf. All transactions moving forward, so a withdraw from account xxxxxxxxxxx7 going to yyyyyyyyyy7 would be deposited in the next block up, since withdraws should NOT be in the same block as the deposits, in any chain.
6: Secondary rewards, that are realistic and not ones that will impact the system in a horribly negative way. Holding coins makes less available, yes... but that artificially increases the value, which leads to dumping large holdings. Unlike a bank, where your holdings are lent-out to others, which the banks offer you a "return on that money you let them borrow"... Holding these coins should NOT have rewards, unless those holdings are destroyed, to be payed-back, from TX gains, in the future. (See above). Abundance would be reduced, and depending on the quantity you destroy, the more you should make from the tx-fees. (In this case, your destroyed coins would be added to another account in block 0, so you would get those back later, along with coins from tx-fees, rewarded by the system.) EG, if you destroy 1000 coins, and that is 1/10,000th of the total destroyed coins, then you get rewarded with 1/10,000th of the last deposited tx-fees, and that same number of coins which you destroyed. If 1/10,000th of tx's was 100 coins, you would get back 200 coins, 100 from tx-fees that others paid, and 100 of your coins back, leaving you with 900 destroyed coins left to gain from.)
7: Third party rewards, lets say encryption services... you, while generating hashes, are creating a cypher-key for something like a website, for use in private strong encryption, that is disposable. They buy coins from anyone, and attach "work" to those coins. If you get that block, and solve that work, you get that coin as a reward, which replaces one of the normally "generated" coins from "nothing". Though it is not a direct reward to YOU, it is to the network as a whole. Because that is one less coin in circulation, and that was one coin that someone earned, possibly you, which was purchased for physical money, for real work. (Unlike prime-coins, which I am sure the programmers are making a killing off, but not offering that reward to the miners or the system, by destroying coins, or reducing coins created from "nothing".)
8: Block rewards should start super small, and rise with network growth but rewarding less per user, only decaying in the event of abundance or over-growth, for stability. Starting with a reward of 2000, when there are 10 people, then lowering to 200 when there are 100 people, then decaying further to 20 when there are 1,000 people, and ultimately going to 2 for 10,000 miners, and then zero... is just freaking stupid. That is zimbabweism in reverse. Just as going in the other direction is just as bad, growing to keep everyone mining and getting the same reward, no matter how many people mine. (I don't think anyone has done that yet, but I imagine someone will.) Having a coin value that adjusts to the power of the network, increasing to allow nearly the same reward, but slightly less with more power, encourages growth and use. EG, rewarding 1 for 1 miner, 0.9 per miner for 10 miners, 0.8 per miner for 100 miners, 0.7 per miner for 1,000 miners, 0.6 per miner for 10,000 miners... until it goes to 0.1, then it gets dramatic and goes to 0.05, 0.025, 0.0125, etc... With supplemented "coins from nothing", coming from "real work" or "transfer fees", to keep the "coins from nothing", limited. If there are more miners, then there are more people trading. If the price is not jumping all over creation, matching the production, then there will be more people trading. The more people trading, the more fees, the more fees, the less coins are created. That balances out. (If not, you make slight adjustments to the values... SLIGHT... ones that will not threaten transactions or mining, in a seriously negative way. EG, through public consensus.)
9: Reduce the need for pools. Solo-mining should be possible, at any point in time. Coins that spent so much time "trying to decentralize" and "trying to beat the man"... seem to only favor "centralized exchanges and pools" and "only favor the MAN with the biggest GPU army." Kind of defeats the purpose of the coins, almost as much as dust-fees and killing micro-transactions, which was the whole purpose of bitcoins in the first place... for micro-transactions. They didn't put all those decimals in there for fun. Much of the above, mostly #8, goes towards "solo mining", and it also goes towards coin-hoppers. If they hop, they get less. If they stay, they get more. Those that stay, don't get raped by the hoppers. The more the merrier, pools or solo.
10: Lock and hold transactions. This is for traders and exchanges and for escrow use, mostly... and for "trusted" stores that would like to reduce transfer overhead. You make a tx, but the money does not actually leave your wallet. It remains in your wallet, unlocked only to the recipient. They don't have to take it until they need it, or they can unlock it back to you, or forward and unlock it to a third-party. EG, You want to trade it at an exchange. You unlock it to them, they see it is available, but they don't take it until you actually trade it. Then, they can forward it to the new owner, only loosing one transfer fee, not two transfer fees. (One fee depositing it to the exchange, one fee depositing it to the new owner, after they withdraw it.) Also, the network has one less transaction to deal with, and if you decide not to trade, the exchange has the ability to just refund your coins back to you, without a fee, or with only one fee. Same for an escrow account, where you unlock it to the service, and the service unlocks it to the recipient, in the event that both parties are in agreement. Shops can leave funds there, returning them without loss, if they decide they can not send an item, or in the event that they legally have to return the funds due to shipping or other issues. But, for all intense purposes, that unlocked money is out of your wallet control, and in control of the new owner you unlocked it to. It is also your proof of payment, and proof that they got it, as it would indicate "collected". Like a receipt system, without the other party having to actually be online with a wallet, to give you a receipt, or without having to clutter the network with receipt transactions returning to the sender.
11: This one is a little harder... but... if the rewards were offered to "the best 100 submitted solutions", that would greatly increase the participation of those who solo-mine, and also make it nearly impossible for an attack, and make any attack easy to detect and reject. Spreading the wealth, demanding that only one "best solution per wallet" is submitted would also thwart any pools from mining, or massive coin-hopper individuals with uber solo-mining ability from disrupting the network. Keeping the "reward solutions" separate from the diff-1 tx solutions, would allow reward solutions to be able to be removed after every hard-coded block. (Since those solutions were all confirmed by 1000+ audits, and are no longer needed as proof of work to be used in the chain, only the short and simple diff-1 solutions that locked the tx-blocks are needed at that point, which holds the 100 accounts that submitted solutions.)
############################
End of my thoughts for consideration... You can wake-up now...
############################
First, as I see it, Bitcoins, Litecoins, Feathercoins, Mincoins, Worldcoins, etc... are all POW (Proof of work) Gen-1 coins. You mine them, you find blocks, you make tx's.
Second, as I see it, PPcoins, Bottlecaps, and other POW/POS (Proof of work/Proof of stake) Gen-2 coins. You mine them, you find blocks, you make tx's, and you gain rewards for holdings through staked coins.
Third, as I see it, would be a coin that does additional work, beyond POW/POS, like Primecoin, which (forgive my lack of knowledge here on the coin) seems to be additionally generating or solving portions of prime-calculations, but with no actual reward for that work, directly. (Not to the miners, though I am sure the programmer is getting credit or use from the calculations.)
Or...
Third, as I see it, would be a coin that takes previous knowledge of other coins short-falls and strengths, and finds alternatives to subdue the bad and enhance the good, in a semi-dramatic way. (Eg, not just changing values of times, blocks, rewards, or logos.)
My suggestions, as poor as they are, are for Gen-3 coins. As I am sure the suggestions would surely disrupt the long-standing value and familiarity with existing coins structures.
##############################
Feel free to skip past my observations (Marked below)
##############################
To this, I have to add the following observations...
- Block-time targets of less than 1 minute are not good for the network. They do not propagate fast enough, leading to many avoidable and undesired forks/orphans. This is partly due to the nature of mining, which anyone can find 10 or more blocks within the first-find, well before the first block has traversed the net. Each new block is a new lotto-ticket, and a 1000000-diff block has as much chance of being found as a 1-diff block. Though it is more rare... when 10 DO get found, that instantly creates a fork on half the network. Half mining on the 10-blocks ahead, and half mining on the 10-blocks behind. Issue also related to retargeting block times...
- Block retarget times of a fixed-length of blocks, which is non-adaptive per-block, is bad for the network. With the known issue of coin-jumpers, this becomes more clear, mostly to any new or slower coin. Waiting for x-blocks before a diff-change after a coin has been mined to hell, into the ground, makes constant miners leave. They do not want to stay and mine a coin that once offered them 200 a day, but now only offers them 50 a day, which it will offer them for the next x-blocks. The diff-adjustment would be fine, if the coin had a constant x-miners STILL hashing away at that speed, but they all leave once they drive the diff through the roof and value into the ground.
- Block rewards that decay with more power, or are too high. This, I have mixed feelings about, because this seems to be one of the most abused and least knowledgeable areas of the programmers focus. Sorry, but there are only about three coins that I have seen, with true "economic planning" with relation to this major core element of the coins. They just throw values into the program and "hope it all works out". I only see two instances where this is sort-of true, but it is an illusion hidden by denial. lol. The three instances which have taken this major issue into consideration, just failed to capture the reality of what they intended to do, though they did it the best they could, without having to rewrite the whole program.
- Single-chains that allow you to MINE while disconnected from "the majority", creating forks and allowing, time-warp attacks, 51% attacks, stall-attacks, and various other exploits. Not to mention tx's being delayed, ignored, dumped, erased, because of some of the above issues.
- Block-spending and tx-spending, without consideration for age of tx-origin or age of block-origin. This issue goes beyond user issues, and into exchanges. Naturally any tx from any block that appears on "the chain you are on", which is valid, is accepted. However, if there is a fork, and that young-tx comes from a young-block on this fork... The TX has a good chance to be erased, along with the block it originated from. However, and older block, and tx, even if it was in the fork... would simply just move to the other fork after a correction. (I believe), as those coins were not generated in the fork, and thus, have the ability to move. Having the ability to say, when a fork is detected or not, no I will not give you credit for this exchange until the fork has resolved... due to that specific coin coming from a block that is not below the hard-code... yet, still accepting a coin coming from a block below the hard-coded block... would greatly reduce a lot of spending issues.
- Fixed IP's never "trying" for more than the ones you constantly connect to, without regard for others being closer, or attempting to "confirm" that the ones you are connected to, have the correct chain. This is another problem that aids to the issues above. There does not seem to be any "trying" for more connections. There is no "stay connected to one slow connection", while also "staying connected to the "one closest and fastest responding connection". There is no warning about, "multiple block-heights detected, mine with caution.", or "Which block-height would you like to connect to." (For instances where selection is critical, or can be used to choose not to RISK mining on a wrong chain.)
###########################
End of observations
###########################
My suggestions for consideration... and why... (Not that all suggestions are good, or worth throwing into one coin, or clearly extrapolated.)
1: Non-decentralized block-height tracking and block-height confirmation. (Every n-th block, you check if the block-height you are mining is correct. If not, you get a link to someone with the correct block-height. The correct block-height is simply the tallest one, that audits-out correctly, which has been reported or tracked by the centralized sources, and spread through the decentralized mining network of nodes.)
2: Minimum block-time of 1 minute, from last block. Forget diff-settings. The best diff submitted, after 1 minute from the last blocks time, gets the solution. (Waiting for 30-seconds of mining, before attempting to submit solutions. Submitting the best of what you found, while you race yourself.) If a solution is submitted, you have to beat that solution, before the minute is up. The first best solution after a minute, is the new block solution you want to build off of. (The other best solution is dynamic diff adjustments. Using the target of 1-min, after every block, it adjusts to compensate. EG, one fast block found in 0.5 seconds, forces a diff for the next block to be real high. About half-height, since this was obviously a "lucky shot", but someone-else may have a "luck-shot" on the next block, and it would again adjust higher, to compensate. If not, then it reduces by half, and half again, and half again, until the target of 60 in the hour have been reached.)
3: Mandatory minimum and maximum tx volume, and mandatory minimum and maximum tx-fees. Except for internal moves, within your own wallet. (See below.) This would be as follows... Assume the minimum unit is 0.00000001 (8 decimals). Minimum tx being 0.00001 (5 decimals), with a minimum tx-fee of 0.00000001 (8 decimals) or 0.1%. {for the minimum tx volume, that would be 0.00000001 or 0.1%} Also having a maximum tx volume of 10,000 to limit theft and make attacks that spend fraudulent coins, less of an impact. EG, they would have to create TONS of fake transactions, not one giant transaction of 100,000,000. This fee being deposited into block 0, which can never be withdrawn from, but is always tracked. Used to eat-up coins, so creation of coins can be off-set by high-volumes of tx's, and also for block-height confirmation, for auditing.
4: Wallet-2-wallet moves, being a zero-tx move. One that is done by the wallet, without instruction, to consolidate coins to one location or address within the wallet, to reduce dust. No dust transactions. If dust is detected, then auto-move the funds into one address, prior to sending, without the dust-fees. It is the wallet that made the dust, beyond our control, but we get charged a penalty for the system creating dust. That is not needed. Nor is a "tax" on moving coins from one address in a wallet, to another, for consolidation and dust-removal.
5: Multiple chains, linked as one. I would personally use 8 or 10 or 16 or whatever, related to the last digit of the "sending" account. This way an attacker would need that many MORE computers to attempt to actually attack a network. All transactions moving forward, first withdrawn, if available... then in the next up-coming block, the deposit is made, which matches the initial withdraw. Each hashed to the block below, of the same ID... 2, 2, 2, 2, 2... as a column, and that also hashed to the adjacent block... 2->3->4->... 9->0 (0 of the next row, from 9 of the last row.) Like a giant knitted scarf.
All transactions moving forward, so a withdraw from account xxxxxxxxxxx7 going to yyyyyyyyyy7 would be deposited in the next block up, since withdraws should NOT be in the same block as the deposits, in any chain.6: Secondary rewards, that are realistic and not ones that will impact the system in a horribly negative way. Holding coins makes less available, yes... but that artificially increases the value, which leads to dumping large holdings. Unlike a bank, where your holdings are lent-out to others, which the banks offer you a "return on that money you let them borrow"... Holding these coins should NOT have rewards, unless those holdings are destroyed, to be payed-back, from TX gains, in the future. (See above). Abundance would be reduced, and depending on the quantity you destroy, the more you should make from the tx-fees. (In this case, your destroyed coins would be added to another account in block 0, so you would get those back later, along with coins from tx-fees, rewarded by the system.) EG, if you destroy 1000 coins, and that is 1/10,000th of the total destroyed coins, then you get rewarded with 1/10,000th of the last deposited tx-fees, and that same number of coins which you destroyed. If 1/10,000th of tx's was 100 coins, you would get back 200 coins, 100 from tx-fees that others paid, and 100 of your coins back, leaving you with 900 destroyed coins left to gain from.)
7: Third party rewards, lets say encryption services... you, while generating hashes, are creating a cypher-key for something like a website, for use in private strong encryption, that is disposable. They buy coins from anyone, and attach "work" to those coins. If you get that block, and solve that work, you get that coin as a reward, which replaces one of the normally "generated" coins from "nothing". Though it is not a direct reward to YOU, it is to the network as a whole. Because that is one less coin in circulation, and that was one coin that someone earned, possibly you, which was purchased for physical money, for real work. (Unlike prime-coins, which I am sure the programmers are making a killing off, but not offering that reward to the miners or the system, by destroying coins, or reducing coins created from "nothing".)
8: Block rewards should start super small, and rise with network growth but rewarding less per user, only decaying in the event of abundance or over-growth, for stability. Starting with a reward of 2000, when there are 10 people, then lowering to 200 when there are 100 people, then decaying further to 20 when there are 1,000 people, and ultimately going to 2 for 10,000 miners, and then zero... is just freaking stupid. That is zimbabweism in reverse. Just as going in the other direction is just as bad, growing to keep everyone mining and getting the same reward, no matter how many people mine. (I don't think anyone has done that yet, but I imagine someone will.) Having a coin value that adjusts to the power of the network, increasing to allow nearly the same reward, but slightly less with more power, encourages growth and use. EG, rewarding 1 for 1 miner, 0.9 per miner for 10 miners, 0.8 per miner for 100 miners, 0.7 per miner for 1,000 miners, 0.6 per miner for 10,000 miners... until it goes to 0.1, then it gets dramatic and goes to 0.05, 0.025, 0.0125, etc... With supplemented "coins from nothing", coming from "real work" or "transfer fees", to keep the "coins from nothing", limited. If there are more miners, then there are more people trading. If the price is not jumping all over creation, matching the production, then there will be more people trading. The more people trading, the more fees, the more fees, the less coins are created. That balances out. (If not, you make slight adjustments to the values... SLIGHT... ones that will not threaten transactions or mining, in a seriously negative way. EG, through public consensus.)
9: Reduce the need for pools. Solo-mining should be possible, at any point in time. Coins that spent so much time "trying to decentralize" and "trying to beat the man"... seem to only favor "centralized exchanges and pools" and "only favor the MAN with the biggest GPU army." Kind of defeats the purpose of the coins, almost as much as dust-fees and killing micro-transactions, which was the whole purpose of bitcoins in the first place... for micro-transactions. They didn't put all those decimals in there for fun. Much of the above, mostly #8, goes towards "solo mining", and it also goes towards coin-hoppers. If they hop, they get less. If they stay, they get more. Those that stay, don't get raped by the hoppers. The more the merrier, pools or solo.
10: Lock and hold transactions. This is for traders and exchanges and for escrow use, mostly... and for "trusted" stores that would like to reduce transfer overhead. You make a tx, but the money does not actually leave your wallet. It remains in your wallet, unlocked only to the recipient. They don't have to take it until they need it, or they can unlock it back to you, or forward and unlock it to a third-party. EG, You want to trade it at an exchange. You unlock it to them, they see it is available, but they don't take it until you actually trade it. Then, they can forward it to the new owner, only loosing one transfer fee, not two transfer fees. (One fee depositing it to the exchange, one fee depositing it to the new owner, after they withdraw it.) Also, the network has one less transaction to deal with, and if you decide not to trade, the exchange has the ability to just refund your coins back to you, without a fee, or with only one fee. Same for an escrow account, where you unlock it to the service, and the service unlocks it to the recipient, in the event that both parties are in agreement. Shops can leave funds there, returning them without loss, if they decide they can not send an item, or in the event that they legally have to return the funds due to shipping or other issues. But, for all intense purposes, that unlocked money is out of your wallet control, and in control of the new owner you unlocked it to. It is also your proof of payment, and proof that they got it, as it would indicate "collected". Like a receipt system, without the other party having to actually be online with a wallet, to give you a receipt, or without having to clutter the network with receipt transactions returning to the sender.
11: This one is a little harder... but... if the rewards were offered to "the best 100 submitted solutions", that would greatly increase the participation of those who solo-mine, and also make it nearly impossible for an attack, and make any attack easy to detect and reject. Spreading the wealth, demanding that only one "best solution per wallet" is submitted would also thwart any pools from mining, or massive coin-hopper individuals with uber solo-mining ability from disrupting the network. Keeping the "reward solutions" separate from the diff-1 tx solutions, would allow reward solutions to be able to be removed after every hard-coded block. (Since those solutions were all confirmed by 1000+ audits, and are no longer needed as proof of work to be used in the chain, only the short and simple diff-1 solutions that locked the tx-blocks are needed at that point, which holds the 100 accounts that submitted solutions.)
############################
End of my thoughts for consideration... You can wake-up now...
############################
Jump to: