I guess I should have made it clear that I was talking to the tool that started the thread and thinks that his opinion should be binding on everyone else, not whichever random person posted just before me.

If you send the change back to one of the input addresses, you end up being a tiny bit less secure, and quite a bit less semi-anonymous.  And you really gain nothing by doing it that way.  Keys are small, and tracking many of them is not hard.

What people really should be asking is how they can make the client look for inputs that allow the spend and the change to be roughly the same size, to make it harder for a snooper to tell which was which.

Use BC.


It is in POSIX, so libraries can be found for just about any language or platform.  Here is a PHP example:

Can you just shut the fuck up already?

They created the exchange, they own it, they operate it, they get to make the decisions for it, not you.  If you don't like that, you can go make your own exchange and set whatever policies you want for it.  If you are right that bots are bad, people will flock to your botless exchange.

You are making the very common mistake of thinking in terms of addresses.

Addresses do not have balances.  Spends do not come from addresses.

Spends come from transaction outputs.  Transaction outputs must be redeemed all at once, never partially.

In your example, if you have a balance of 10 btc and you send 1, your client will look through the list of transaction outputs that it has the keys for and it will select a subset of those outputs that adds up to at least 1 (the amount you want to send).  It then makes a new transaction using that entire subset as the input, and with 2 outputs*:  one for the recipient, and the other for the change.  In the client as it is today, the change always goes to a fresh key (address).  If the client can't find a spare key in the wallet file, it creates a new one.  If it can't write that new key to the file, you just lost whatever the change would have been.  If your 10 btc balance had been from a single transaction, you just lost 9 btc.  Forever.  If the client crashes too, that was just a bonus.

Come up with a better way to track your balance.

* I'm ignoring two special cases that don't really change the process much.  The first is if the client just happens through random luck to find exactly the right amount so that it doesn't need to make any change.  The other is if transaction fees are needed.

The idea that 90% of the mining power would disappear at once is pretty silly.  The literal end of the world would be more likely.

But, if it ever did happen, the remaining 10% would have plenty of time to agree to a change of algorithm and update their clients.

And yes, this have been discussed many, many times before, in dozens if not hundreds of threads.

People need to understand that this step is very important, and should not be delegated lightly.

You need to narrow your quoting window.  You really should automate your trades on the exchanges too.

With the wild swings in the market, you really should be quoting live rates, or use a 15 minute window.  Maybe an hour, tops.  If your quoted price is different from the live prices on the exchanges, people will use you for arbitrage.  Since your operation is a way to go from bitcoins (liquid) to physical goods (not liquid), you won't have big operators cycling through you over and over again, but people that want to use your service will do it when it favors them, and wait when it doesn't.  Not absolutely, of course, but there will be a bias, and that bias is already big enough to make your site unprofitable.

Automated trading will limit your exchange losses.  Just sell them the instant that you get them, for the best price that you can get.  The exchanges have APIs that make this pretty easy.

Resist the temptation to speculate with them.  Either you don't know what you are doing and will take unnecessary losses, or you do know what you are doing and really should keep that activity separate.

The nice part about EVE is that the main method for sending money around is a "Donate" button.  That might be a nice feature in the bitcoin client.

1.  I'm well aware of the difference.

2.  No, I haven't misrepresented anything of the sort, mostly because I haven't said anything about people criticizing anything.  I'm also well aware of the history of paper money.

Generally speaking, people that know enough about our monetary system to criticize it don't need me to explain basic concepts like what "backs" the dollar.

Did you run that past a cryptographer first?  I haven't read FIPS 186-3 in detail, but I seem to recall that ECDSA keypair generation involved more than tossing a bunch of bits together.

Also, did you test this?

A decent mixer could sort this out, but those have been big targets historically (see anon.penet.fi).

Also, I don't think that real anonymity is a show stopper.  Most of us would like it if it were there, but very few applications have it as a hard requirement.

Don't most profiling tools have options to explicitly flush read caches before runs, for just this reason?

Problem number 1 is highlighted.

Problem number 2 is that this will enable bigger scams, for the low, low price of whatever your joining fee is.

Latency.  It always adds.

Yes.

While we are at it, there is no requirement that the price of the last execution be bounded by the current ask/bid spread.

Well, since you know what T+2 means, I guess I'm sorta wondering why you don't also know what "settle" means.

Wow, you screwed up ordering something for free, and it triggered a nasty case of nerd rage.  Go get yourself a beer or something.

My first thought was an alert message.  Presumably Satoshi had the exact same idea years ago.

The maintainers could generate a key pair for each release, with the public key embedded in each client.  If a critical bug is found in some client, the maintainer signs a message telling the node to notify the operator.  If the message is informational only, and has some anti-spam provisions (embed the message in a transaction sig?), it should be pretty widely accepted by the community.  Each node operator then has the choice of how they want to handle the message.

If I was running a store, and the devs found a critical bug that made my client unreliable, I would set up a handler that disabled my store first, and paged me second.  Operators that ignored the messages would do so at their peril.  Having a deep reorg trigger the same exception handler would be good too.

Theymos is right that having a higher barrier for deep reorgs would allow an attacker to maintain control over some nodes for a longer time (or forever), but under my scenario, those are the nodes with careless operators, which is their own fault.  I'm all in favor of protecting all nodes, even those with careless operators, when it happens for free.  But I'd throw half of the network under the bus if it made the remaining half twice as secure.  Hell, I'm almost at the point where I'd be willing to do it just to stop all of the "51%" threads here.