bitcoind is often used in automated processes.  I much prefer my company wallet being automatically backed up every day and knowing I have multiple backups then an intrusive system which waits to refill the keypool and forces me to do a manual backup on a unpredictable schedule.

What if the user makes a backup right before the keypool exhausts and being a user (think your grandmother) assumes he is "covered" he just made a backup 5 minutes ago it must be good.  Then they keypool refreshes making his backup 5 minutes ago worthless?

What happens if you are right in the middle of sending out a batch of payments.  Will the system halt and lock you out of your own money until it forces you to make a backup?   Will it actively prevent you from using the wallet.   If it doesn't and the wallet fails you just lost keys and funds.

What happens if the backup is corrupted?  Your prior backups are completely useless because backups between refreshes contain less and less new keys?

Of course the client is open source.  Feel free to fork it and implement a different backup system.    Honestly given all the potential use and applications I can't see a more universal solution than make regular backups and the backup will contain all used keys and X future keys.  Still this is somewhat academic, long term all wallets will be deterministic anyways.

Why would he do that? He likes giving away his personal wealth?  It is a corporation.  Baring fraud on the part of the CEO the investors claim is with the corporation, which according to the report has $50,000 in assets for $3.6M in debt.

Maybe in the future they will make wiser investments.  Note it was a major VC firm it isn't like they aren't capable of due diligence.

No unless you like losing keys, unpredictability, or bitcoind halting your automated system because you didn't do a backup you didn't know you needed to do until it halted.

As it stands now every backup is useful.  It resets the "future key clock" to the limit of the pool (default 100).  So if you do a daily or weekly backup your backup will ALWAYS have all keys and the next 100 future keys.

Backups should always be periodic.  Setup your system to backup the wallet.dat once per week and set your keypool large enough to cover two weeks usage and at all times you should have two valid backups (in case of a file corruption issue).   Nothing to think about, no risk of creating keys which aren't backed up, no intrusive system where bitcoind has to prevent you from using your own money because it just foolishly exhausted the keypool and needs you to stop and manually make a backup right now.

It would make backups before the pool exhausts useless.  As it works now any backup made at anytime covers all active addresses and the NEXT 100 future addresses.   It also means that prior backs (if not overwritten) likely are also effective and can be used as a backup for the backup if you do more than 1 backup per 100 key uses.

My keypool is 1,000 keys.  My highest weekly usage ever was ~130 keys.  I backup automatically once a week with sequentially named backups.  The likelihood of losing any keys is essentially zero.

It does but it doesn't allow the keypool to run out.  It adds a new key to the keypool everytime one is used.

Imagine a wallet has a keypool which contains 100 address.  We will number them 1 to 100.

So:
Active Addresses: None
Keypool: 1 ... 100

If you took a backup right now you will notice you have all the addresses backed up to #100.


You need a new address.  The wallet pulls the oldest key from the keypool "1".  It immediately add a NEW key to the keypool lets call that 101.

Active Addresses: 1
Keypool: 2 ... 101

Next address used
Active Addresses: 1, 2
Keypool: 3 ... 102


48 more addresses used.
Active Addresses: 1, 2 .... 50
Keypool: 51 ... 150

50 more addresses used
Active Addresses: 1, 2 .... 100
Keypool: 101 ... 200

If you used another address it wouldn't be included in your backup.

In the QT client the keypool is continually refreshed.  While the keypool contains 100 keys every send requires a new change address so the oldest key from the keypool is used AND a new key created and added to the keypool.  The keypool is always at 100 keys (baring some unusual situations where wallet can't be unlocked).

So yes the wallet would need to warn you to backup every single time you sent a transaction OR clicked New Address.

Do you know how to properly title threads?
Do you know how to select the proper sub forum?

(Hint: they are rhetorical questions the answer is no)

So every transaction you mean.  You want the wallet to warn you to backup after every single send?

None.

If you had a rig which would produce X BTC per day (after operating costs) why would rent it for less than x BTC per day?

Why not just run the rig and collect X BTC?

There seems to be some confusion between ADDRESS and PUBLIC KEY.

The PUBLIC KEY is computed from the PRIVATE KEY using ECDSA.

The ADDRESS is the PUBLIC KEY triple hashed and checksumed.

It is utterly impossible for a human in any reasonable amount of time and with any reasonable accuracy (don't want to be sending funds to the wrong address) to perform the hashing necessary to create the ADDRESS.

However the OP asked about the PUBLIC KEY.  It would seem difficulty but possible to compute the PUBLIC KEY from the PRIVATE KEY.  Then transfer only the PUBLIC KEY to a computer and use a simple program to compute the full ADDRESS.

Sorry for the annoying caps but seems many people can't grasp the difference between PRIVATE KEY, PUBLIC KEY, and ADDRESS.  If you are one of them they are three distinct things. ADDRESS =/= PUBLIC KEY.

Curious on what exactly they burned $3M in funding on in a mere three months.  I mean even for hookers and blow we are talking $33K per day.

To decrypt an encrypted wallet.dat two possibilities:
a) keylogger

or

b) you claim short but unique.  Short = worthless password.  If it was short enough it may have simply been brute forced.  If it had been long and unique that would have been more interesting.  Care to share the password?  Hopefully you are not using it anywhere else, you should assume the attacker knows it.

I guess but very risky.  When the tx was done the OP could have sent the coins to a new address.  Proving it was the OP not the middle man who moved the coins after the fact would essentially be impossible.

Except he did move the coins.  Not moving the coins would be an asinine security risk as the owner could simply take them back at any point until they are moved.

No idea.  He probably (incorrectly) thought it would somehow be more secure or less traceable.

Wait and complain to them for not including a fee.

No it wouldn't.  There is no issue in moving BTC between exchanges.  The issue is in moving USD from MtGox to your account to another exchange.   LTC won't magic that problem away.  MtGox fixing their banking system or moving to a country where they can fix their bank access will solve that problem.

Well TSMC 20nm line starting in 2014 is CLN20SOC, for low powered devices (think mobile phones, <10W, system on a chip type designs).  TSMC high performance 20nm line won't be available til Q3-2014 and even then prices are extremely high and availability very limited.  So yes I would say impossible not a stretch but we will see.

Maybe I should make a wager on bitbet could probably clean up.

Volume just means non-prototype.  The article I linked to was a month old.  There are plenty of similar ones only days old.  The number of 20nm designs for the entire year is a couple dozen.  Did KNC secure one of those coveted slots I doubt it given the number of industry giants who likely will be excluded from 20nm in 2014.  

Still your first claim was:

I think we can agree
a) KNC said nothing of the such
b) March isn't even a possibility for 20nm.
c) 2014 isn't even a possibility for 16nm.

I put money on 2015 at the earliest you may disagree but at least you admit than any 1620nm in March sometime in 2014 is your assumption not a statement by KNC.

I thought they were already sold out of Nov Saturns.