It might not be too hard to whip up a script that iterates the addresses and then dumps the private keys for them.

You can export and then later import the private keys (am not sure if the exporting can be done in one go though - you'd need to check that).

Glad to know that you fixed your problem but I would recommend that you reconsider the idea of having such a huge wallet (especially if it is going to grow much bigger).

Many of the RPC functions will perform poorly because of that (and the problem will just get worse and worse).

I was guessing the same thing but wanted to make sure exactly what was causing the crash first (if the super large wallet is causing blockchain corruption then perhaps that is a bug that should be reported).

OP should note that if they are using Windows then they are using a 32 bit version (so a possible fix might be to change to a 64 bit Linux version).

Thanks for clearing that up for us.

Then your problem is a corrupted blockchain (whether or not your wallet has anything to do with it) so unfortunately you are simply going to have to repair that before trying to use your original wallet again.

I would suggest you consider setting up a separate machine (or VM) for working on this and keep a copy of the blockchain (once you have the full uncorrupted version) somewhere handy.

The point being that if it was due to your wallet's size that somehow the blockchain got corrupted (unlikely but I guess possible) then you might find that as soon as you put back your big wallet and restart it might corrupt the blockchain again (putting you back to square one).

So once you have a clean blockchain (with an empty wallet) back that up (the whole thing) before trying to put back in you big wallet.

I didn't suggest that you resync the whole blockchain at all - backup your wallet and then delete it is all I suggested (after first stopping bitcoind).

That shouldn't take you more than a minute to do (after you restart bitcoind it will create a new empty wallet which is done almost instantly).

It is only a solution to the malleability issue that rendered TierNolan's original implementation practically unusable (so I just wanted to clarify that malleability is no longer a part of the problem).

I see ACCT with CLTV as being more akin to a street currency exchange than to an exchange like Cryptsy (i.e. useful in the same way as a street currency exchange is for fiat when you are traveling abroad but not very suitable for the purposes of day-trading and cannot be used for high frequency trading of course).

If the purpose of say obtaining LTC for BTC was not to day trade but just to have some LTC as some sort of hedge or to use for some other purpose then you won't need to trust an exchange like Cryptsy being the point.

Firstly, have you verified that it is the wallet that is causing your problem?

(if you haven't then there is very little point in my continuing to offer any advice)

In regards to decentralised exchanging using ACCT the introduction of CLTV means that malleability is no longer an issue (you don't need to refer to transaction ids that aren't already confirmed).

I have built code that will create a Bitcoin script that works by combining the ACCT and CLTV with a P2SH address and redeem script.

https://bitcointalk.org/index.php?topic=598860.msg13435766#msg13435766

I wrote some code that would let you encode data into addresses here: https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L757

The method shown only encodes one byte per address (even trying two bytes per address is rather too slow to be of much use) but at least you have all the secret keys (so all addresses can be redeemed by yourself).

Of course the tx fees will become rather large as you add more and more outputs to the tx so is it a very practical way to store information in the blockchain? No and that isn't what the blockchain should be used for anyway (there will soon enough be things like side chains that will be suitable for such things).

Why did I code this? Mostly it was just some experimentation and fun (I haven't actually used it with any tx I have pushed onto mainnet).

Well first I'd suggest you work out whether the problem is your wallet - assuming that it is then I hope for your sake you have a backup that still works (if not you are going to have a very hard time especially if the wallet is encrypted).

^ That is not a good idea.

The wallet doesn't scale well at all and despite the large amount of RAM you might be hitting a limit that is causing the bad alloc (although a bad alloc could also be caused through passing an invalid value for allocation).

To work out whether the problem is your wallet's size back it up and then delete it and re-start Bitcoin (it will create a new empty wallet). If no crashes happen with the empty wallet then I would assume your problem is the huge wallet.

Really?

Hmm... let me see - I remember now - Unwatch!

(so now that I have *left* feel free to carry on spouting your nonsense)

Thanks for the arrogant statement - how about you just leave instead?

(hint: you don't win hearts and minds the way you are going about things)

I never said you could spend "on the same chain" (please don't put words into my mouth - I am not doing so to you).

You would be able to spend your pre-fork coins on both chains so this is not fear mongering but simple *fact* (have you not understood how it works?).

So if such a hard-fork situation arises then no vendor would want to accept any BTC purchases (nor should they) until a clear majority has taken control.

If that control is not taken smoothly and quickly then you would expect chaos.

If it was only 51% (and why not just say >50% as there is nothing magical about 51) then it would be very problematic as has already been pointed out that could easily be reverted (as you have to continue to control the hashing power).

This is why any hard-fork should require a lot more % of the hashing power (it costs miners a lot in electricity to create new blocks so they are not going to want to be creating invalid ones).

If a >50% attack like this happened then there would be two Bitcoins and you could literally spend your coins twice. IMO if that actually happened then Bitcoin would lose 99% of its value (which is most likely exactly what the banksters are hoping to achieve).

BTW - people were trying this "ultimate compression" scam back in the 1990's (on usenet) so your idea is really not much newer than the Nigerian Prince one.

I suggest you try harder next time.

You are spouting nonsense - why?

My guess is that you are trying to scam people because there is no logical reason to spout such nonsense otherwise.

I think I would be warning others to be very careful taking anything this forum member has to post with more than a grain of salt.

You cannot get 0.1% consistently - if you are given a random set of values with no repeated ones then how on earth did you compress it by any percentage at all?

You are either deluded or wanting to scam but in either case your statements are not even close to rational.