Flexcoin announced a security breach today, so: Bump. Guys, using or telling people to use an Online Wallet Service is Not Okay. Not MyBitcoin, not Flexcoin, not StrongCoin, not Coinbase. The only reason a web site should ever have access to your bitcoins is if that website sold them to you, in which case you should transfer them to your own wallet prompty, or if you are using them to pay that website for something, in which case you shouldn't be expecting them back.

CoinExchanger, you're making yourself look bad. MtGox has its share of problems, but in this case it's just following the law. Someone or some algorithm in the law enforcement world decided that sergio's account looked suspicious, and froze it. To get it unfrozen, sergio would have to submit a copy of his ID. Instead of sending ID, he claimed he didn't have any, and sent a receipt showing that he'd requested an ID. This probably means that he isn't willing to link the account to his real identity. So his funds are still frozen, and here he is complaining that MtGox won't break the law for him. Boo hoo.

This is a Dollar Auction pretending to be a game show.

If you can send a coin to an arbitrary address, you can send it to yourself to remove any restrictions. If you can't send it to an arbitrary address, then it's not a Bitcoin and existing vendors won't accept it. This works out the same as if a government created a new currency on a separate blockchain, and offered to trade it for bitcoins. It might catch on, but it would be less valuable than Bitcoins and people probably wouldn't get them confused.

I previously wrote "CODEHASHCHECK is arguably better, but only slightly". After reading Gavin's comment and the linked patch, I take that back. Introducing a non-stack interaction between scriptSig and scriptPubKey is a bad idea and a big deal, much moreso than special-case matching a script is.

I recall seeing some mention in this forum that MyBitcoin doesn't follow the usual coin-selection and change-making rules, presumably because its Bitcoin-handling code was custom-written; and that it shuffles coins around between its own addresses. Given this list of addresses, it should be possible to learn some things about it; and I strongly suspect that its transactions are distinctive in some way, which should make it possible to find *all* the MyBitcoin addresses.

Another theory - the reason MyBitcoin came back briefly and returned some coins, was to get plausible deniability when spending the coins that were stolen.

Epoch: The problem this is solving is M-of-N multi-key addresses. It lets you set up your wallet so that there are multiple keys, stored in different places - for example, one on your computer, one on your smartphone, and one in a safe - and require that several of them be used together in order to spend coins. That way, if your computer is compromised, the attacker can't steal your coins without also compromising one of the other keys. This feature is extremely important; it would have prevented the allinvain attack, it allows corporations to hold coins without having to completely trust any one employee, and it makes escrow work better. Implementation has to be done in two stages - first adding support for it in the protocol, then second adding support for it in the user interface. We're currently on the first part, and talking about the relative merits of different ways of doing it. All of the proposals currently on the table are protocol changes that enable M-of-N multi-key addresses, and pretty much everyone agrees that at least one of the proposals must be adopted.

This would've been a lot better received if it was brought up while the technical discussions were still ongoing. I originally proposed something like OP_EVAL in https://bitcointalk.org/index.php?topic=46429, and I think P2SH achieves everything I wanted out of that. CODEHASHCHECK is arguably better, but only slightly - certainly not by enough to justify delaying deployment. Getting some sort of multisig transactions working is rather urgent, and P2SH is the implementation we have, and it carefully avoids opening any cans of worms.

What this really seems to be about is politics - LukeJr is uncomfortable with Gavin having the power to alter the Bitcoin protocol. I think that this power should be phased out eventually--but not yet. We'll mark that transition with a "1.0" version number. We still need protocol improvements. Gavin's shown no indication that he'd ever abuse his position, and he's the only one who's actually putting in the work required. And this is a really bad time to start a power struggle, because LukeJr isn't really going against Gavin - he's going against the output of a community discussion which he didn't take part in.

(As for the technical side - the issue seems to be that P2SH introduces a new interaction between the concept of "standard transactions" and the scripting system. Before, a transaction would be accepted if it was standard and the script returned success; now there's an additional requirement, which is that one of the standard transaction types now calls for you to rerun the script in a different way. This means that the "standard transactions" concept is now actually part of the scripting system, rather than a secondary sanity check, so it can't be fully dropped in the future. However, the special case is on the sender-script side, and I don't think allowing nonstandard scripts there was ever plausibly a good idea. I do still want to see the standard-transaction types broadened to include fancy tricks with time locking, but that's considerably less urgent.)

MyBitcoin having been a scam was obvious, but it's good to finally remove all doubt. If MyBitcoin really had been hacked, there wouldn't be any old coins stored in their receiving addresses; they would've either been transferred to a different address by the attacker, or transferred to a different address by MyBitcoin's operator, a long time ago. Unfortunately, this transaction probably involves coins being sent to a coin-mixing service, rather than directly to something linked to an identity.

