Here we go again: BTCServ hacked, BTC gone

[muyuu]

[...]

Nothing. Never said its wrong, just that you can not have anonymity for Joe and traceability against the thief at the same time.

Right. Anonymity for both.

That was one of the main points of bitcoin in the first place, if you read Satoshi's paper.

Sure you did not skip through the talk I was referring. Then please read just the first sentence of https://en.bitcoin.it/wiki/Anonymity:

While the Bitcoin technology can support strong anonymity, the current implementation is usually not very anonymous.

Fact is: with the current implementation you must add additional efforts and precautions to stay anonymous. Watch the talk and understand: since the blockchain is eternal during Bitcoin's existence, you can just sit and wait until the target person makes one single mistake to loose his carefully built up anonymity.

I know how it works to some degree. I was just defending the usage of those extra steps. The fact that the blockchain is persistant doesn't change much. You just stop completely using an address that can give you trouble, there are means to this end. Addresses are free anyway, it's a matter of discipline and some effort.

[zefir]

[...]
Once a transaction makes it's way to more, then it becomes harder with each iteration.  Who's to say that the next person (or three or eight) knows that they're stolen?  As far as they know, they receive coins (or perhaps purchased/traded them) from legit means, not knowing they're stolen.. would you blame each one?  I'd guess that once it reaches 10 iterations, it's all but lost.

From a technical side, why is this a problem? The blockchain for the currently generated 166kBlocks is a 4.2GB database (gross, including redundant data). Every single address, every single coin and their transaction path from generation to their currently holding address is available. It does not really need rocket-science to parse that data and trace stolen coins.

But you're right of course when it comes to practice: after several transactions you can not blame users for holding initially stolen coins. You could if e.g. the Bitcoin nodes would check every transaction for black-listed addresses. But this would be a centralized component -- fully contrary to Bitcoin's p2p design.

[dooglus]

As a miner I would prefer that the pool sends the generated coins to itself and pays me in mature coins.  That way I don't have to wait for 120 blocks before I can spend the coins.

It doesn't make sense. You'll have to wait anyway. Either you wait with the money in your wallet, or you wait with it in the wallet of the pool operator. I find the former more secure.

I presume the pools have a buffer of mature coins which they use to pay their miners.  I don't have to wait; I can withdraw mature coins as soon as the pool finds a block.

[DeepBit]

Before posting the question I decided to take a look in the blockchain.info... and even deepbit and Slush are attributing the generation coins to a single address, possibly to transfer them after the 120 blocks maturation period. Why? This is risky... Just send them immediately to the miners.

As a miner I would prefer that the pool sends the generated coins to itself and pays me in mature coins.  That way I don't have to wait for 120 blocks before I can spend the coins.

It doesn't make sense. You'll have to wait anyway. Either you wait with the money in your wallet, or you wait with it in the wallet of the pool operator. I find the former more secure.

Actually there is some sense.
If we generate directly do user's address then he will have to wait about 20 hours (if the block is not orphaned).
If we pay in matured coins then it's only about 10 minutes.

[caveden]

I presume the pools have a buffer of mature coins which they use to pay their miners.  I don't have to wait; I can withdraw mature coins as soon as the pool finds a block.

So some pools "pay in advance". That would require them to have some "invested capital". And such money can be stolen, as we've seen here. In such event, unless the pool operator eats the loss himself, he will have to pass it to the miners.

Honestly, I find it quite absurd accepting higher risks only for not having to wait one single day for maturation. But anyway... it's your money, do as you please.

[DeepBit]

I presume the pools have a buffer of mature coins which they use to pay their miners.  I don't have to wait; I can withdraw mature coins as soon as the pool finds a block.

So some pools "pay in advance". That would require them to have some "invested capital". And such money can be stolen, as we've seen here. In such event, unless the pool operator eats the loss himself, he will have to pass it to the miners.

Honestly, I find it quite absurd accepting higher risks only for not having to wait one single day for maturation. But anyway... it's your money, do as you please.

I think that most non-0% pools do. It would be very strange to receive payments that you still can't use for almost a day

As for the possible theft... It's not a user's problem. Pool should pay anyway.

[runeks]

Honestly, I find it quite absurd accepting higher risks only for not having to wait one single day for maturation. But anyway... it's your money, do as you please.

Seems to me pool users are paying for ease of use (or rather: less setting up required) and low variation.