Topic: NA - page 409. (Read 893613 times)

Time based block rewards seems like a good solution if there are no exploits of course.

But I was thinking can block maturity also be dynamic in the way that if clevermining jumps in diff or hashrate goes up next block has a much longer maturity time?

I don't fully understand coin dynamics just an idea

The target for the block time is 2.5 min
Reject blocks of lets say less than 30 sec or 1 min block time (could even be by same IP). That would take away a reasonable part of the advantage for very high hash power jumping in at low diff.


Dividing it by 4 to bring it back closer to the default block time sounds better.


Anyway, here is what I was thinking about to modify our DGW3 for faster adaption to hash rate changes:
Either take the actual hash rate reading into account (was reading weeks back that a coin did this but can't find it again) or try to predict it by giving the blocks in the interval different weight for the calculation.
The first (oldest) block in the interval gets the lowest weight and increase it to the last (newest) block with the highest weight. Maybe double or triple the weight from one block to the next, so the latest blocks are getting far more important for the next diff.
This way it would react much faster to heavy hash rate changes and would not have a big impact on smaller variations.
I still think the very short blocks should get rejected too; less than 40% of the default time is too short.

I'm still in under the opinion that DGW3 would work with tweaked values.  What needs to happen is the difficulty spikes up almost instantly when clever hits the chain.  Going 10 or so blocks at 10 seconds or less a block is no bueno.  It should pick up on the second, or even third, block and jump the difficulty immediately.  The post I made here explains what I mean visually via the difficulty charts of NLG and POT: https://bitcointalksearch.org/topic/m.8992812.  POT uses digishield, but I suspect you could tweak DGW3 to emulate it's behavior.

-Fuse

Hi all,

Thanks everyone for taking part in this discussion! It's very important that we discuss and work together towards a solution!

Lower price
I agree with ny2cafuse: when the price drops there will still be profitable blocks (the low diff ones) that are going to be mined by the multipools. I also agree with strataghyst: price manipulation is a bad idea in general. Furthermore, the price must go up at one point.. So even if a lower price would fix, it won't be a permanent solution.

Different diff readjusment
I agree with thsminer: changing the diff readjustment is not a complete solution. I should've been more verbose in my earlier post. I think we can change the diff readjustment more so it fits better with Guldencoin's specs and performs better. But it won't be a complete solution. The scale and speed of the multipools is simply too large relative to our dedicated miners.

Longer coin maturity
If I was going to set up a multi-pool, I would start by mining 20 blocks; 20.000 NLG. Lets call it a "buffer". I would put those buffer coins in the exchange wallet. Then I would write software that watches the exchange rate and coin difficulty to calculate the profitability. When the coin is profitable, the software directs the miners to start mining x blocks until the diff is so high that it isn't profitable anymore. Say 10 blocks are mined, the software would directly sell 10.000 NLG from the buffer on the exchange. Once the 10 mined blocks have matured, those coins are sent to the buffer (exchange wallet). Then the whole process starts over again.
I don't know for sure if clevermining works this way, but it's trivial to implement. Therefore, increasing the coin maturity duration only requires multi-pools to have a larger buffer so they can bridge the maturity time. At the same time, a long coin maturity is a huge downside for independent and smaller miners.. So I'm a bit divided on this one.. It might help, but only as long as multi-pools haven't worked around it yet.. And it has downsides for small independent miners, the ones that are dedicated to our network.

Rejecting blocks
This sounds like a good idea, but I'm afraid it can be bypassed fairly easy. A multi-pool could implement some software to premine blocks with future timestamps, and broadcast those future blocks when the time is right (while the actual mining machines are working on different blocks on a different coin). So in the end, it will still result in multi-pools getting a lot of blocks.

Adjustment between blocks
I've been thinking about changing the diff between blocks. The problem is that a diff based on time is prone to errors and would likely cause chain splits when different miners and nodes are not in sync (clock time). This can be solved by doing a diff change only once every -lets say- 10 minutes. The diff is halved when 10 minutes have past without a block. Because machine times are not always in sync, it needs a graceful period of -lets say- 1 minute before that time. This means nodes can be out of sync for max 1 minute. This actually still a short amount of time, I've seen lots of machines with a wrong time greater than 1 minute. But if you were to take a larger graceful margin, people might try to take advance of that in the form of exploits (halving diff after 9 minutes instead of 10, and hoping for all other nodes to accept it because it's in the grace margin).
I think this might work as a fall back, when a block is 'stuck' for a long time. It does not prevent long blocks in any way.. I think it could be beneficial when the halvation time is pretty high (30 minutes or more, instead of 10), and a grace period being 2 or even 3 minutes.
The bitcoin/guldencoin software was never created with this feature in mind, so it could take a lot of efforts to create this, while it does not directly solve our problem.

Time based block reward
When the block reward is based on the seconds that have past since the previous block, it will discourage multi pools to mine a lot of blocks at once, as it won't be profitable since the reward will be low.
For example: 150 seconds since last block would reward 1000 NLG and 15 seconds would reward 100 NLG.
As pointed out by ny2cafuse: the downside is that "lucky" blocks will have a smaller reward. On the other side, we could change the max block reward to 2000 NLG (rewarded at a block being 300 seconds after the previous block). This means that in the end exactly 1000 NLG per 150 seconds would be generated, regardless of "lucky" or "bad-luck" blocks or jumping pools. To me it's still unclear if there are exploits with this approach (for instance: invalid block times to receive more coins).


I'd love to hear everyones thoughts and feedback.
As mentioned before: Guldencoin is a long term project. It's important that we think about decisions that are being made and achieve good consensus.

Cheers!
Geert-Johan Riemer

You should listen to Alex Jones, he's the guy that knows everything about that.

I know it's totally off-topic in a time of serious discussion, but I've got a doozy of a conspiracy theory I came up with the other day regarding gold, BTC, and China's grand scheme to destroy the US economy.  I'll have to tell it to you some time .

-Fuse

Not that I know of But hey, I do like conspiracy theories

Could it be that multipools are sponsored by the btc-richlist? They should embrace NLG instead of being destructive. If it stays this way, better cut them out indeed if possible, I agree.

I literally asked to stop all together when when we first did the DGW3 implementation.  He said he "has an obligation to his miners", and that the devs would need to fix the issue instead of him stopping mining.  He ramped down mining, and you can see the result of that over the last month with his 70-90% network ownership.  Keep an eye on the numbers.  I'm sure you'll see the same after this decrease in hashrate.

IMO, whatever solution is put in place needs to be a solution to completely cut multipools out of the game.  We shouldn't be trying to cater to the multipools needs.  Cut clever out of the game and say "we have an obligation to our community".

-Fuse

Ask Terk to totally stop this mulipoolmining on NLG. It is in best interest for cryptoland in general to support NLG and leave NLG with dedicated miners. There are other shitcoins to profit from. I really don't understand why Clevermining is doing this. 

Edit: Simultane post, I see now

Terk just got back to me on PM, Clevermining is now using 50% hashrate on NLG. I hope this will give us a bit more stability while we work on a solution.

no backupoplader.nl is not 55 already on my site http://www.guldencoinlinks.nl/betalen.html

Nice one Shopem! Number 55  

Don't worry about the price so much. This will happen naturally when no solution is there. Price manipulation is never a good idea in my opinion.

This isn't a fix.

Price drops, miners drop, difficulty drops.  Difficulty vs price ratio would be the same and the multis would continue to mine.  Then the price goes back up and the multis continue to mine.  Price manipulation will never fix a coin.  In fact, price should be the last thing people think about in terms of working coin dynamics.

-Fuse

I know this might sound like a crazy idea but why don't we let the price fall to around 300 and then the ratio between dedicated miners and multipools will decrease. Then after it's fixed we can start buying again? This would require a lot of collaboration I know but if everyone just removes there buy orders and let the price drop, the multipools will sell out at any price.

It's ok.  He's most likely a profit miner, not a supporter.

-Fuse

Nice support from the communitym, peeps, have some patience....

Johndec2 is a member of the Criptoe team.  I'll catch him in chat and get some insight into this.

I can see the disparity though, as the difficulty algorithm there isn't doing what it needs to do.  BTM isn't a difficulty algorithm, and can't handle highs and lows.  DGW3 can when properly tuned.  Using a straight difficulty algo like LTC/BTC with BTM = no bueno.  Using it with a more advanced difficulty algo would most likely be just fine.

-Fuse

From the ANN of BTM: https://bitcointalksearch.org/topic/m.9253396:

Quote from: johndec2 on October 19, 2014, 11:58:36 AM
Buck. It's not xhash's fault.  The coins take 720 blocks to confirm and this current round of 720 has taken a few weeks.  Everybody is in the same boat.  In a day or so we will move to the next round of 720, the diff will drop and the whales and multipools will move in and 720 blocks will disappear in a few hours... Then everyone will sit back and wait for the painful process to repeat.