i figure 3-5 days before the networks starts flowing freely again.
there is quite a backlog of POS blocks trying to squeeze through the little KED network's CPUs. and since there is no effective way to cancel a current minting POS block (that i know of).. just gotta wait till you're CPU is done ....then your reservebalance function should kick in.
once the network grows and there are more transactions between addresses...this should not be an issue?
cheers
Topic: [ANN] StarTrek insipred coins =) and mining links (Low Diff) Nice Bounties! - page 14. (Read 60763 times)
October 18, 2013, 02:02:27 PM
October 18, 2013, 01:31:12 PM
Q: So i understand that too many POS blocks are clogging the system, If i want to help unclog the network how do i prevent my client from generating POS blocks and making the problem worse?
A: Glad you asked!
Method 1) Move your oldest coins(older than 25 days) to a new wallet address that you control. This will renew the coin-age factor and reset your coins' Available_for_minting clock.
Method 2) Make your current balance of coins unavailable for POS minting while your client is turned on, by using 'reservedbalance' function in your darsek.conf file. Restart your client. example:
in the example above...the client will try to keep 1000 ked from being used in POS generation. I put 'reservebalance=1000000' to effectively turn off
all POS generation on my client......at least until i get 1 million ked.
I believe if enough of the users/clients out there do this then the network will unclog again and we wont have to use any other more drastic measures, such as a re-issuance or recoding.
I recommend at least method 2.
cheers.
A: Glad you asked!
Method 1) Move your oldest coins(older than 25 days) to a new wallet address that you control. This will renew the coin-age factor and reset your coins' Available_for_minting clock.
Method 2) Make your current balance of coins unavailable for POS minting while your client is turned on, by using 'reservedbalance' function in your darsek.conf file. Restart your client. example:
Code:
reservebalance=1000.00
in the example above...the client will try to keep 1000 ked from being used in POS generation. I put 'reservebalance=1000000' to effectively turn off
all POS generation on my client......at least until i get 1 million ked.
I believe if enough of the users/clients out there do this then the network will unclog again and we wont have to use any other more drastic measures, such as a re-issuance or recoding.
I recommend at least method 2.
cheers.
Method two worked for me! Client is running smoothly and I just started mining again
We'll see if it actually works! 
October 18, 2013, 01:03:21 PM
I believe it only happened to PoS coins that are not on an exchange before PoS kicks in.
Once it is on an exchange, people will start moving coins and less PoS blocks are generated.
Once it is on an exchange, people will start moving coins and less PoS blocks are generated.
October 18, 2013, 12:59:17 PM
Q: So i understand that too many POS blocks are clogging the system, If i want to help unclog the network how do i prevent my client from generating POS blocks and making the problem worse?
A: Glad you asked!
Method 1) Move your oldest coins(older than 25 days) to a new wallet address that you control. This will renew the coin-age factor and reset your coins' Available_for_minting clock.
Method 2) Make your current balance of coins unavailable for POS minting while your client is turned on, by using 'reservedbalance' function in your darsek.conf file. Restart your client. example:
in the example above...the client will try to keep 1000 ked from being used in POS generation. I put 'reservebalance=1000000' to effectively turn off
all POS generation on my client......at least until i get 1 million ked.
I believe if enough of the users/clients out there do this then the network will unclog again and we wont have to use any other more drastic measures, such as a re-issuance or recoding.
I recommend at least method 2 with 'reservebalance=100000.00' for a 100k reserve.
cheers.
A: Glad you asked!
Method 1) Move your oldest coins(older than 25 days) to a new wallet address that you control. This will renew the coin-age factor and reset your coins' Available_for_minting clock.
Method 2) Make your current balance of coins unavailable for POS minting while your client is turned on, by using 'reservedbalance' function in your darsek.conf file. Restart your client. example:
Code:
reservebalance=1000.00
in the example above...the client will try to keep 1000 ked from being used in POS generation. I put 'reservebalance=1000000' to effectively turn off
all POS generation on my client......at least until i get 1 million ked.
I believe if enough of the users/clients out there do this then the network will unclog again and we wont have to use any other more drastic measures, such as a re-issuance or recoding.
I recommend at least method 2 with 'reservebalance=100000.00' for a 100k reserve.
cheers.
October 18, 2013, 12:45:12 PM
@ Dreamwatcher.
1. Thank You for all your help and support, you truly are the main reason for the success of these coins. I think I speak for everyone when I say this.
2. I had already considered the hard fork option, but like you pointed out the dev time needed is high, and most importantly there is no guarantee of success.
3. I personally want to do a relaunch and give coins back in the amount, that they have currently been mined. I want a block of 100,000 to devide and the remainder used for a design competition. To redesign the darsek logos, so that it truly is distinguishable from the original.
4. If we do go down this route, It would be good to know if the ked explorer http://ked.cryptocoinexplorer.com/ can be used to see all wallet balances. People would stake their claim on the forum (we could use the new www.scificointalk.com *thanks to Shad3dOne*) to each balance and I will manually payout at launch. Unclaimed balances will remain for 1 or 2 months and then if unclaimed we can give them away. We *could* do it by people sending in their current coins, but we are running out of PoS blocks to process the transactions, so best to do it the way I suggested.
Maybe we will need to have a poll, to determine what people want from the new coin. What algorythm? what style? base58 starting letter, total coins, block target time, TX comment needed? TX fees? Maybe to make it indivisible like pennies or some other Ideas.
1. Thank You for all your help and support, you truly are the main reason for the success of these coins. I think I speak for everyone when I say this.
2. I had already considered the hard fork option, but like you pointed out the dev time needed is high, and most importantly there is no guarantee of success.
3. I personally want to do a relaunch and give coins back in the amount, that they have currently been mined. I want a block of 100,000 to devide and the remainder used for a design competition. To redesign the darsek logos, so that it truly is distinguishable from the original.
4. If we do go down this route, It would be good to know if the ked explorer http://ked.cryptocoinexplorer.com/ can be used to see all wallet balances. People would stake their claim on the forum (we could use the new www.scificointalk.com *thanks to Shad3dOne*) to each balance and I will manually payout at launch. Unclaimed balances will remain for 1 or 2 months and then if unclaimed we can give them away. We *could* do it by people sending in their current coins, but we are running out of PoS blocks to process the transactions, so best to do it the way I suggested.
Maybe we will need to have a poll, to determine what people want from the new coin. What algorythm? what style? base58 starting letter, total coins, block target time, TX comment needed? TX fees? Maybe to make it indivisible like pennies or some other Ideas.
October 18, 2013, 12:16:26 PM
THE DARSEK POOL WILL BE CLOSING IN 5 HOURS
The mining operation will shut down in 5 hours in keeping with the promise I made.
The website will remain up so withdrawals can be made.
Within 24-48 hours I will get everyone's account credited for the last 48 hours.
The mining operation will shut down in 5 hours in keeping with the promise I made.
The website will remain up so withdrawals can be made.
Within 24-48 hours I will get everyone's account credited for the last 48 hours.
October 18, 2013, 11:32:47 AM
I wonder if we could try out a system similar to proof-of-burn here. Basically, you prove that in the old blockchain you sent coins (from an address you own) to an unspendable address (and that that event actually occurred), and that gives you new coins.
I'm not sure how feasible that would be, though. You would need to get a full record of unspent txouts, as well as give people time. A complete cross-reference would also be advised.
The superblock idea, though, looks good - mine a few superblocks corresponding to the entire KED supply and send it to the addresses containing KED.
I'm not sure how feasible that would be, though. You would need to get a full record of unspent txouts, as well as give people time. A complete cross-reference would also be advised.
The superblock idea, though, looks good - mine a few superblocks corresponding to the entire KED supply and send it to the addresses containing KED.
October 18, 2013, 10:52:34 AM
Late last night I went ahead and shifted around all the coins in the Pools wallet with the coins in my personal wallet. Looks like not much has happened.
If we needed to drastically change something (Like the chain structure to get away from the CMC structure) it could be done in a hard fork. The main issue here is the amount of development time needed as this would be a labor intensive operation. The client/daemon would have to be coded to check/build the chain up to the point of the hard fork the way it is now. After the hard fork in the chain the client/daemon would need to use the new rules. It is even more complex then it sounds.I do not have the time (CCE3 is already waaaayyy behind schedule), to dedicate to being part of that team in any way that woulds be meaningful.
However, I like scifi's idea of a "cash in" and just doing a re-launch. "KED: The Next Generation"
A better and maybe even creative chain structure could be used to relaunch. This is could be done in a much shorter period of time.
If we needed to drastically change something (Like the chain structure to get away from the CMC structure) it could be done in a hard fork. The main issue here is the amount of development time needed as this would be a labor intensive operation. The client/daemon would have to be coded to check/build the chain up to the point of the hard fork the way it is now. After the hard fork in the chain the client/daemon would need to use the new rules. It is even more complex then it sounds.I do not have the time (CCE3 is already waaaayyy behind schedule), to dedicate to being part of that team in any way that woulds be meaningful.
However, I like scifi's idea of a "cash in" and just doing a re-launch. "KED: The Next Generation"
A better and maybe even creative chain structure could be used to relaunch. This is could be done in a much shorter period of time.
October 18, 2013, 09:39:51 AM
I have not had darsek show stake ever. UFC does all the time and shows it. How many coins do you have to have before it does its thing?
October 18, 2013, 09:37:19 AM
I may be wrong.
And I think i probably am. I am reading about Cosmoscoin, the coin that KED was cloned from. It looks like it may have been a bad choice. The PoS code was taken from the earlier version of novacoin, and may have some inbuilt PoS problems, that do not exist on UFC or GPL.
One possible solution that I have thought of, would be to have a cash in..
If we were to relaunch the coin we could do block 1 as a super block (80,000 - 100,000) and divide the coinage between the current Darsek contributors.
We could create a new coin, without the stratum issue. we could even make it Sha256, or some other algorithm.
Just an idea. I think it's less pain then any other possibilities at the moment. As we have a small close knit group it would be a lot easier for us. What do people think?
October 18, 2013, 08:26:28 AM
Question about PoS: Is there a way to make PoS consume multiple txouts, or is it only possible to stake one at a time?
AFAIK. It depends on how the coins arrived at that wallet, as the PoS is purley based on time or blocks passed since generation. So for example blocks that were originally solo mined will stake one at a time, but if you get 1000, in one lump from a pool it will stake as one block in the future.
October 18, 2013, 07:38:16 AM
Question about PoS: Is there a way to make PoS consume multiple txouts, or is it only possible to stake one at a time?
October 18, 2013, 07:20:21 AM
Ok guys so the reason for the Darsek problem is quite simple from what I seem to be seeing, and as you may have gathered I have nowhere near the level of understanding of the complexities as Dreamwatcher does. However, this is not a problem in the code as such but more of a circumstantial issue.
The daemons and QTs that have long term static coins are crashing and taking up a vast amount of resources. This is also probably the reason Dreamwatcher has problems with the darsek pool daemon. The stake blocks are a big issue on resources especially as some of you have vast amounts of coins.
The long term solution (if you still want to store vast amounts of coins) is to either move them around, or store them on a client that is always on and not in cold storage, this will take a lot of processing power if you have a large amount of coins.
In the future this should, in theory become less of an issue as the coins with have more liquidity and as a result less PoS blocks with a stronger network.
The reason we are seeing problems now is because many people will have re-synced old wallets after the new clients were released. the PoS blocks are all bottle-necking the network as they have been stored up for a long time. Now all this info is being forced onto the chain.
Like Shad3dOne has suggested the only fix now is to move your coins along to completely new client (wallet.dat) .
You may find that moving them is a pain, but keep trying and you will get there.
I may be wrong.
The daemons and QTs that have long term static coins are crashing and taking up a vast amount of resources. This is also probably the reason Dreamwatcher has problems with the darsek pool daemon. The stake blocks are a big issue on resources especially as some of you have vast amounts of coins.
The long term solution (if you still want to store vast amounts of coins) is to either move them around, or store them on a client that is always on and not in cold storage, this will take a lot of processing power if you have a large amount of coins.
In the future this should, in theory become less of an issue as the coins with have more liquidity and as a result less PoS blocks with a stronger network.
The reason we are seeing problems now is because many people will have re-synced old wallets after the new clients were released. the PoS blocks are all bottle-necking the network as they have been stored up for a long time. Now all this info is being forced onto the chain.
Like Shad3dOne has suggested the only fix now is to move your coins along to completely new client (wallet.dat) .
You may find that moving them is a pain, but keep trying and you will get there.
I may be wrong.
October 18, 2013, 05:16:03 AM
I had an old wallet.dat file stored from the early days of KED mining. I synced it up last night with the new client and I get lots of POF blocks with 0 amount
I thought they were called POS blocks?
October 17, 2013, 11:37:57 PM
Another clue:
https://bitcointalksearch.org/topic/m.3270196
Too many POS blocks being generated by a pool. Pos is taking priority rules and blocking All POW generation.
Next clue :
https://bitcointalksearch.org/topic/m.3273614
The longer you keep a coin in your wallet...the more likely it will generate POS...and block POW generation.
Hope this helps.
https://bitcointalksearch.org/topic/m.3270196
Too many POS blocks being generated by a pool. Pos is taking priority rules and blocking All POW generation.
Next clue :
https://bitcointalksearch.org/topic/m.3273614
POS Blocks override POW blocks... so until all wallets (thousands of them currently opened) who has POS blocks to be mined are mined, POW must wait for POS to complete. Therefore, to help speed up POS, goto HELP > DEBUG WINDOW > Click CONSOLE tab, then type
sendtoaddress [comment] [comment-to] [tx-comment]
and send to your own wallet address with the FULL amount in your wallet.
This will stop the thousands of POS blocks waiting to be mined. POS Blocks are CPU mined blocks and will take a very long time.
by swiftshoot
possible fix...renew coin-age in large wallets by moving coins to another address/wallet..send to self etc...this will knock down the POS generating override and allow POW to be mined once again.sendtoaddress
and send to your own wallet address with the FULL amount in your wallet.
This will stop the thousands of POS blocks waiting to be mined. POS Blocks are CPU mined blocks and will take a very long time.
by swiftshoot
The longer you keep a coin in your wallet...the more likely it will generate POS...and block POW generation.
Hope this helps.
October 17, 2013, 11:08:44 PM
One more thing. Is it possible that you got the correct patch, but everyone else are running the old one and rejecting your blocks? Maybe you are a subject of 51% (or maybe 98%) attack by old daemons.
October 17, 2013, 10:38:09 PM
Just an idea, why don't you make the changes locally, and recompile ked. Who knows if it will work. UFC uses the same value, but it has different other settings.
I have been. I lost count of how commits I ported over, changes, and compiles I have done tonight. I think I am done for tonight. Hopefully somebody will come up with a solution overnight. If not I will try again tomorrow.
October 17, 2013, 10:23:00 PM
Just an idea, why don't you make the changes locally, and recompile ked. Who knows if it will work. UFC uses the same value, but it has different other settings.
October 17, 2013, 09:52:14 PM
And here is a getwork primer geared towards Scrypt based coins:
https://litecoin.info/Scrypt
https://litecoin.info/Scrypt
Quote
Breakdown of data and header
See Block hashing algorithm
~/litecoind getwork
{
"midstate" : "40fd268321efcf60e625707d4e31f9deadd13157e228985de8a10a057b98ed4d",
"data" : "0000000105e9a54b7f65b46864bc90f55d67cccd8b6404a02f5e064a6df69282adf6e2e5f7f953b 0632b25b099858b717bb7b24084148cfa841a89f106bc6b655b18d2ed4ebb191a1d018ea7000000 0000000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000",
"hash1" : "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000",
"target" : "0000000000000000000000000000000000000000000000000000a78e01000000"
}
The data field is stored in big-endian format. We need to cover that to little-endian for each of the fields in the data because we can pass it to the hashing function.
Data is broken down to:
Version - 00000001 (4 bytes)
Previous hash - 05e9a54b7f65b46864bc90f55d67cccd8b6404a02f5e064a6df69282adf6e2e5 (32 bytes)
Merkle root - f7f953b0632b25b099858b717bb7b24084148cfa841a89f106bc6b655b18d2ed (32 bytes)
Timestamp - 4ebb191a (4 bytes)
Bits (target in compact form) - 1d018ea7 (4 bytes)
Nonce - 00000000 (4 bytes)
You need covert these from big-endian to little-endian. This is done 2 characters at a time because each byte is represented by 2 hex chars. (each hex char is 4 bits)
Version becomes 01000000
Previous hash becomes e5e2f6.....a5e905
Merkle root becomes edd218...53f9f7
Timestamp becomes 1a19bb4e
Bits becomes a78e011d
And Nonce is a 32-bit integer you choose that will make the scrypt hash be less than the target.
Remember that you will need to convert the 32-bit nonce to hex and little-endian also. So if you are trying the nonce 2504433986. The hex version is 9546a142 in big-endian and 42a14695 in little-endian.
You then concatenate these little-endian hex strings together to get the header string (80 bytes) you input into scrypt
01000000 e5e2f6.....a5e905 edd218...53f9f7 1a19bb4e a78e011d 42a14695
See Block hashing algorithm
~/litecoind getwork
{
"midstate" : "40fd268321efcf60e625707d4e31f9deadd13157e228985de8a10a057b98ed4d",
"data" : "0000000105e9a54b7f65b46864bc90f55d67cccd8b6404a02f5e064a6df69282adf6e2e5f7f953b 0632b25b099858b717bb7b24084148cfa841a89f106bc6b655b18d2ed4ebb191a1d018ea7000000 0000000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000",
"hash1" : "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000",
"target" : "0000000000000000000000000000000000000000000000000000a78e01000000"
}
The data field is stored in big-endian format. We need to cover that to little-endian for each of the fields in the data because we can pass it to the hashing function.
Data is broken down to:
Version - 00000001 (4 bytes)
Previous hash - 05e9a54b7f65b46864bc90f55d67cccd8b6404a02f5e064a6df69282adf6e2e5 (32 bytes)
Merkle root - f7f953b0632b25b099858b717bb7b24084148cfa841a89f106bc6b655b18d2ed (32 bytes)
Timestamp - 4ebb191a (4 bytes)
Bits (target in compact form) - 1d018ea7 (4 bytes)
Nonce - 00000000 (4 bytes)
You need covert these from big-endian to little-endian. This is done 2 characters at a time because each byte is represented by 2 hex chars. (each hex char is 4 bits)
Version becomes 01000000
Previous hash becomes e5e2f6.....a5e905
Merkle root becomes edd218...53f9f7
Timestamp becomes 1a19bb4e
Bits becomes a78e011d
And Nonce is a 32-bit integer you choose that will make the scrypt hash be less than the target.
Remember that you will need to convert the 32-bit nonce to hex and little-endian also. So if you are trying the nonce 2504433986. The hex version is 9546a142 in big-endian and 42a14695 in little-endian.
You then concatenate these little-endian hex strings together to get the header string (80 bytes) you input into scrypt
01000000 e5e2f6.....a5e905 edd218...53f9f7 1a19bb4e a78e011d 42a14695
October 17, 2013, 09:43:53 PM
KED getwork gives the following... Can anyone decipher it?
{
"midstate" : "675c64ab03bfcc587dc7631e8ca74dc63bf82d97dcdb79edf2a75b7c5a16b8fd",
"data" : "000000042aa1497ccc07747f86dad47bd873bfccc29b0ee40b8a90bde601bb8b0446f5f40c7cfc9 6cf831532938649867f9565c829409a6437d8c0fc7d0460d5824c3865526098461d828463000000 0000000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000",
"hash1" : "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000",
"target" : "0000000000000000000000000000000000000000000000000000638402000000"
}
{
"midstate" : "675c64ab03bfcc587dc7631e8ca74dc63bf82d97dcdb79edf2a75b7c5a16b8fd",
"data" : "000000042aa1497ccc07747f86dad47bd873bfccc29b0ee40b8a90bde601bb8b0446f5f40c7cfc9 6cf831532938649867f9565c829409a6437d8c0fc7d0460d5824c3865526098461d828463000000 0000000080000000000000000000000000000000000000000000000000000000000000000000000 0000000000080020000",
"hash1" : "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000",
"target" : "0000000000000000000000000000000000000000000000000000638402000000"
}
I have been looking at those all night and comparing to getblocktemplate to find discrepancies.
Here is a primer on the getwork protocol:
https://en.bitcoin.it/wiki/Getwork
Jump to: