NA

[gielbier]

Is there a paperwallet for NLG ? If not, would anyone care if I made one?

[1715032767]

1715032767

[1715032767]

1715032767

[bram_vnl]

Is there a paperwallet for NLG ? If not, would anyone care if I made one?

http://walletgenerator.net/?currency=guldencoin

[mainpmf]

Is there a paperwallet for NLG ? If not, would anyone care if I made one?

http://walletgenerator.net/?currency=guldencoin

Silly question,
Suppose I create a paper wallet with some guldens inside, later on how do I export that amount into Guldencoin-Qt for instance?

[gielbier]

importprivkey ofc.

Is there a paperwallet for NLG ? If not, would anyone care if I made one?

http://walletgenerator.net/?currency=guldencoin

Nah that would probably work fine, but something more guldencoin related artwise. So I don't have to guess which paperwallet is which.
(btw I did the banksycoin paperwallet; https://dl.dropboxusercontent.com/u/27041159/Bansky-25.html )

[KenChanYu]

importprivkey ofc.

Sounds like a good idea, would you create a tutorial on this? There looks like a lot of Dutch people buying NLG that are new to cryptos so they will need help understanding paperwallet.

[gielbier]

importprivkey ofc.

Sounds like a good idea, would you create a tutorial on this? There looks like a lot of Dutch people buying NLG that are new to cryptos so they will need help understanding paperwallet.

To be honest, it's not hard. in every xxcoin-qt you got the console. and if you type importprivkey "YOURPRIVATEKEY" "label", it will just show up in your wallet . (some qt's are a bit annoying, and you need to do it twice to make it pop up)

[0btc]

My p2pool node at http://gulden.p2p.0x0a.nl:27100 hasn't been doing too well (by which I mean, no miners). In order to make it a bit more appealing, I acquired the domain guldenpool.nl - so you can now reach it at http://guldenpool.nl:27100. I've also lowered the fee from 0.9% to 0.5%. Perhaps it doesn't change much about how well p2pool is currently doing, but if the annoying domain name was the one thing holding you back - a warm welcome to you  !

Also, it would be great if someone could set up another p2pool node (or multiple someones & nodes even). Spekske's commit made it into Rav3nPL's p2pool repository, so you can now get it from https://github.com/Rav3nPL/p2pool-rav as well as https://github.com/Spekske/p2pool-spek.

http://guldenpool.nl:27100/static/ gives a loop atm

Ouch, made a stupid mistake.. Should be good now!

[/GeertJohan]

Hello all,

I haven't posted a message on here over the past few weeks because I've been very busy with the difficulty problem.
Once it was discovered that the jump pool might be CleverMining I got in contact with Terk to discuss the problem.
He reduced the amount of hashrate for NLG a few times so it won't cause multiple hour blocktimes anymore.
Fuse also contacted Terk, and as you all know by now the hashrate used by CleverMining for NLG is now 1/12th of the normal hashrate they would use.

I want to thank Terk and CleverMining again for their cooperation and help.

However, CleverMining and other jump mining pools won't hold back forever, especially not when the prices rise.
So we need a solution.

I dug into the code.. I read the digishield and DGW1,2,3 algorithms and looked at some others.
Digishield looks a lot like the original diff adjustment algorithm. But it readjusts per block and rises diff slower, while it lowers diff faster.
This makes it possible for a jump pool to mine a lot of blocks, and afterwards the diff drops faster again.
DGW1 and 2 look a lot like DGW3. DGW3 simply has some improvements over the first two.
DGW also adjusts the difficulty per block. But it rises the diff just as fast as it lowers it.
But it calculates the new diff based on the average diffs for the past x blocks. This means the diff can rise fast when a lot of blocks are mined in a short amount of time, but it also levels back pretty quick afterwards.
I believe that DGW3 is our best option. We are now making plans for a mandatory update including this new algorithm. We will have more information available before the end of tomorrow (sun 21th).

Thanks,
Geert-Johan

[BioMike]

@/GeertJohan, did you also consider the BTM solution to this problem? Why was it rejected? To me this seemed a very elegant solution to the problem (which should IMHO also be future-proof).

Ref: https://bitcointalk.org/index.php?topic=554412.msg8870691#msg8870691

[/GeertJohan]

@/GeertJohan, did you also consider the BTM solution to this problem? Why was it rejected? To me this seemed a very elegant solution to the problem (which should IMHO also be future-proof).

Ref: https://bitcointalk.org/index.php?topic=554412.msg8870691#msg8870691

