YC
@ Digibyte, How nice to see an idea get some traction! Glad to see it being considered, analyzed, broken down, and dissected. Ideas are just for that: brainstorming starting points that more often than not end up leading to something very different than what they were to begin with. Real nice input so far to get things rolling. I'm delighted to see interest in the debate.
One of the first things I start to do with any idea I have is doubt myself to begin with, and one of my major doubts with this has to do with whether or not the CPU miner is really feasible anymore (regardless of how much we try to make it so), or whether feasibility should even matter to begin with and we shouldn’t strive for CPU competitiveness regardless, and out of principle. I remember seeing oodles of CPU DOGE miners on reddit back in January who were thrilled to be mining double digit amounts of coins a day when a GPU was taking down thousands, and perhaps those same miners would be thrilled to be able to mine again. Another positive would be basic math: if things got really bad and nobody came to the party, at some point the difficulty would be so low that the rewards would look good even to someone like myself.
This is a point for real debate in any event. I wonder if there are any stats out there at all to help us with this.
Another debate centers around whether or not price is really being driven down by specialized miners using ASIC equipment. While I'm very much of the opinion that the answer is yes, many, including the following dev insider, argue the complete opposite: https://bitcointalksearch.org/topic/m.7783111
As you know, I’m not a coder, so I haven’t a clue about what is technically feasible and what isn’t, but the need to keep the little guy “in the game” has me constantly mulling over the issue (very much like you all). This is all very conceptual and the technical aspects certainly leave us with yet another debate.
Taken in Digibyte 'steady as she goes' terms, this all translates into something that might be fairly long term (I might think, but who knows?) since there certainly are lots of questions to be answered.
@ Kayahoga, Your ideas on how to reach the gaming community are so interesting that, now after reading your comments, I too ask myself “why people haven't done this already?” Quite often we miss the forest for the trees.
That one click miner is already happening! I came across this yesterday: https://bitcointalksearch.org/topic/annaid-aidbit-digital-currency-redefined-powpos-groestl-charity-683317
When I mentioned this on the MYR thread, a couple of contributors chimmed in with a couple of ideas (but it really didn't go much further than that, perhaps because there was no dev interest either, who knows?). The main issue that immediately jumped front and center was netbot vulnerability and we talked about the same wallet restrictions and limitations that would lead to the logical conclusion you described in your first point - everyone’s wallet would be the same, and everyone would have the same limitations, thus meaning that regardless of the hash you try to send through any given wallet, you’ll never get credit for more than the maximum limit set.
@ haggis, 1) My thinking, and this is conceptual, mind you, is to not touch, or touch as little as possible, the coin itself, and the only thing that really needs to be done with the coin code would be to set the individual algorithm payouts, and nothing else. 2) The idea was mentioned on the MYR thread that the wallet probably wasn’t going to be able to effectively manage the maximum hashrate “throttling” threshold (which should probably just be referred to as a simple threshold since the world “throttling” suggests something more dynamic than a simple cap) since it could be hacked, like you mentioned, which perhaps would mean that maximum cap would also have to be included in the coin code. I'm thinking now that it would best be managed server side, with the official Qubit P2Pool’s servers doing simple handshake connections and putting a maximum hashrate submission limit into place above which any excess hashrate sent by any given wallet would be simply discarded, and rewards could never be more than that possible for the maximum hashrate share. 3) Everything else would be done with the wallet.
Other secondary ideas mentioned were an IP address connection limit for individual wallets, and, this last one being another of mine, e-mail user registration on install.
Add: I'm also in favor of a 1% fee on all coins mined (that would double at each of the next 2 reward halvings and then stay permanently capped at 4%) that would go directly to development and administration.
One of the first things I start to do with any idea I have is doubt myself to begin with, and one of my major doubts with this has to do with whether or not the CPU miner is really feasible anymore (regardless of how much we try to make it so), or whether feasibility should even matter to begin with and we shouldn’t strive for CPU competitiveness regardless, and out of principle. I remember seeing oodles of CPU DOGE miners on reddit back in January who were thrilled to be mining double digit amounts of coins a day when a GPU was taking down thousands, and perhaps those same miners would be thrilled to be able to mine again. Another positive would be basic math: if things got really bad and nobody came to the party, at some point the difficulty would be so low that the rewards would look good even to someone like myself.
This is a point for real debate in any event. I wonder if there are any stats out there at all to help us with this. Another debate centers around whether or not price is really being driven down by specialized miners using ASIC equipment. While I'm very much of the opinion that the answer is yes, many, including the following dev insider, argue the complete opposite: https://bitcointalksearch.org/topic/m.7783111
As you know, I’m not a coder, so I haven’t a clue about what is technically feasible and what isn’t, but the need to keep the little guy “in the game” has me constantly mulling over the issue (very much like you all). This is all very conceptual and the technical aspects certainly leave us with yet another debate.
Taken in Digibyte 'steady as she goes' terms, this all translates into something that might be fairly long term (I might think, but who knows?) since there certainly are lots of questions to be answered.
@ Kayahoga, Your ideas on how to reach the gaming community are so interesting that, now after reading your comments, I too ask myself “why people haven't done this already?” Quite often we miss the forest for the trees.
That one click miner is already happening! I came across this yesterday: https://bitcointalksearch.org/topic/annaid-aidbit-digital-currency-redefined-powpos-groestl-charity-683317
When I mentioned this on the MYR thread, a couple of contributors chimmed in with a couple of ideas (but it really didn't go much further than that, perhaps because there was no dev interest either, who knows?). The main issue that immediately jumped front and center was netbot vulnerability and we talked about the same wallet restrictions and limitations that would lead to the logical conclusion you described in your first point - everyone’s wallet would be the same, and everyone would have the same limitations, thus meaning that regardless of the hash you try to send through any given wallet, you’ll never get credit for more than the maximum limit set.
@ haggis, 1) My thinking, and this is conceptual, mind you, is to not touch, or touch as little as possible, the coin itself, and the only thing that really needs to be done with the coin code would be to set the individual algorithm payouts, and nothing else. 2) The idea was mentioned on the MYR thread that the wallet probably wasn’t going to be able to effectively manage the maximum hashrate “throttling” threshold (which should probably just be referred to as a simple threshold since the world “throttling” suggests something more dynamic than a simple cap) since it could be hacked, like you mentioned, which perhaps would mean that maximum cap would also have to be included in the coin code. I'm thinking now that it would best be managed server side, with the official Qubit P2Pool’s servers doing simple handshake connections and putting a maximum hashrate submission limit into place above which any excess hashrate sent by any given wallet would be simply discarded, and rewards could never be more than that possible for the maximum hashrate share. 3) Everything else would be done with the wallet.
Other secondary ideas mentioned were an IP address connection limit for individual wallets, and, this last one being another of mine, e-mail user registration on install.
Add: I'm also in favor of a 1% fee on all coins mined (that would double at each of the next 2 reward halvings and then stay permanently capped at 4%) that would go directly to development and administration.
). Hence you can only regulate a miners efficiency by the mathematic mechanics a hashing algo uses.
