8 hours is really just an estimate based on how long it takes to reach maturity. The block maturity is 500, so 510 (10 for confirmation) blocks after you put the Clams in your wallet the green light should come on and staking should begin. The block times have been slower then then should be which is why it would have taken more then 8 hours. 

Also, from my understanding the 'stake reward time' is just an estimation calculated from your weight and the network weight. It can be pretty inaccurate (from experience), especially with growing networks like Clam's

Locked wallet won't create any issues.  Your wallet.dat will stay encrypted and as per usually it will ask for the password when you go to send

Im not a electrum expert but it seems like you should be able to use  dumpprivkeys( map(lambda x:x.get('address'), listunspent()) )  to get a list of private keys on the wallet with unspent outputs.

From then you just need to import them into the client. The Debug window->console   importprivkey     function will do that for you

Check out https://electrum.org/console.html for more details on dumping the keys

Yeah, your not wrong (about the data). The new client also trys to enforce not reusing addresses now, which means best practice makes it impossible for a parser like this to associate an address to a wallet.  

Its accurate on a per address basis.

The data is interesting but useless if your looking for the biggest wallets. It can tell you broad things, like there are 200k addresses with unspent outputs (just a made up number), there have been a total of so and so addresses since the beginning of the chain, etc.   Interesting, useless data.  My favorite kind    

I've used one of the open source block parsers (https://github.com/znort987/blockparser) which can find the unspent outputs for all the addresses on the chain.

I'll throw the DigiByte modified version in a repo so you can compile it yourself and check it out.  I'll includ my dump too, so you can just check the list if you want.

I haven't confirmed its accuracy yet but when I checked the balance on my address it was correct.

It will be a few hours, need to run out for a bit

I don't know much about economics, I'm more of a tech guy myself.. but I suspect because of the way clams were distributed the total clam distribution will trend with the total users. aka The more people that claim their Clams the more clams there will but the more demand there would be also which would possible lead to a constantly rare coin.

Should be very interesting to see this progress.

Did you run -salvagewallet during the first load? Otherwise your wallet.dat will hold tx information for invalid tx's, thus the "too high" and "negative" errors i suspect.

Also I was wondering about the dogecoin make a million address thing myself. While still costing a good amount in fee's, especially if you wanted to try to redeem those 1M 1 dogecoin addresses, you'd stand to gain more if things were to take off.  
 
If everything is correct I believe the majority of the address's must have came from the bitcoin blockchain. I say this because according to what Im seeing there are not enough addresses with positive values on the other chains. Keep in mind the block chains I'm parsing would not be in sync with the blockchains that the clam devs used so this is currently just a guestement at best.  

Ive been playing around with the one of the block chain parser and Bitcoin has currently over 2.7M addresses with balances above 0, which would be the majority of the ~3.1M Clams addresses distributed too. I don't claim to the accuracy of said parser I used but I checked a few of my addresses in the list and the balances were correct.  

If thats true, which intuition based on observation is suggesting is, that only leaves ~400k addresses between Litecoin and Dogecoin. I've yet to parse their blockchains but if the numbers on there chains are correct Litecoin and Dogecoin only add up to ~400k of the ~3.1M.

It would seem the majority of the coins went to Bitcoin holders.

I'm working on a script to test that, convert the address back to ripemd160 -> back to bitcoin and then see if it was a used address on blockchain.com

I'd be happy to provide the script for anyone interested, although I warn you, its in Go.

Edit: Clam Devs, the source used to create the original send would be very helpful as the current block-chains will be out of sync and not provide an accurate picture

Was just going through the git commits. I see the commits from after the fork from blackcoin and nothings looking worry some to me. I see there was some changes to base58 to support the keys with other identifiers, the rest seems pretty standard.

Built it in a fresh vm instance with no issues. Moved my coins to new wallets just to be extra safe and when I opened clams it seemed to be correct, there were clams there. 

Staked a block a few minutes ago with no problems also

Interesting idea! I considered something similar but got side tracked with other projects, I'll keep my eye on this one. 

The block reward was never 168. 

Block 49, the last block of the premine the reward was 3236.

