Quote from: Stephen Gornick on July 28, 2012, 06:29:34 AM

So presumably you are considering this only for double spending where the spend in one branch of the fork contradicts the spend in another branch.

Yes, that's correct. It's a thought experiment about penalizing double-spends visible to the network in too-short a time frame by removing the coins from circulation. Roughly how it would work is right now, miners have to choose one of the double spend transactions to hash into their chain. I am proposing adding the ability to hash BOTH double spend transactions into the same chain with the net effect of making the coins disappear and for miners to prefer building off of blocks that black-hole double-spends. Innocents could be harmed, but attackers would have less incentive to Finney attack this way. I'm not sold on it, but I haven't been convinced its definitely a bad idea yet.

Quote from: Stephen Gornick on July 28, 2012, 06:29:34 AM

Not all double spends attempts are intentional even. Take the scenario where someone who imports their private key from a wallet.dat into Blockchain.info, for example, and then spends the one in blockchain.info. Then the bitcoin-qt is launched but it hasn't caught up on the blockchain and a payment is sent, which happens to spend the coin that was transferred to blockchain.info. That would be a double spend. That can happen seconds apart or months apart.

This is true, and is one of the potential drawbacks of the approach I'm considering. However, it already is possible to lose coins, and it seems to me that appropriate windowing (e.g. only possible for a miner to black-hole a transaction while there's less than 'x' blocks chained on top of it, where x is probably < 18) would address at least the 'months apart' instances of the unintentional case.

Quote from: Stephen Gornick on July 28, 2012, 06:29:34 AM

Your black-holing means bitcoins are no longer fungible. Innocents will be harmed. That's bad.

It's true that this reduces fungibility, but it applies only to a situation where fungibility is already bent a bit (an attempted double spend). We already expect users to exercise due diligence with respect to private key management, and it seems to me that a similar notion of responsibility could hold in this hypothetical case.

Thanks for the serious response Stephen, I'm most grateful.

-bgc