Thermal throttling.

Right, so you wouldn't ship a product until the chargeback window had closed. But the advantage would be if some guy calls you up and says "I sent you 50 bitcoins, where's my XYZZY?" you say "I have no record. Charge it back or send us proof we accepted your payment."

Or, "I accidentally sent you 100 bitcoins instead of 1.00, here's the record, send them back to this address". What do you do? You don't want to steal from someone who sent you money by mistake, but you don't want to risk the next call asking you to send them back to some other address.

This type of chargeback is a great idea. I recently posted a suggestion to add support for them to bitcoin and to make transactions truly anonymous at the same time. (Admittedly, it also had some downsides.)

Pass bitcoin a '-nolisten' flag on the command line when you start it.

If you initiate a transaction, wait a few hours, and the transaction doesn't appear in block explorer, then the coins weren't sent. Placing a transaction in the public hash chain is essentially the definition of "sent" in this context.

Say you set up such a system, and the price on that system goes to $18. As soon as there's nobody left whose willing to pay $18 for a bitcoin, and some guy on some other system starts offering them for $17, nobody would trade on that system.

You can't sell something for more than it's worth unless you can keep a ready supply of suckers.

Also, what does "total loss of my Internet connection" mean? Does it mean you can still reach your router but can't reach Internet sites? Does it mean you've lost your wireless link? Does it mean your Ethernet port's connection light goes out?

Your concern is valid. It would be very difficult to enter into a long term transaction today that was denominated in bitcoins. There's a non-negligible risk that in three years bitcoins as we know them today will no longer exist as a means of exchange.

The only thing I can think of, which likely would defeat the entire purpose of whatever you're doing, would be to have a backup clause. The backup clause would say that the contract switches to being denominated in dollars if bitcoins are no longer actively exchangeable for US dollars (or whatever currency is appropriate for you) between a certain set of exchange rates (say $1 to $1,000).

First, punch his address into block explorer and make sure you see the transaction. You can also note the block number of the transaction.

Second, make sure his client has downloaded all the blocks (138,691 as of now). This can take 8 hours or so when you first install it. The client cannot see any transactions in blocks after the last block it has processed.

Here we see a master of the "praise with faint damn" technique. I bow to you, sir.

If you mean the same as her husband, then yes.

I'm not hostile to Paxum either, and I don't think Paxum is trying to defraud anyone. I wouldn't read as much into these particular issues as ErgoOne seems to.

But I will say one thing from my own experience: It is very easy for non-technical people to assume that because someone knows how to do something and make it work, they also know how to make it secure. And it's easy to assume that because nothing bad has happened for awhile, your system must be at least reasonably secure. And it's easy to assume that because a system is growing, it's also growing more secure -- surely someone's doing that, right? However, these three assumptions are entirely false.

This is especially true for innovative companies that experience fast growth. Mt. Gox, for example.

A small anecdote: The last breach I helped clean up involved a software defect that could have leaked a small, growing company's entire customer and transaction database. The programmer whose code had the bug knew that his code had this type of bug, but he believed it was too difficult to exploit because he didn't know an easy way to exploit it. He, of course, was not a computer security person, so he had no idea that there are toolkits available that make exploiting bugs of this type extremely easy.

And one final point: If you ask these people if they take security seriously and if their code is secure, they will say yes because they honestly believe that they are. And they believe there's no need for other people to audit them. When they see how many vulnerabilities there are and how easy they are to exploit, they are frequently quite surprised. People who aren't security experts just don't understand what the threats actually are.

In theory, yes, but this is very difficult in practice. Unlike most other businesses, you can complete your transaction with an exchange in minutes -- get in cash, buy Bitcoins, and irreversibly ship them out. If the incoming funds weren't good, there is no recovery for the exchange. And the stolen money can be across the planet in minutes. So it's a choice target for fraudsters.

A bitcoin exchange that tried to do this themselves would have to have the very most advanced fraud controls in the financial industry, because they'd be the perfect target. And balancing out all those costs, they'd have only the volume of their share of the bitcoin market.

These are very typical of the issues you have when a service goes live, especially when external events force your timing. I bet these will all be sorted out within a week at most.

Fraud. ACH transactions can be reversed weeks later with a claim that the owner of the account didn't authorize the transaction. The middle man confirms that the transaction is authorized by the account holder, handles the ACH disputes, and eats the cost if it turns out the transfer was fraudulent.

I remember specifically thinking, when I placed the code, that the code held a lock that wouldn't let the 'getwork' code run until it was safe anyway. But then I looked back after I got the patch from Giel, and I couldn't figure out what I saw that justified that belief.

If this mechanism is being seriously considered, someone needs to make sure it's not encumbered by a patent. I remember when I first heard the notion of a "family of public keys" such that a single private key would allow deriving the corresponding family of private keys, I seem to recall it being patented. That was at least three years ago, I think, so it may not even be covered any more.

You can do even better than that. You can send bitcoins in such a way that a "code phrase" (like 'My plaid socks don't fit me well!') unlocks them. (The client doesn't provide an easy way to do it, but that's an easy fix.)

The could make a client they could corrupt say whatever they want, but they can't make non-corrupt clients honor it.

That smallish group of individuals only has control because nobody has a reason to wrest it from them. If that group refused to accept needed improvements, added changes that defeat the spirit of bitgoin, or even just fail to keep up with competing technologies, others would simply switch to a competing project and/or nodes would just refuse to upgrade. To prevent that mechanism from working would require an almost totalitarian restriction on people's ability to communicate.

Wasn't Octav Moise the guy behind the 'Vimax' (penis enlargement patch) affiliate program that littered the Internet with web pages using the words "Vimax" and "scam" prominently so that people searching for "is vimax a scam" would find hundreds of pages that said it wasn't?