(Also interesting: those addresses weren't completely cleaned out; they still have a few coins in them, after the recent withdrawals.)

It might not have been "fake" per se, but rather, insulin that was left in the sun or otherwise improperly stored. Still quite serious, but how serious it is depends on whether he knew it was spoiled or not, which is hard to prove. (This sort of thing is why you need a license to sell prescription drugs, by the way.)

I think the correct solution to this is proper import/export options in the GUI. The current business of finding a fixed-path file and switching it out is really counterintuitive. and doesn't work very well.

Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.

Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.

This is multi-key escrow. I believe the blockchain supports it now, with current clients, although there's no GUI support. Ideally you'd use three keys: Alice's key, Bob's key, and a third-party judge's key, such that two of the keys together could release the funds. That way, an anonymous sender couldn't break his agreement and use the threat of withholding funds as leverage.

The reason for connecting to many peers is for security. If you connect to only a few peers, or you design your peer-finding system poorly, an attacker might arrange things so that all of your connections were to computers that he controlled. Then he'd be able to hide published blocks from you, and to send blocks and transactions to you that don't reach the rest of the network. This would allow him to mount something sort of like a 51% attack, but with much less computing power.

In other words, the peer-finding algorithm is security-critical, so you shouldn't mess with it unless you know exactly what you're doing. The transaction and block relaying algorithms are, too, by the way; if a large fraction of the network stopped relaying because they wanted to be lightweight, then 125 connections might not be enough to stay safe anymore.

What!? Nonono, that would be a bad outcome, to be avoided if at all possible! There are lots of threats against browser-based programs that don't apply to desktop apps. And if there's 2-device authentication, then it's much easier to compromise a matching pair if both clients are in a browser; they're more likely to have vulnerabilities in common. For example, someone could steal an SSL certificate, and MITM traffic on the internet connection that both devices share, replacing both clients with malicious software.

Please, reconsider. The future of Bitcoin depends on there not being any more MyBitcoins or Allinvains. I wrote that online wallet services are an invitation to fraud and theft, a month before the MyBitcoin fiasco. That is still true. Don't encourage people to use them, or there will be more disasters.

joeyjoe, there are extremely good theoretical and practical reasons to think that safely handling bitcoins using a compromised computer is impossible, no matter what tricks you use to protect them, and that this issue is fundamentally impossible to fix. While you can write software which makes stealing bitcoins inconvenient, the only true defenses are (a) keeping your computer secure, and (b) incorporating multiple devices, such as by using multi-signature transactions (coming in a future version).

Various tricks have been proposed for doing protected computation in non-bitcoin contexts, and it always ends up being an arms race with the bad guys having a substantial advantage. Things like using a TPM, hiding the keys behind interprocess communication, in-memory encryption, and device fingerprinting only help a little.

You shouldn't assume that because your teacher hasn't shot you down, that your plan will work. Experts in cryptography often propose schemes that are later proven not to work, and this happens so often that it's considered poor form to advertise anything as truly secure until it's been published and peer reviewed for a fairly long time.

Thanks for all your hard work! But does this being a release candidate mean that multi-sigs/receiver-scripts won't be available on testnet until 0.6 or later?

Related discussions in https://bitcointalk.org/index.php?topic=46429.0, https://bitcointalk.org/index.php?topic=45211.0, https://bitcointalk.org/index.php?topic=46538.0. The basic idea - allowing more-complex scripts to control the conditions under which coins are released - is good. However, I prefer the versions that keep the address format the same, or at least very similar. Allowing complicated addresses puts burden on Bitcoin-handling web sites and breaks compatibility in ways that it doesn't need to be broken.

Actually, I think this is considerably more urgent than that. Right now, it's impossible to safely hold corporate-scale amounts of money in Bitcoin, because corporations can't trust any one person with unrestricted spending power. Botnets have started introducing wallet-harvesting as a standard feature, and the encrypted wallets are not a defense because they had password-keylogging was a standard feature already. Every large theft deals major damage to Bitcoin's reputation, and if it takes too long to add security features, the damage will be irreparable.

There is going to be an unavoidable delay between hammering out the details of this proposal/group of proposals, and introduction on testnet; another delay between introduction on testnet and introduction to the main client; and then another delay between introduction to the main client and activation in the blockchain to allow miners time to get up to date. These delays are important, but remember that the thing we want to maximize is thought, not time; and there are better ways to get more people thinking about these issues than just waiting. Once the details are hammered out and there's a testnet implementation (which I see little reason *not* to rush; it's only testnet), then it'll be time to summon as much security-researcher attention to it as possible.

We could guarantee that a transaction stays valid even if it's moved to a later block; how about instead of OP_BLOCKTIME and OP_UNIXTIME, make OP_BLOCKTIME_CHECK and OP_UNIXTIME_CHECK, fusing pushing the time and failing if it's too early together? They could still be skipped over by conditionals, so you can do the complicated realistic stuff, but you couldn't write a script that ever transitioned from valid to invalid with those opcodes.

But I actually think keeping the transaction associated with its block, and determining its validity that way, is better. You could make a receiving address with rules like "may be claimed by A within 72 hours; goes to B otherwise".