From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd2M1-0001Jx-I4 for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:57:09 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.181 as permitted sender) client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f181.google.com; Received: from mail-lb0-f181.google.com ([209.85.217.181]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd2M0-0004We-EB for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 18:57:09 +0000 Received: by mail-lb0-f181.google.com with SMTP id c11so1125554lbj.26 for ; Wed, 23 Apr 2014 11:57:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.87.71 with SMTP id v7mr37104218laz.10.1398279421697; Wed, 23 Apr 2014 11:57:01 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 11:57:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 11:57:01 -0700 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Wd2M0-0004We-EB Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 18:57:09 -0000 On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn wrote: > Lately someone launched Finney attacks as a service (BitUndo). As a remin= der > 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=3D327767.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 fo= r > 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=E2=80=94 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 the= y > 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.