Angry about Linode's fiasco? Start mining at a pool supporting multisig!

[m0mchil]

There are features already implemented which will make the recent heist a nightmare of the past. The problem is they can't be deployed before the majority of hashing power agrees.

I am not vouching for a particular one - just trying to convince you that you should start mining at a pool supporting any of the solutions.

Unfortunately Deepbit is currently supporting NONE of them.


http://blockchain.info/p2sh

[1714194705]

1714194705

[1714194705]

1714194705

[1714194705]

1714194705

[1714194705]

1714194705

[Kluge]

Wouldn't wallet encryption, which is already implemented, have made this a nightmare of the past? (honest question, not trying to be a dick)

[Sukrim]

Or other security measures, like paper/deterministic/offline wallets?

I don't know much about bitcoinica, maybe these 40k bitcoins even were just the daily "play money" and the real funds were anyways securely stashed away...

[BkkCoins]

Wouldn't wallet encryption, which is already implemented, have made this a nightmare of the past? (honest question, not trying to be a dick)

I don't think so as wallet encryption in an automated system would still have required the password to be placed in some script to function. Even if it required sysadmin intervention after reboot to init a password there would still be a running process with access privileges. While it may be harder to hijack that a user (hacker) who has gained root could likely manage it. I'm not even sure the bitcoind  rpc calls are limited to the process that unlocked the wallet since it may not even be able to tell which process made an rpc request. It may be as simple as polling the rpc calls until a valid  request unlocks it and then firing a malicious request.

I would think a more defensive approach would be only maintaining enough bitcoin in an active wallet to handle X minutes demand activity and transfer excess receipts to an offline address. Any demand in excess of average could fire an SMS message to a sysadmin who would use an offline wallet to topup the active wallet.

Security is not only about protecting access but also about limiting damage.

Edit: It's also conceivable to build traps into the system. eg. On a hardened system (with properly configured sudoers) root login should never be needed in daily activity so if root ever logs in the wallet could be immediately shredded such that a legitimate sysadmin must audit the system and re-init the wallet from an offline backup.

[FlipPro]

Furious.

[Sukrim]

Yes, offline wallets + transactions would be more useful imho.

1 Bitcoin node (A) that collects incoming coins + outgoing requests.
1 Bitcoin node (B) completely offline.

Every x minutes, A puts on an USB stick: Current blockchain (can be just a delta from the last time...), outgoing transactions to be confirmed, transaction to send all incoming coins to a address controlled by B

B then gets just this data, someone looks over it, if it seems legit and if it is so, B signs the payout transactions on the USB stick. A imports these and broadcasts them to the network.

Refinements could be that X transactions below Y BTC don't require confirmation and are paid from the "hot" wallet or similar.

Multisig would just mean that you need to compromise more internet machines than one and that you are screwed if you require a signature from a device that has gone belly up.
multisig also looks easier to DoS to me...

[mrb]

I don't think so as wallet encryption in an automated system would still have required the password to be placed in some script to function. Even if it required sysadmin intervention after reboot to init a password there would still be a running process with access privileges.

The obvious solution is for Bitcoin exchanges to implement, on the server-side, one encrypted wallet per user. The site's password can be used as the passphrase. And tie the whole thing to the authenticated web session.

So that when you log in the server stores the passphrase in memory to access the wallet when necessary. And when you log out or when your session expires your wallet is re-encrypted to remain secure on the server, and the server securely erases the passphrase from memory.

That way, if an attacker gains access to the server, he would only be able to steal the money from users currently logged into Bitcoinica by stealing passphrases from memory, while the majority of the rest of the funds would be secure.

[Sukrim]

That would just mean, you need a more persistent exploit that waits until a wallet gets decrypted and then sends all it's funds to some address. Less efficient, yes but it still might take a while until this comes out, especially if the backend shows no loss in balance or if you can make it look like a user initiated payout.

Why would I need to log on to deposit after the first time, if I then know at least 1 address from my own private wallet?

[mrb]

That would just mean, you need a more persistent exploit that waits until a wallet gets decrypted and then sends all it's funds to some address. Less efficient, yes but it still might take a while until this comes out, especially if the backend shows no loss in balance or if you can make it look like a user initiated payout.

Correct. My method would just raise the bar for a successful, massive theft. It is an application of the "defense in depth" concept.

Why would I need to log on to deposit after the first time, if I then know at least 1 address from my own private wallet?

No need to log on (of course, duh!) I edited my post.

[torservers]

Sorry to say this, but, no matter what, it is simply not excusable to keep a large amount like that on off-the-shelf virtual servers.

[memvola]

Wouldn't wallet encryption, which is already implemented, have made this a nightmare of the past? (honest question, not trying to be a dick)

It would make the theft a tad harder in this specific case (change a few lines of code or run a hidden process) but probably wouldn't have prevented it. However if the servers were rooted without having to boot, or access to live bitcoind were gained by other means, it wouldn't have any more benefit. As others have said, polling the main server from a secure machine and generating transactions after a sanity check would definitely help. On the other hand, multisig transactions are general purpose and would conform with very different usage scenarios than the ones addressed here, so I guess having them in place as soon as possible is desirable.

[Technomage]

