On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn <[email protected]> wrote: > Lately someone launched Finney attacks as a service (BitUndo). As a reminder > for newcomers, Finney attacks are where a miner secretly works on a block > containing a double spend.
Hm? I didn't think this is at all what they did. What they claim to do is to prioritize transactions in their mempool from people who pay them, potentially over and above other transactions which they may or may not have received first. This may still be bad news for someone taking an irreversible action in response to an unconfirmed payment and it may or may not be really ill advised in general, but I think it's less sinister than it sounds in your posts. Is there some reason to believe it isn't what it claims to be? I think we have very clear evidence that the Bitcoin community doesn't care if miners reorder transactions in their mempool to profitable ends: In https://bitcointalk.org/index.php?topic=327767.0 it's demonstrated that GHash.IO, currently the largest publicly identified pool was used to rip off Betcoin dice via double-spends. > first started using Bitcoin, nowadays most of my purchases with it are for > food and drink. If Bitcoin could not support such purchases, I would use it > much less. Accepting zero-conf inherently has some risk (well, so does all business, but there is substantially more in a zero-conf payment). Even in a spherical-cow Bitcoin absent anything like Bitundo someone can just give a double spend to a large miner and currently give the whole rest of the network the one paying the merchant. They will, with high success rate be successful. Worse, it may _appear_ to the network that the miner was a "bitundo" but they really were not. The blockchain exists to establish consensus ordering, prior to the blockchain there is no order, and so it is not easy to really say which transaction came first in any meaningful sense. But in business we balance risks and the risk that sometimes a transaction will be reversed exists in every electronic payment system available today, in most of them the risk persists for _months_ rather than minutes. Businesses can still operate in the face of these risks. More importantly, it's possible to deploy technological approaches to make zero-conf very secure against reversal: Things like performing multi-sig with a anti-double-spending system, or using an external federated payment network... but this stuff requires substantial development work— though it's not work thats likely to happen if people are still confused about the level of security that zero-conf has. > Miners can vote to reallocate the coinbase value of bad blocks before they > mature. I think miners 'voting' to reallocate coins, even if they're thoroughly convinced that the owner of the coins is a nasty party, is a much greater violation of the Bitcoin social contract than some twiddling with the unspecified unconfirmed transaction ordering. Doubly so because a 'nasty' party with non-trivial hash-power can doublespend their own transactions with a pretty good success rate (as was the case for the GHash.io betcoin spends) including not-just zero-conf (though with obviously reduced effectiveness), and all of your reliable detection depends on it being a public service. A much better defense is having the control of hash power very well distributed and so there isn't any central point that excerts enough influence to change the risk statistics much. Giving miners the ability to steal each others payments is, if anything, a force away from that decentralization. ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Bitcoin-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bitcoin-development