Yes we are still thinking about the BTM solution of making the required confirmations for generated coins higher.
However, I think it can be bypassed by any jump pool fairly easy. The pool simply creates a buffer of say 100K NLG and places this at the exchange. When the pool decides to mine blocks, the buffer is being sold. So if the pool gets 14 blocks, then 14K NLG is sold at the exchange. When the 14K mined coins are completely confirmed (which will take longer than normal), the coins are moved to the buffer at the exchange, so the buffer is back at 100K NLG again.
I think this technique might actually be used already, it makes the calculations by a jump pool very accurate because mined coins can immediately be sold. The buffer itself is a one time investment that can eventually be sold again.

So when the generated coins maturity confirmations is changed from 120 to 240, that would simply mean that the jump pool requires a buffer of twice the size to accommodate for the confirmation time..
So like BTM, it would require a huge confirmation time (maturity), like 480 (20 hours), 720 (30 hours), 960 (40 hours) or maybe even 1152(48 hours)... Each one requiring a larger buffer to effectively calculate the profitability for mining and selling coins right away.. And even with a small buffer it would work, it would just mean that the miner can't come back every hour and has to wait for the buffer to fill for a day or two..
The downside is that our dedicated miners also have to wait longer before their coins are matured. So I would very much like to hear how everyone thinks about this. Especially if you are a miner (dedicated or jump), please let us know how you feel about a higher maturity confirmation count.

[thsminer]

@/GeertJohan, did you also consider the BTM solution to this problem? Why was it rejected? To me this seemed a very elegant solution to the problem (which should IMHO also be future-proof).

Ref: https://bitcointalk.org/index.php?topic=554412.msg8870691#msg8870691

Yes we are still thinking about the BTM solution of making the required confirmations for generated coins higher.
However, I think it can be bypassed by any jump pool fairly easy. The pool simply creates a buffer of say 100K NLG and places this at the exchange. When the pool decides to mine blocks, the buffer is being sold. So if the pool gets 14 blocks, then 14K NLG is sold at the exchange. When the 14K mined coins are completely confirmed (which will take longer than normal), the coins are moved to the buffer at the exchange, so the buffer is back at 100K NLG again.
I think this technique might actually be used already, it makes the calculations by a jump pool very accurate because mined coins can immediately be sold. The buffer itself is a one time investment that can eventually be sold again.

So when the generated coins maturity confirmations is changed from 120 to 240, that would simply mean that the jump pool requires a buffer of twice the size to accommodate for the confirmation time..
So like BTM, it would require a huge confirmation time (maturity), like 480 (20 hours), 720 (30 hours), 960 (40 hours) or maybe even 1152(48 hours)... Each one requiring a larger buffer to effectively calculate the profitability for mining and selling coins right away.. And even with a small buffer it would work, it would just mean that the miner can't come back every hour and has to wait for the buffer to fill for a day or two..
The downside is that our dedicated miners also have to wait longer before their coins are matured. So I would very much like to hear how everyone thinks about this. Especially if you are a miner (dedicated or jump), please let us know how you feel about a higher maturity confirmation count.

To add my 2 cents, I think that if a solution is implemented which needs a hardfork it has to be a futureproof solution of some sort and not another algo for an old problem.
The BTM solution is very nice and even if it takes an huge confirmation time to solve the problem it's also in the benefit of the miners. Right now the common miners and pools are put behind and only get the hard blocks. Thats a very undesirable situation not to talk about the fact one pool can dictate the coin by mining 90% of the total. Another solution to the problem can be rejecting blocks with relatively low blocktimes. This way it's no use to add a lot of hashrate because those blocks will be rejected. Drawback is the normal miners also get a rejected fast block once in a while, but in the long run they benefit because the big pools have less advantage. An variant could be an algo that prevents two fast blocks in a row.

[BioMike]

I don't mind/care the dumping of the coins on exchanges (or the financials of the big jumping pools), what matters is how the pool reacts to this change in respect of difficulty adjustments. If we have a big pool jumping in and out less frequently, this means more blocks for our dedicated miners (and maybe longer stretches of lower difficulty).

I've got difficulties trying to visualize the effect of this change on the network difficulty (and your bypass method doesn't make it easier).

[/GeertJohan]

@/GeertJohan, did you also consider the BTM solution to this problem? Why was it rejected? To me this seemed a very elegant solution to the problem (which should IMHO also be future-proof).

Ref: https://bitcointalk.org/index.php?topic=554412.msg8870691#msg8870691