Encryption would have been a saviour in this case because the exploit required a reboot of the servers in question. But multisig would allow to setup an even more secure system.

Gavin posted about this in his blog and explained one way of doing it (regarding the faucet): http://gavintech.blogspot.com/2012/03/bitcoin-faucet-hacked.html

Currently P2SH support is around 36%, all we need is Deepbit support and it's done. I hope Tycho finally gives in. This feature IS needed.

[BkkCoins]

It hasn't been stated anywhere (that I've seen) but I wonder if the reboot was required because the "customer service portal" is like KVM access that allows recovery access during the boot process. The recovery mode can be used to gain root on any linux os unless it's explicitly disabled.

I suspect that for super-admin purposes they would be unlikely to disable that mode - in which case, even if they have taken added steps to try and secure access to the "portal", the underlying problem is still present and Bitcoin sys admins would want to be very, very careful about using any VPS where KVM style access is available to "unknowable / unaccountable" admins.

[Gabi]

Mine at p2pool, you won't lose your btc because you mine them on your address

[memvola]

Mine at p2pool, you won't lose your btc because you mine them on your address

Good that you said that. What's the most straightforward way for local or p2pool miners to start supporting p2sh?

[Raize]

Unfortunately Deepbit is currently supporting NONE of them.

Tycho has expressed his opinion several times on the forums. Because he is the biggest pool he CANNOT make a decision, if he does, and the majority of miners vote against him, he runs the risk of forcing a fork of the blockchain and then being the biggest miner on the new blockchain, meaning he'd be mining useless coin (the blockchain would be subject to 50% attacks regularly and no one would want to use it).

Tycho seems to have made it known that he'll wait till BIP16 or BIP17 has a clear majority, and then follow suit accordingly with the majority opinion.

[memvola]

If you are mining at P2Pool or solo, run bitcoind with the correct patch to vote for BIP16.

OK, from the code, it seems the official main branch accepts the -bip16 parameter and you don't need to apply a patch. I did it, so hopefully I'm supporting now. I wish it was apparent without looking, nobody cares about solo miners anymore.

[MacRohard]

There are features already implemented which will make the recent heist a nightmare of the past. The problem is they can't be deployed before the majority of hashing power agrees.

I am not vouching for a particular one - just trying to convince you that you should start mining at a pool supporting any of the solutions.

Unfortunately Deepbit is currently supporting NONE of them.


http://blockchain.info/p2sh

This isn't really true. Multisig will not stop bitcoins from being stolen. If it's an online wallet that supports automated withdrawl then hackers can just do whatever the application normally does to process withdrawls. Maybe the webapp makes an rpc call to some other server to process the second signature.. fine, you just do that. easy. If you can make automated/instant withdrawls then so can a hacker - there's no way around this fundamental issue.

[compro01]

Yes, offline wallets + transactions would be more useful imho.

1 Bitcoin node (A) that collects incoming coins + outgoing requests.
1 Bitcoin node (B) completely offline.

Every x minutes, A puts on an USB stick: Current blockchain (can be just a delta from the last time...), outgoing transactions to be confirmed, transaction to send all incoming coins to a address controlled by B

B then gets just this data, someone looks over it, if it seems legit and if it is so, B signs the payout transactions on the USB stick. A imports these and broadcasts them to the network.

Refinements could be that X transactions below Y BTC don't require confirmation and are paid from the "hot" wallet or similar.

Multisig would just mean that you need to compromise more internet machines than one and that you are screwed if you require a signature from a device that has gone belly up.
multisig also looks easier to DoS to me...

Yeah, Bitcoinica did do that.  it was their hot wallet that got cleaned out.

[nybble41]

If it's an online wallet that supports automated withdrawl then hackers can just do whatever the application normally does to process withdrawls. Maybe the webapp makes an rpc call to some other server to process the second signature.. fine, you just do that. easy. If you can make automated/instant withdrawls then so can a hacker - there's no way around this fundamental issue.

True, you wouldn't want to just expose "withdraw X bitcoins to address Y" as an RPC call. You need to tie the withdrawals to specific accounts and validate the amount against the account balance so that no one RPC call can wipe out the entire wallet.

Ideally, you would have one or more cheap, low-security systems to handle the front-end traffic. These systems would not hold any private keys or sensitive customer databases. A separate, secure, low-traffic system would deal with authenticating users and withdrawing coins (or you could use two separate servers). Authentication should include some form of challenge-response protocol (e.g. a public-key certificate) or one-time password to avoid exposing the user's credentials to anyone breaking into the front-end server.

When someone logs in, their credentials would be forwarded to the authentication server, which would then issue a time-limited one-time authentication token. When they want to withdraw money from their account, the front-end server would send that token, the amount, and the destination address to the secure wallet server, which would validate the token and the amount and then sign a transaction to send the coins to the destination address. A compromise of the front-end systems would expose, at most, the balances of those accounts which were active at the time.

For even better security, you could require the login credentials to be re-entered for each withdrawal (limiting the exposure to those accounts making withdrawals), and/or only allow withdrawal to pre-registered addresses. This last option is more cumbersome, but it also almost completely eliminates the incentive to break in to the front-end systems, leaving only the more hardened secure servers as a worthwhile target.