Block 50 the reward went to 159.39  (http://explorer.nautiluscoin.com/block/98c4bf0592d7413ff4ec9c2d61bf3b95ef8495e955764af1ac5169a63e28b328) 

Currently the reward is 157.7961.

Block explorer is up at  explorer.nautiluscoin.com

Im still working on getting the new template working as its layout is quite boring at the moment.

It works though

The building process has changed some with the new client. Make sure your up to date with the git repository and run the following to compile.


The complete guide for building on linux can be found at https://github.com/digibyte/DigiByteProject/blob/master/doc/build-unix.md

Thanks for pointing it out

Spelling is not my strong suit, I'm sure there's one or two more spelling mistakes in there so if you see them let us know!.

We will have the updated client that fixes the ssl bug out later today. The URI payment protocol in the new client (2.9.0) is affected. I'm unaware of any web services for DigiByte that implements the payment protocol so risk should be very low. Once the new client is released if you were using 2.9.0 it would be best to send your DigiBytes to a completely new wallet and delete the old one. While this step isn't required I always err on the side of caution.

If your still using DigiByte 2.0.0 you should have no issues but coin control in the new client alone makes the update worth it.

I've been looking into the myriadcoin solution since talk about switching algorithms was brought up. Something about how it balances the mining and allows ASIC and GPU's to live together is appealing. I had a few concerns about potential attacks but they addressed my largest concern even before I even had a chance to mention it by weighting the difficulties against each other. I have the code setup in a testnet integrated with the DigiByte code and haven't seen any issues yet. More testing is required but it looks promising.   

Changing over should not be taken lightly though as the code is only one aspect. With this approach we would need new pools for each algorithm, new block explorers etc. To a large extent it would be like a relaunch. It would also make the process of mining more complicated, which isn't necessarily bad but is against the general approach of DigiByte and our goal of bringing DigiByte to the other 99% of people who don't yet understand crypto. 


 

I'm not saying we should switch as I'm still largely undecided, its a difficult problem. If we were to change I'm personally becoming a fan of the approach that myriadcoin has taken with there algo design (at least on paper). To me it seems like a balanced approach and could be tweaked for digibyte and accommodate other algos if we so desired.  


It would require some changes to infrastructure where we would need pools for each algorithm and depending on which algo you mined you would use a different mining program.

It needs more research but its an interesting idea and worth exploring

No one said that. I figured it could be assumed but obviously I was wrong.

The crypto crowd from my knowledge is not much of fans of centralization, especially of their coins. I know for sure I'm not. I had hoped you had answers to my concerns that didn't involve centralization or trust because that would have made this truly novel.

Thanks for your reply, I've learned everything I need to know.

Best luck with your coin

I'm not quite sure I get how a random difficulty can work and would love an explanation as I'm a fan of the concept and have considered it myself before.  

If each client is randomly generating their own difficulty on the hour whoever is lucky enough to generate the lowest diff required has the most chance to find the block as they require the least work, locking in the lowest diff a large portion of the time.

I'm also interested in how you can go back and validate blocks. When you go to verify a block with a 'random' difficulty change how does it find this random number again with certainty? When a block is processed it compares its PoW included in the block to what it would generate in getnextworkrequired. have you removed this PoW check for the blocks with diff changes?


Edit: taking it a step further there would be nothing keeping someone from modifying their client to always pick 1 diff on those changes. Where any diff between 1-20 has to be valid for those blocks you can remove the randomness entirely and still produce a valid diff that no one would be able to argue with.

I had this problem as well when I was compiling using gitian. I'm confident theres a better solution but restarting the vm instance that I was running kvm in solved the issue. Likely something to do with residuals left from the previous dependency builds that werent removed correctly wjem they completed.

I stopped digging after the reboot solved the issue.

Interestingly enough because of how private keys are generated and how addresses are validated in the clients in any coins based on bitcoin if the address prefix is the same, 'D' in our case, both addresses and private keys will be valid on both coins blockchain. Thats not to say your coins come with you from one blockchain to the other, just that the private key generated for an address on one blockchain will also be valid on the other if the address prefix match.

Now, you may ask yourself (as I did when I first discovered this), well, isn't this a security concern. Can't somebody on doge coin generate a private key that could access your address? This however is incredible improbable (or unfeasible depending on which term you like better) and no more likely then someone on the DigiByte blockchain generating an address that is already in use on the DigiByte blockchain. I could get into the absurdity of the numbers but needless to say the amount of possible addresses is beyond large. Imagine the number of atoms in all the matter on earth... and that would only be a small portion of the possible address space.

People in the past have occasionaly sent their DigiBytes to a Doge address on an exchange. Because the private key to the address they were sending already existed on the Doge blockchain and was owned by the exchange, the exchange was able to import the private key from one blockchain to another and redeem the otherwise lost coins.

This of course is totally up to the desecration of the exchange.

We've looked into possible solutions but have only come up with bandaids that aren't worth implementing and don't actually fix the underlying cause.

My only suggestion currently, as poor as a suggestion as it might be, is to remain diligent about verifying you are sending to a DigiByte address. Almost every instance of this has been related to DigiBytes being sent to an exchange. Double check your on the DigiByte deposit page when you generated a deposit address and that your not mixing up Doge and DGB or anyother coin that might start with D  

It also doesn't hurt to send a very small amount and verify it was deposited to your account correctly before you send a larger amount.  Its much better to risk losing 1 DigiByte to the void then 50k.  

You can conjecture all day but the bottom line is Apple doesn't allow anything to do with sending or receiving bitcoins on the app store as apparent by their recent removal of the blockchain app in February.

Here is a quote from blockchains response to their apps removal
(taken from https://blog.blockchain.com/2014/02/06/blockchain-response-to-apple/)



EDIT:  http://www.change.org/petitions/apple-allow-bitcoin-wallets-on-the-iphone/