In the absence of the DNS seeds, you can simply ask someone for the address of a node and connect to it.  Once connected, your node will learn thousands of addresses.

The DNS seeds are just a convenience.

No, BIP 34 prevents duplicate transactions because they were an ugly corner case.

It was heavily discussed, so searching these forums for it will provide enlightenment on the matter.  The short version is that allowing duplicate generate transactions was surprising, but realizing that they could be spent and then mined again was even more surprising.  In theory, whole strings of transactions with identical IDs could be made that way.

There is no simple relationship.  See https://en.bitcoin.it/wiki/Mining_hardware_comparison

Network hashing power and luck.  In the long run, luck will tend to balance out.

The problem is that when you are "debating" with people that are desperate to impose a total government takeover of everyone else because they imagine themselves clever enough to end up on the ruling side, they have their hammer well in hand and they sure as hell aren't going to let you convince them that the screw they aren't looking at is anything but a nail.

"picked"?

util.cpp, line 386.  (0.9.0)

You've got the xxx on the wrong end.  What we have is headroom.

A guy that I talk to on IRC (friend of a friend) does quantum computing research at Caltech.  He says that the "mood" in the community is that D-Wave is actually quantum.  It wasn't so early on and they needed a lot of convincing.  I've seen similar statements online (but don't have any references handy).

But people need to keep in mind that D-wave does quantum annealing, which is different from "general" quantum computing.

A bit difficult to log something that you can't see because no one will relay, don't you think?

Blocks come in discrete lumps.  You always know how many of them you have.

http://arxiv.org/abs/1403.6676  <--  non-obscured link

While I suspect that their conclusion is correct, I really take exception to their methodology and assumptions.  Mostly, they assume that a mutation will be visible as a double spend.  However, the reference client's behavior regarding relaying transactions with degenerate signatures changed, so a sparse sensor network would likely only see the mutated transaction instead of a pair.

The accounting world will have to adapt to bitcoin.  They will not be dragging their current fiat notions into bitcoin intact.

For some strange reason, plenty of people on this forum think that the rules of accounting were handed down to Moses on Sinai and have been passed down from father to son unchanged since then.  This is, of course, nonsense.  Accounting changes all the time.

Bitcoin does what it can.  The block timestamp is the only time with any meaning for bitcoin.  If that isn't good enough for the accounting industry, they will just have to come up with something else that does.

Same goes for everyone else, pretty much.  I'm reasonably sure that the "commerce community" "needs" the "capability" to reverse transactions.  Ain't gonna happen, so they'd better get over it sooner rather than later.

P.S.  I can think of several ways to address your specific example that don't involve wishful thinking.  1)  Don't wait until the last fucking minute.  2) Accept a receipt from an audited timestamping service as the effective time.  3) Accept the timestamp of an orphaned, but otherwise valid, block as the effective time.  4) Pay more fees.

Anyone-Can-Spend is normally done with an empty scriptPubKey, not OP_TRUE.  0x51 is used to redeem it, not create it.  You can try to redeem it with OP_TRUE, but now it'll look like a double spend against the (apparently bogus) transaction already roaming the network.

Oh, and now that you've drawn attention to it, you'll be racing against bots trying to spread their own versions that spend it to their own addresses.

Input address?  What's that?  I don't remember seeing that in the specs anywhere.

Pick a random number, privkey₀.  Multiply G by privkey₀, result is pubkey₀.

Now, pubkey_i=pubkey_i-1+G and privkey_i=privkey₀+i.

So, just keep incrementing privkey and adding G to pubkey until you have as many pairs as you need.

Note that this is much less secure than actually pulling random privkeys.  It is fine in vanitygen because most of the pairs are discarded.

The secret to account safety is understanding when they are updated, and which one is getting updated.

When a new transaction comes in, all accounts are checked to see if the destination address is tagged as an account member, if any are, that account is updated, if none are, the default account is updated.

When a new spend is created, the account explicitly mentioned in the command (which is usually the default account, is updated.

When a move command is executed, the two accounts explicitly mentioned are updated.

The first two big pits that people tend to run into are:

Tagging an address into an account does not update that account with transactions already known.

The coin selector doesn't know or care about accounts.  A spend tagged with account "B" does not necessarily use a transaction that had come in to "B" before.  A spend that redeems a transaction that had come in to account "B" does not update account "B", unless you explicitly mention account "B" in the command.

Any time the question is "Accounts?" the answer is no.

Not that accounts aren't usable, or useful.  Just that if you are asking questions about them, you don't know enough about them to use them safely.

Error messages from those services tend to suck badly.

Speaking from experience, I will say that writing a varint handler for a parser is easy, and I'd be amazed if more than one of those sites got it wrong.  More likely, they are passing it to bitcoind, which is rejecting it based on the IsStandard() check, and they simply report all errors as "parsing error"s.

But please post the raw transaction here so that we can check it.

Oh dear God...  I'm having PTSD flashbacks.  You know, from the time not so long ago that this was debated, and debated, and debated, and debated, and debated...

Do you also ask this question of The Children's Cancer Foundation?  They have, after all, named their club to be confusingly similar to the disease.

Given the history of the exchanges, rather than their claims, I'm not sure that "manage" is the right word.  Or maybe "cold" is the word out of place.