Yes we are still thinking about the BTM solution of making the required confirmations for generated coins higher.
However, I think it can be bypassed by any jump pool fairly easy. The pool simply creates a buffer of say 100K NLG and places this at the exchange. When the pool decides to mine blocks, the buffer is being sold. So if the pool gets 14 blocks, then 14K NLG is sold at the exchange. When the 14K mined coins are completely confirmed (which will take longer than normal), the coins are moved to the buffer at the exchange, so the buffer is back at 100K NLG again.
I think this technique might actually be used already, it makes the calculations by a jump pool very accurate because mined coins can immediately be sold. The buffer itself is a one time investment that can eventually be sold again.

So when the generated coins maturity confirmations is changed from 120 to 240, that would simply mean that the jump pool requires a buffer of twice the size to accommodate for the confirmation time..
So like BTM, it would require a huge confirmation time (maturity), like 480 (20 hours), 720 (30 hours), 960 (40 hours) or maybe even 1152(48 hours)... Each one requiring a larger buffer to effectively calculate the profitability for mining and selling coins right away.. And even with a small buffer it would work, it would just mean that the miner can't come back every hour and has to wait for the buffer to fill for a day or two..
The downside is that our dedicated miners also have to wait longer before their coins are matured. So I would very much like to hear how everyone thinks about this. Especially if you are a miner (dedicated or jump), please let us know how you feel about a higher maturity confirmation count.

To add my 2 cents, I think that if a solution is implemented which needs a hardfork it has to be a futureproof solution of some sort and not another algo for an old problem.
The BTM solution is very nice and even if it takes an huge confirmation time to solve the problem it's also in the benefit of the miners. Right now the common miners and pools are put behind and only get the hard blocks. Thats a very undesirable situation not to talk about the fact one pool can dictate the coin by mining 90% of the total. Another solution to the problem can be rejecting blocks with relatively low blocktimes. This way it's no use to add a lot of hashrate because those blocks will be rejected. Drawback is the normal miners also get a rejected fast block once in a while, but in the long run they benefit because the big pools have less advantage. An variant could be an algo that prevents two fast blocks in a row.

I have also thought about that yes: rejecting blocks that are mined too soon. However, a miner could then mine the block in advance and broadcast it when the time is right.
So lets say the algorithm denies blocks with a timestamp within 20 seconds of the previous block. A jump pool operator could easily write some software to work arround this. The pool would generate 20 blocks in advance, each with a timestamp that is 20 seconds in the future relative to the previous block. Then the pool op would simply broadcast each block at exactly the right times. The pool's chain would automatically win as the normal miners simply can't generate blocks that fast. (edit: and they aren't coordinated to mine blocks in advance)
Please correct me if I'm wrong or if I'm overlooking something.

[BioMike]

Personally, I think rejecting otherwise valid blocks is a no-go area. That is not in the benefit of anybody.

[thsminer]

I have also thought about that yes: rejecting blocks that are mined too soon. However, a miner could then mine the block in advance and broadcast it when the time is right.
So lets say the algorithm denies blocks with a timestamp within 20 seconds of the previous block. A jump pool operator could easily write some software to work arround this. The pool would generate 20 blocks in advance, each with a timestamp that is 20 seconds in the future relative to the previous block. Then the pool op would simply broadcast each block at exactly the right times. The pool's chain would automatically win as the normal miners simply can't generate blocks that fast. (edit: and they aren't coordinated to mine blocks in advance)
Please correct me if I'm wrong or if I'm overlooking something.

Yep, that could be done. However, asume some pool writes software to do this, they better use that technique to do some sort of spend attack.
Also this would be highly theoretical because if he mined 20 blocks his chain would only win if it has the most work done and I doubt if this is the case. On the other hand he has this oportunity right now also (mining blocks in advance and send them in at good times to keep the diff within limits). So not using something because it possibly can be manipulated is an awkward logic.

[thsminer]

Personally, I think rejecting otherwise valid blocks is a no-go area. That is not in the benefit of anybody.

Thats how you look at the problem. Orphan blocks are also valid blocks... and the only ones with very low submissions are pools with guerilla techniques.

Edit: The current diff system punishes you also when you are mining fast... In fact there are two problems to fix; hopping very high hashrate and concentration of hashrate.   

[BioMike]

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

[Bluestreet]

I am highly impressed with the discussion taking place here. The dev definitely has looked at all angles and the miners are coming back with more suggestions. Really I feel Guldencoin is in great hands here!

[thsminer]

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

This would induce a problem when the diff rises organically. The confirmations would lower and lower over time.

[BioMike]

Just some brainstorming... Is it possible to have a maturation time dependent on the difficulty? So, lower difficulty => longer maturation time for that block. High difficulty => short maturation time. (This could induce some extra fluctuations on the market price though).

This would induce a problem when the diff rises organically. The confirmations would lower and lower over time.

Not if you take the average diff of x blocks and use the deviation from that to calculate a difference from a base maturation time.