So I can confirm that if you are having syncing issues with the gui client, directly running geth seems to solve that (and be faster).

so, I navigated to where geth (CLI interface) and manually ran it with this:
and it finished syncing after a few hours, this was with a fast (100+ Mbps network and an ssd), but non of the run away memory issues I was facing with the main client when trying to do the initial sync.  You could use a larger cache and see if it speeds it up more (value is in MB).

Same boat here, I'm back to the original 4gb of ram on my mac till I can rma my other sticks.  I let it run overnight and I came back to 40 GB of swap according to the activity monitor... I've now launched with the command line and am trying to limit the cache size... not quite sure if it is working though, swap is slowly growing... I was also under the impression that the --fast option was effectively a p2p download and reduced the verification.  This part of the setup is definitely not good, I may try to restore an old setup from a backup before my reinstall to see if I can get the sync to not be as memory intensive.  For ethereum they will need to develop some sort of distributed pruning if they want to have the blockchain companies (companies pay for the storage that they use, otherwise they are pruned) because these companies will lead to extra bloat... that and ram prices aren't dropping as fast as storage prices so there needs to be some changes in that department.

I guess let us know when it is officially available from github

Do you know if we need to backup or wallet after every time we stake or not (does the stake works by 'sending' the coins?)?

Do any of you know of a good way to release coins that seemed to be stuck trying to stake a block that wasn't accepted by the network?  I tried -rescan and that didn't work, at the moment I'm in the processes of re-downloading the blockchain.

I'm guessing your question is related to one I had a few pages back.


So, if there has been a two hour delay since the last block was process, you'll probably get that message.  Good news is, the network is smoothing out so that these delays should disappear.

Sounds like that is the main chain then?  I'm on 702518, which is about right with the time that has passed...  How many people are having client issues (and do we know why the block explorer is behind?)?

So, it would appear that the block explorer https://chainz.cryptoid.info/flap/ is stuck on block 702293 at the moment?

Looks like the network is getting a bit more active, between having (seemingly) more people involved and the splitting Griffith was talking about, the block time is starting to look a lot better.

Are you looking at this from inside your wallet?  I'd say it is because they are currently staking, if you want to prevent this you can encrypt your wallet (however you won't earn any coins unless you unlock it for a while).  If your not looking at it from inside your wallet I'd say open it and check the staking balance.

Yup, I take it that it just went through?  I guess I should have waited a few extra hours to post...  Although I guess it looks like it is taking a few hundred blocks to get a transaction in sometimes or I'm just unlucky?  Thanks for the update

Hasn't hit a block, here's the transaction ID: b534da9eeb6feee6e40751bb7c0a16ab890bb09c241a2fc7519d05730de9195c-000 wallet says it was broadcasted through 5 nodes, but has zero confirms.  It could just be slow to propogate through though.  I can always stake the transaction myself in two days.

How well are transactions going through for yall, or are you having to process your own transactions right now?  I've got one transaction that has been pending for close to 20 hours despite all the recently processed blocks; are nodes just not relaying transactions to each other well because of the limited network size?

A Qt button that unlocks the wallet (so you don't have to open the console), when pressed it would prompt you for your password and then ask for how long you'd like to stake.  Also, this might be work than it's worth, but is it possible to make the minimum stake time vary based on time since last transaction (like difficulty)?

For those interested flap seems to have a new dev and has moved to: https://bitcointalk.org/index.php?topic=860075.0

*edit: I should add that this one has gone PoS

Ah..., it does appear like you have to unlock your wallet if it is encrypted to stake... Is there a way around this, otherwise a button in qt might not be a bad addition?  Although, I guess you can still go to the console and change it.

I think the reason for the fast block time is probably because there are so few open/valid wallets up at the moment, when a wallet does have an address become availible it binges on the blocks and then we wait another couple days... dropping the average difficulty quite a bit.

Ok, so would it be a good idea to split balances across several wallet addresses so that we can get a more consistent blocks?  Also does our wallet need to be unlocked to stake?  (I may have decommissioned mine for a while... I tried sending a test transaction that got stuck..., so I may have to wait a while till my coins are availible to stake (on a side note, is the delay 3 days or some other time?))

*edit: Well I see chef bauer just put the minimum wait for my stake time question.

So, according to this (https://chainz.cryptoid.info/flap/#) at the time of posting we're at block 700442 and that is supported by my peer connections.  My wallet says that it is on block 700442, yet still thinks it is 13 hours behind?  How do we counter the slow network when there may be long periods of time when no blocks were created (which I'm assuming causes the wallets to think they are behind?)?

*edit: well, checked this morning and it is now up to date