Double spend attempts are rare.  Really rare.  Because of this, if the chain reorgs, all legitimate transactions that were in the old chain will be in the new chain, or they'll make it in shortly.

But, a reorg destroys a coinbase permanently.  If that coinbase had been spent, all transactions that traced back to it would become invalid and need to be thrown out.

So, the solution is to prevent spending coinbases until WAY more blocks have passed than we ever expect to get balled back in a reorg.

Odds are pretty good that it was just addr.dat that you needed to delete.  That is the culprit like 90% of the time.  The good news is that the latest RC has swapped that out for a less annoying system.

The logs should indicate which file is causing the problem.

Phishing?

Ok.  It is already bold, I can't make it bolder.  How about red?


Your posts make it clear that you do not understand this distinction.  Here is a recent example:


Capital does not sit in wallets.

Put another way, money is not wealth.  Money is what you use to purchase wealth.

There are up front costs, and then per run, per wafer and per chip costs.  The fabs are rarely totally transparent with them, preferring instead to give quotes like "X for the first 1000 chips, Y for each subsequent thousand", or whatever.

Assuming that there are no errata, Y should be much lower than X.  If there are errata, and they can't be fixed with blue wire, you might be back to step 1.

And getting recognition is huge.  It establishes the presumption, makes it normal.  Think of the hoops that Jubal tricked the government into jumping through when they met with Mike in Stranger in a Strange Land.

15!  But this time with electrons, and this time it was really truly Quantum^TM, for sure.

Also, according to Wikipedia, the first factoring was done in 2001.  It may not have actually been a quantum event since entanglement wasn't observed, but I'd think that teaching an NMR machine to factor integers would be a bigger accomplishment!  After all, everyone "knows" that quantum computing is coming, but getting Shor's to work in a non-quantum computer would change the world.

BDB doesn't work the way you are thinking.

BDB records extra data outside of the database files in an attempt to ensure consistency across (some types of) crashes.  For historic reasons, BDB expects database files all to be in the same place, and all of the files in that place share a single journal set.  The log.* files in database/ are the BDB journal, FYI.  As long as the files are closed properly and marked as clean ("detached"), you can swap them back and forth with no problems.  It simply doesn't support having files in multiple places, and there is nothing that bitcoin's developers can do about it.

The only option is to work around it by creating a whole second BDB instance, doubling the overhead, doubling the development effort needed, and bloating the code.  Oh, and then the client would have to rescan after even trivial "clean" crashes (maybe even on normal starts too, now that I think about it), because there would be no way to do transactions across both instances and so the code could never be sure that both databases were synchronized, even if both were marked clean.

I'm not even sure if Access does any journaling, it's been a long time since I used it, and google results weren't very helpful.  If it does do any, it does it inside the file, not externally like BDB.  Also, Microsoft has gigantic systems (OLE, DDE, etc) for data access abstraction hidden in the operating system so that their products can interact for "free".  The Bitcoin devs get no such help, they have to use the lowest common denominator between Windows, Macs and Unix, which is nothing.  Which means that they need to bring along their own third-party database library, and it needs to be freely distributable, plus work across all three platforms.  BDB fits that bill, not much else does.


Shit, September is right around the corner isn't it...  By the way, pull requests are for patches, not feature requests.

I struck out your baseless assertion.  Your one sentence is trivially true, but being merely a roundabout definition of "want" and "need", it is devoid of other content.  It certainly does not follow from that sentence that more spending is better, nor that the lack of spending is evidence of a flaw in anything.  Nor does it say anything about what the real level of spending is or should be.

Hmm.  The other hundred threads on this same topic all came to the conclusion that QC wasn't a problem for the next decade or more, and that we'd have plenty of time to adapt as technology improves.

I'm going to watch this thread, just in case it turns out differently from the others.

I'm in total agreement.  I was skeptical of deterministic wallets early on, because I know that they are full of traps waiting to catch the unwary.  But done right, the difference in security is negligible at worst (and with a huge upside 99.9% of the time).  And the negligible security loss is only in the amount of work the attacker has to do after he's already done the impossible.  Seems like a good trade.

However, for my personal deep safe wallet, I still prefer that my keys be unrelated and totally random (well, as random as /dev/random).  Keys generated offline using known code (using something like a live distro that predates bitcoin, heh), encrypted and burned to M*Disc DVDs and printed on archival paper, addresses burned to different DVDs and also printed.  Copies of the encrypted private keys stored in different cities.  Easy to send money to a wallet like that, but very difficult to get money out, which fits my needs very well (but is not practical for most people or most uses).

The sad thing is that for every person that thinks that I went overboard, at least one other person will think that I wasn't careful enough.

Ahh, so it is bytes.  I read your chart wrong.

Hmm, that makes your scheme (very!) slightly less secure against rainbow tables.  Yeah, I know, rainbows for this are totally impractical because you have a good initial a, but a (very!) lucky hit would reveal the rest of the sequence without the bother of having to search for the c that generates the next one.

And just to be clear to people following along at home, the level of "very lucky" that I'm talking about is probably along the lines of an attacker being saved from Death By Meteor when another meteor hits the first one at the last second, knocking it aside.  In practice, it isn't much better than brute force, as long as a is strong.  If some idiot modifies it to accept a weak a from the user, all bets are off.

scrypt seems to be the only safe way to do it, and with terribad parameters so that it takes forever even on a decent box.  Real users won't do it often enough to be put off by it, but attackers have more resources.

Agreed on the brain wallets.

The rainbow attack would be huge, and sneaky.  You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever.  I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.

That's pretty cool.  The EC multiplication routine doesn't look like it should associate and cancel like that.

I guess that means that if Moore's law holds for a bit longer (heh), it will become possible to attempt rainbow tables attacks on schemes like this if they don't start with a good entropy source for a and c.  Brainwallets come to mind.

You'd be better off generating the pair remotely, and pulling the address into the customer-facing server.

The stuff that you don't want stolen is being created in the place that you are worried about it being stolen from.  That isn't a great idea, even if you delete it right away.

Heh, I'm no cryptographer either, that's probably my problem.  But I do have an implementation of ECDSA that I'm somewhat familiar with, and it works correctly with bitcoin keys.

I was just going through the code that I use to generate ECDSA keypairs, and the multiplication used to create the public key didn't look like it could possibly be done in that way.  The multiplication depends on every bit in the private key, and you can't back out a step if you want to change one of the private bits.  (My understanding is that if you could do that, it would totally break ECDSA's security.)

Because of that, I had assumed that Armory generated a couple thousand (or whatever) private keys, made public keys for them, and gave you the option to export just the public keys for watching elsewhere.  If it turns out that there is a pair of iterator functions that can create halves of a keypair without the other half present, I've gotta see it.

If you don't trust the host that runs your web store with your wallet, you really shouldn't trust it with the stuff that your wallet it made of either.

By the way, this is possible to do entirely in PHP, no calls to an external program.  You need a PHP library for doing EC math (there is one, LGPL), the curve definition for secp256k1 (copies of SEC2 are available for free on the web) and a little code to glue it all together.

The nice part is that if you do it all internally, you can specify the private key rather than asking the program for one at random.

Question about watching wallets...

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

Generating a list of (pseudo)random numbers to use as private keys is easy enough, and deriving public keys from them is also pretty simple.  But I can't figure out how to write a generator for a sequence of public keys that doesn't involve generating the list of private keys and then deleting them.