So 3/4 of an inch longer and it would go an inch deep?  #fml.. You're a little off on the math. Buerra, make sure you keep it a surprise  . I'm really excited to announce it when I can get actual pictures of it. It's pretty exciting though. -Fuse |
|
|
|
Are we having some calm before the storm?
Possibly  I know I've got something in the works that will be a first for the coin. If all goes as planned, there will be some awesome Xmas presents for some people this year. Here's a preview(I know you all like these mysterious hints):  -Fuse I got word back, and this project will be ready around mid-November. Here's another hint: They would go 0.0381944444444444 fathoms deep if they were 25400 microns longer. -Fuse |
|
|
|
Unfortunately, no. NOMP uses a wallet address as the user name, so you would need to pay your parents a visit  . Sorry, man. -Fuse |
|
|
|
|
Tagmining.com will be coming down this weekend for an update.
I've been running Tagmining for nearly a year now(domain registration fee is up on the 2nd), and I've decided that I'm just tired of MPOS. Being that I have run MPOS and NOMP side by side for a few months now on Tagmining and Criptoe, I can say without a doubt that I'm all-in on NOMP. NOMP is easier to use and it is more secure. It's also much more efficient in terms of server requirements, meaning mining will be substantially more reliable on the same server that the MPOS system is currently running on.
So this weekend, Tagmining will be moving to a NOMP frontend/backend. The change will be relatively quick- hopefully only the amount of time it takes to update the DNS records.
In preparation for this, please make sure you update your wallet address on Tagmining now so that when I force the payout to all wallets, you get paid. Once the server wallet goes down, it's down. If you don't have your wallet address set when the change happens, your coins are going into a margarita and beer fund for the Criptoe team.
I will post additional info on the time frame of the change-over later this week. However, the change will be made on Saturday, so make sure you're ready.
If you have any questions, drop me a line or post them here and I will respond as soon as I can.
Thanks,
Fuse
|
|
|
|
|
Please remove Criptoe.com from the pool list. No one mined on the pool, so I shut it down.
-Fuse
|
|
|
|
|
Any updates about the difficulty algorithm?
-Fuse
|
|
|
|
Has anybody ever thought about a NLG cloud mining service like zeushash or zenminer?.
The idea of a multipool that pays out in NLG has been brought up in the past. The problem with this though is that it would be the NLG clevermining to the other coins out there. While I could probably make a shit-ton of money on this, I couldn't in, good conscience, rape another coin for my own pockets. -Fuse |
|
|
|
+1, I'm even careful with buying orders so price doesn't rise too much... Although it's still hard keeping away from the candy store But lets face it, The price is not that important at the moment. I'm in longterm. Knowing what is to come, I think even Clevermining would stop dumping right now, but I don't think they can afford that yet... Imagine what would happen if Clever didn't have the coins to dump. It's not just the difficulty swings..... -Fuse |
|
|
|
|
Criptoe is a NOMP based pool and HCM is a MPOS based pool. Both have their advantages and disadvantages. I have run both types of pools, as well as their predecessor mmcFE, over the last year+. To put it in the simplest terms:
NOMP is more secure, but less informative. It's basically a park your miner and walk away system. You aren't getting all the bells and whistles charts and darts you get with MPOS, but you don't need a login, and your coins are sent immediately after confirming. No coins sit on the server, and therefor, they can't be lost to attack or op scams(not saying HCM scams, just saying in general).
MPOS is more informative, but more prone to vulnerabilities depending on whether the op knows what their doing. Stratum and DB vulnerabilities are higher here, but can be mitigated by using NOMP as the backend to the MPOS frontend. However, you need to have an account in most cases, which are prone to attack, and coin tends to sit on the server unclaimed or unpaid if you don't set up your payout properly.
Both systems work. It's really up to you to decide what works best for you. I will never tell people to mine on Criptoe just because I want them to. I will ask for help with hashrate if we're struggling, but I will never tell people they should or shouldn't mine with us.
It's your rig, your money, your time... do what makes you the most coin.
-Fuse
|
|
|
|
Clevermining didn't stop. Maybe they reduced their hash rate towards NLG, but the increase in hashing at guldenpool is probably the big difference maker.
Nah, man. Criptoe is tearing up all those blocks -Fuse |
|
|
|
The danger of putting too much weight on the latest block:
Lets put it to an extreme and you use only the last 1 or 2 blocks. A pool can easy cherry pick those blocks, leave for 2 blocks, come back... and repeat. The diff would jump up and down like crazy.
So it is important to fine tune the settings and find a good path between instant reaction and smoothing the diff changes.
I would never recommend a 1-2 block focus. That would be crazypants thinking. I seriously think 6 is a nice even number, and it falls in line with about the average number of blocks that Clever rapes at any given time. You put more focus on those 6 blocks, instead of 24 evenly, and you'll see a big change in Clever's ability to own 90% of the network. Of course, GJ has some code on the table right now. I guess we'll all just need to wait to see what it looks like before we try to push one way or another. -Fuse |
|
|
|
DGW3 was developed at a time and for a network that had far smaller spikes than we see today. I still think what we need is a faster reaction to the hash rate spikes and drops we see. The more time it takes to settle in to the desired diff for the actual hash rate the more time we give pools to take advantage of it and normal miners will suffer after a drop and the time it takes to bring the diff back down. The idea I wrote about a few pages back and some others picked up too is to give the newer blocks in the interval a higher weight than the older ones. Lets say we split the 24 blocks into 4 parts when calculating nActualTimespan. older ---> newer part1, part2, part3, part4 (each part 6 blocks) a more conservative approach: part1: block times * 1 (counted like 06) part2: block times * 2 (counted like 12) part3: block times * 3 (counted like 18) part4: block times * 4 (counted like 24) sum / 60 = weighted average weighted average * 24 = nActualTimespanWeighted a more agressive approach: part1: block times * 2^0 (=block times * 1) (counted like 06) part2: block times * 2^1 (=block times * 2) (counted like 12) part3: block times * 2^2 (=block times * 4) (counted like 24) part4: block times * 2^3 (=block times *  (counted like 48) sum / 90 = weighted average weighted average * 24 = nActualTimespanWeighted Splitting it into more parts would make it react even faster, both on the way up and on the way down. Giving the newest i.e 1 or 2 blocks additional weight can even speed it up more; giving the very latest blocks too much weight could lead to an exploit for an attack. It should be an easy mod to our DGW3 diff algo with lower risk than a completely new algo. I think this is getting more complicated than it needs to be. If we're looking at a weighted average, like I suggested, take the first 6 blocks and then the next 18 counted as one block. I don't see how additional weight on the latest blocks would allow for an exploit. Care to elaborate? I do agree though that the changes need to happen faster, much like I originally pointed out here: https://bitcointalk.org/index.php?topic=554412.msg8992812;topicseen#msg8992812. The POT chart there is a solid representation of what we should be trying to achieve. -Fuse |
|
|
|
Accepted payment methods?
BTC, LTC, NLG, maybe other coins if they peak my interest. No fiat. -Fuse |
|
|
|
|
Coming back to this, as there has been some traction lately for these units in the forums.
Just checking back in to see if anyone wants to make a reasonable offer on 20 units.
-Fuse
|
|
|
|
|
For the sake of fact preservation, I've saved his "limp dick" bill image to another image hosting site. That way he can't delete it and say it never happened.
And on that note, I'm locking the thread.
-Fuse
|
|
|
|
I think you misunderstand. The diff will rise max with a factor of 1.2 between blocks. So if the diff is 300, the next block can be max 360.
I definitely misread your text lol This is a decent approach. As long as we don't from 250 to 750 in a single jump, you should see better block times. Additionally, as the difficulty drops back down, we'll get to the point where we're riding a sweet spot where it's not profitable for the miners doing short-term calculations for profit(aka multis). -Fuse |
|
|
|
I think we're on a good path here! I've actually started implementing a new algorithm, from scratch. It performs faster re-adjustment, limited to 1.2 or 0.8 difficulty change between individual blocks. But it also limits the difficulty change to 3.0 or 0.33 compared to the last 120 blocks difficulty average. This means that the diff can rise ~3.0 times in 6 blocks, and it can fall to ~0.33 times in 5 blocks. In the linked formula's the impact of the new blocks themselves are not calculated in the 120 blocks average. The idea behind this is that it will be able to handle large joins and leaves, but won't be tricked into settling on a high difficulty too fast. Thoughts? I'll share the code when I'm happy with initial implementation. I think you're shooting too high with a 3X increase. We'll have the same results we have now where it jumps too high for normal miners, and we get stuck. The drop back down is fine, but the jump up in difficulty should be smaller IMO. As 24Kilo always tells me, we don't need to reinvent the wheel. We just need to make sure our current wheel is round. -Fuse |
|
|
|
I knew that the blocks were based on calculated averages of the past. I'm a bonehead, sometimes. Haha. Instead of cancelling the block as I described, why can't the network start to drop the diff if the last block was found, for example, an hour ago? Have a decaying diff inside the time between each block instead of varying diff per block and put a limit on how long the maximum time in between blocks for the decay math to base itself from.
You still need a block to be found to trigger the change. When a block is found, the network broadcasts the next block's difficulty. The difficulty algorithm should takes into account the time between blocks and adjust the difficulty accordingly for the next block. But without a block being solved to send out a new record of the next block's difficulty, you can't find out what the difficulty is going to be. I suspect any change that would do something like a "difficulty ping" would not only need to write these changes to the blockchain somehow(like POS blocks). Not only would it bloat the blockchain, but it would also allow additional avenues for time-based attacks. Essentially all an attacker would need to do is set their clocks forward on numerous nodes to simulate a larger time gap. -Fuse Edit:Beside all these solutions I still think the problem is the way DGW3 is implemented. It just does not react the way it should and that has nothing to do with being designed for... Because its a counting algo based on the last 24 blocks. One thing that also keeps me busy is the fact that KGW did not work properly either so maybe the solution is at some totally other place in the code. You sometimes see the same strange behaviour when variables are used outside the memory space and overwritten by some other procedure
DGW3 was not modified, except for some code comments and alignment. It looks like DGW3 is calculating correctly, the problem is that it was not created for jump pools at this scale. I have been thinking about increasing the number of blocks into calculation (currently 24). But I'm affraid that it will only result in multipools getting more blocks before the diff spikes. What do you think?
No, what I meant is the fact that two seperate dampening solutions that should work pretty well jump around like crazy. That made me wonder, maybe its not the KGW or DGW code but something that precedes or supercedes it. You maybe could ask Rijk what exactly was done about the KGW problem back in April, because then KGW went haywire. It's just a wild guess, but it's strange that we have more problems with those jump pool than other coins.
I agree, it could be something else. Something not related to KGW or DGW. But when doing the math (and I'm sure you've done it too) it makes sense that it's simply DGW not being able to handle the huge amount of hash/sec
This is exactly why you need to reduce the number of blocks taken into consideration. IMO, a weighted average is the way to go. You want to reduce the amount of blocks the multis can take. Increasing the count evens the difficulty graph out over time, but it doesn't solve the issue of network jumping. You need to limit the amount of blocks they can mine by quickly ramping up difficulty, but not overshooting the magic number. Again, less change more often. I believe a weighted average would do this. The other option is digishield, but that is another very serious fork. -Fuse |
|
|
|
I'm no coder, but I can read and understand it. If the solution is a weighted average, the section of code we would need to adjust would be the following snippet: // loop over the past n blocks, where n == PastBlocksMax
for (unsigned int i = 1; BlockReading && BlockReading->nHeight > 0; i++) {
if (PastBlocksMax > 0 && i > PastBlocksMax) { break; }
CountBlocks++;
// Calculate average difficulty based on the blocks we iterate over in this for loop
if(CountBlocks <= PastBlocksMin) {
if (CountBlocks == 1) { PastDifficultyAverage.SetCompact(BlockReading->nBits); }
else { PastDifficultyAverage = ((PastDifficultyAveragePrev * CountBlocks)+(CBigNum().SetCompact(BlockReading->nBits))) / (CountBlocks+1); }
PastDifficultyAveragePrev = PastDifficultyAverage;
}
// If this is the second iteration (LastBlockTime was set)
if(LastBlockTime > 0){
// Calculate time difference between previous block and current block
int64 Diff = (LastBlockTime - BlockReading->GetBlockTime());
// Increment the actual timespan
nActualTimespan += Diff;
}
// Set LasBlockTime to the block time for the block in current iteration
LastBlockTime = BlockReading->GetBlockTime();
if (BlockReading->pprev == NULL) { assert(BlockReading); break; }
BlockReading = BlockReading->pprev;
} Instead of cycling through all 24 blocks, we need to cycle through the first 6(or whatever number, lower being better in my mind), and then cycle through the next 18 and count those as 1 lesser weighted block. I ran this theory through an excel spreadsheet, and the weighted average reacts faster and carries a slightly higher difficulty than a generic average. Try it yourself and you'll see what I mean. Of course, am I'm now starting to wonder if I'm even calculating the correct values, and whether or not I should be looking at time instead. Can someone steer me in the right direction? -Fuse |
|
|
|
Thinking a little outside the box here:
How about if the network senses an hour or however long has passed, then automatically drops the diff of the current block by voiding/canceling the current big diff block and releasing a new small diff block? Is there a reason the network can't cancel/re-submit the diff or the current block being mined? Just ideas to keep ppl thinking, food for thought, I don't know if it's even possible. Blockchain and code are capable of so many things, figured I'd ask.
I might not be 100% correct on this, but I don't think this would be possible. The code works around submitted blocks. So you need to have blocks created and submitted to the chain to have the numbers calculated against. I might be possible if you had something like POS always generating blocks separately from POW, but that's a whole other can of worms. Frankly, implementing something like that is a huge undertaking. -Fuse |
|
|
|
|
Show Posts
