63
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [BEN] Benjamins ◄ SHA-256 ►◄ NO HARD FORK INCOMING ►◄ Cryptsy ►◄ PAYSHA! ►
|
on: March 07, 2014, 05:45:45 PM
|
We are 15k blocks ahead of schedule. This has nothing to do with wanting to hold what we already have. None of us have sold a single Benjamin, and in fact have used most of what we mined for giveaways on Reddit, Twitter, Cryptocointalk, and several other sites
Read what Igotspots quoted above. It explains our decision and gives reasons why a fork would make the situation worse. 10 minute block times are better for security, this is a known issue, as well as the KGW holes recently found, further strengthen our decision not to fork
Coins should not be created to serve the miners, but the consumers who will use them in the end. Benjamins will be one of the most secure blockchains once it has the hashpower to back up the numbers. Security and not losing coins or leaving them vulnerable to attack so vendors, exchanges, or traders don't lose payments is more important to us than making a few coin hopping miners happy. I'm sorry, but that's the truth. The ones that have stuck around mining since the beginning will enjoy having rarer-than-planned coins, but that was definitely not our intention
Sorry to be blunt but you are delusional. Appealing to miners is ABSOLUTELY REQUIRED. Without miners transactions cannot be confirmed. No sending coins, no receiving coins, no mining coins. I'm not saying BEN needs KGW. I'm not saying BEN has to decrease the block time (although, it would be my preference if it did). But the diff adjustment issue has to be addressed. Mark my words, the next diff adjustment will never, ever, ever arrive, BEN will never, ever, ever see anything close to 10-minute block times again if you do not fork this coin. I can't make it any more clear. If we make difficulty adjust faster, it will go up every block. Every block will get harder than the previous, increasing the time even further than if it jumps every 2000 blocks. The long time in between will let the network catch up. If difficulty is changed more frequently, it will go up more than if we don't fork it before it goes down You did the math before, so I know you understand how far ahead we are. Surely you realize what I mean? I do understand what you mean, but I don't think you understand what I mean Simply changing the diff adjustment to every 1 blocks will not fix the problem. The diff algorithm itself also needs to be changed, and adjusted to take into consideration the current block height. Current diff algo looks at the current block height, versus the expected block height and adjusts the difficulty up or down based on how close we are to the expected block#. This algo is no good, BEN will never, ever correct itself using this algorithm (well, maybe eventually, but it will take YEARS). A new diff adjustment algorithm must be implemented, maybe one that does not look at the expected block height, but looks at the length of time it took to complete the previous X number of blocks and adjusts the diff accordingly (pretty sure this would work, but I'm just shooting from the hip here). Additionally, the diff adjustment period must also be reduced - otherwise, BEN will simply end up with the same problem again in a couple weeks. Max time at current hashrate will be 4 months to be where it should be, sped up with more miners that hop on. This problem will never happen once it catches up, because the network will not allow it to get that far ahead. It only happened because ASIC power wasn't accounted for in the initial difficulty This, once corrected, will NEVER happen again. It's impossible to get 5 times ahead of the network other than with a massive launch
|
|
|
64
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [BEN] Benjamins ◄ SHA-256 ►◄ NO HARD FORK INCOMING ►◄ Cryptsy ►◄ PAYSHA! ►
|
on: March 07, 2014, 05:35:21 PM
|
LOL, as if I even know where to start with the math. You are hilarious. Let me make it simple. I will use round numbers to show it easier. These numbers are made up for the sake of an example 1440 minutes in a day / 10 minute blocks = 144 blocks/day 144 * 30 (a month, to make it easy) = 4320, the block the network believes we should be on a month after release time We are on block 22k due to ASIC mining before the first adjustment. That means all the blocks between 4320-current are ahead of schedule, so the difficulty goes up to stall 2000 block adjustments will go up 25% 200 block adjustments will go up 25% I'm using 25%, but what the real % would be is the same for both adjustments since it is limited in how far it can adjust 25% increased 10 times with faster retargets will give you an exponentially higher difficulty than one jump, less often, with the same percentage increase, due to the adjustment limits. You would be going 100 + 25% then (100 + 25%) + 25% and so on for every adjustment
|
|
|
65
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [BEN] Benjamins ◄ SHA-256 ►◄ NO HARD FORK INCOMING ►◄ Cryptsy ►◄ PAYSHA! ►
|
on: March 07, 2014, 05:19:56 PM
|
We are 15k blocks ahead of schedule. This has nothing to do with wanting to hold what we already have. None of us have sold a single Benjamin, and in fact have used most of what we mined for giveaways on Reddit, Twitter, Cryptocointalk, and several other sites
Read what Igotspots quoted above. It explains our decision and gives reasons why a fork would make the situation worse. 10 minute block times are better for security, this is a known issue, as well as the KGW holes recently found, further strengthen our decision not to fork
Coins should not be created to serve the miners, but the consumers who will use them in the end. Benjamins will be one of the most secure blockchains once it has the hashpower to back up the numbers. Security and not losing coins or leaving them vulnerable to attack so vendors, exchanges, or traders don't lose payments is more important to us than making a few coin hopping miners happy. I'm sorry, but that's the truth. The ones that have stuck around mining since the beginning will enjoy having rarer-than-planned coins, but that was definitely not our intention
Sorry to be blunt but you are delusional. Appealing to miners is ABSOLUTELY REQUIRED. Without miners transactions cannot be confirmed. No sending coins, no receiving coins, no mining coins. I'm not saying BEN needs KGW. I'm not saying BEN has to decrease the block time (although, it would be my preference if it did). But the diff adjustment issue has to be addressed. Mark my words, the next diff adjustment will never, ever, ever arrive, BEN will never, ever, ever see anything close to 10-minute block times again if you do not fork this coin. I can't make it any more clear. If we make difficulty adjust faster, it will go up every block. Every block will get harder than the previous, increasing the time even further than if it jumps every 2000 blocks. The long time in between will let the network catch up. If difficulty is changed more frequently, it will go up more than if we don't fork it before it goes down You did the math before, so I know you understand how far ahead we are. Surely you realize what I mean? Why is it 2000 blocks or EVERY block? is there no where in the middle? Let's say it's 200 blocks then. The problem will still get 10 times worse than it is now. Every 200 blocks. Instead of every 2000. If you guys want to do the math, feel free. We have, it won't catch up any faster to the target block RIGHT NOW if we make difficulty adjust more often. It will make it take LONGER to catch up because blocks will be harder and harder. Leaving it like this locks that difficulty in for a period of time, rather than adjusting even higher every day (or week)
|
|
|
66
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [BEN] Benjamins ◄ SHA-256 ►◄ NO HARD FORK INCOMING ►◄ Cryptsy ►◄ PAYSHA! ►
|
on: March 07, 2014, 05:15:39 PM
|
We are 15k blocks ahead of schedule. This has nothing to do with wanting to hold what we already have. None of us have sold a single Benjamin, and in fact have used most of what we mined for giveaways on Reddit, Twitter, Cryptocointalk, and several other sites
Read what Igotspots quoted above. It explains our decision and gives reasons why a fork would make the situation worse. 10 minute block times are better for security, this is a known issue, as well as the KGW holes recently found, further strengthen our decision not to fork
Coins should not be created to serve the miners, but the consumers who will use them in the end. Benjamins will be one of the most secure blockchains once it has the hashpower to back up the numbers. Security and not losing coins or leaving them vulnerable to attack so vendors, exchanges, or traders don't lose payments is more important to us than making a few coin hopping miners happy. I'm sorry, but that's the truth. The ones that have stuck around mining since the beginning will enjoy having rarer-than-planned coins, but that was definitely not our intention
Sorry to be blunt but you are delusional. Appealing to miners is ABSOLUTELY REQUIRED. Without miners transactions cannot be confirmed. No sending coins, no receiving coins, no mining coins. I'm not saying BEN needs KGW. I'm not saying BEN has to decrease the block time (although, it would be my preference if it did). But the diff adjustment issue has to be addressed. Mark my words, the next diff adjustment will never, ever, ever arrive, BEN will never, ever, ever see anything close to 10-minute block times again if you do not fork this coin. I can't make it any more clear. If we make difficulty adjust faster, it will go up every block. Every block will get harder than the previous, increasing the time even further than if it jumps every 2000 blocks. The long time in between will let the network catch up. If difficulty is changed more frequently, it will go up more than if we don't fork it before it goes down You did the math before, so I know you understand how far ahead we are. Surely you realize what I mean?
|
|
|
67
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [BEN] Benjamins ◄ SHA-256 ►◄ NO HARD FORK INCOMING ►◄ Cryptsy ►◄ PAYSHA! ►
|
on: March 07, 2014, 05:04:50 PM
|
We are 15k blocks ahead of schedule. This has nothing to do with wanting to hold what we already have. None of us have sold a single Benjamin, and in fact have used most of what we mined for giveaways on Reddit, Twitter, Cryptocointalk, and several other sites
Read what Igotspots quoted above. It explains our decision and gives reasons why a fork would make the situation worse. 10 minute block times are better for security, this is a known issue, as well as the KGW holes recently found, further strengthen our decision not to fork
Coins should not be created to serve the miners, but the consumers who will use them in the end. Benjamins will be one of the most secure blockchains once it has the hashpower to back up the numbers. Security and not losing coins or leaving them vulnerable to attack so vendors, exchanges, or traders don't lose payments is more important to us than making a few coin hopping miners happy. I'm sorry, but that's the truth. The ones that have stuck around mining since the beginning will enjoy having rarer-than-planned coins, but that was definitely not our intention
|
|
|
69
|
Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] [BEN] Benjamins ◄ SHA-256 ►◄ NO HARD FORK INCOMING ►◄ Cryptsy ►◄ PAYSHA! ►
|
on: March 07, 2014, 04:57:54 AM
|
I've been busy and haven't checked in a couple days so I wasn't sure. I won't worry about it for now but I should probably lower my payout threshold so it doesn't take so long between payouts. Edit: The site is up now but the minimum payout is only able to be set to 100. Send him a message. All the pool ops listed in the OP are extremely helpful I have lowered the min payout to 1 BEN - sorry it's an MPOS default I just forgot to change These DDOS attacks are getting really annoying. They were really only attacking one pool but since the web front-end for all my pools is the same server they pretty much all went down. I'm going to scale out a bit with the pools so one getting attacked doesn't take everything down. I own two entire Class C address blocks no reason why I can't setup each pool with its own IP Told you he would respond soon! Thanks for paying attention to the miners
|
|
|
|