From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd37T-0000vb-4U for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:46:11 +0000 X-ACL-Warn: Received: from p3plsmtpa09-04.prod.phx3.secureserver.net ([173.201.193.233]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Wd37R-0003Bq-IW for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 19:46:11 +0000 Received: from [192.168.0.23] ([201.231.95.129]) by p3plsmtpa09-04.prod.phx3.secureserver.net with id tXZP1n00X2nUpUh01XZRgS; Wed, 23 Apr 2014 12:33:27 -0700 Message-ID: <53581584.307@certimix.com> Date: Wed, 23 Apr 2014 16:33:24 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: bitcoin-development References: <20140423152954.GG19430@savin> In-Reply-To: <20140423152954.GG19430@savin> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [173.201.193.233 listed in list.dnswl.org] X-Headers-End: 1Wd37R-0003Bq-IW Cc: bitcoin-research@lists.cs.princeton.edu 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 19:46:11 -0000 (this e-mail is cc to the bitcoin-research list) Hi everyone from the bitcoin-development mailing list! I decided to join this legendary list because it seems that all the research fun is taking place in here, and I don't want to miss the research party. Regarding the discussion about BitUndo, a year ago I posted about an attack (which I called the the Bitcoin Eternal Choice for the Dark Side Attack or ECDSA) that tries to erode the confidence in Bitcoin by offering double-spends as a service. I think it's related to the last post from Peter Todd about the problems with BitUndo. Here is the link if anyone is interested in reading about it... http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/ Sergio D. Lerner. On 23/04/2014 12:29 p.m., Peter Todd wrote: > Interesting discussion re: incentive compatibility happening on the > bitcoin-development email list: > > ----- Forwarded message from Mike Hearn ----- > > Date: Wed, 23 Apr 2014 09:55:30 +0200 > From: Mike Hearn > To: Bitcoin Dev > Subject: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks > > 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. When they eventually find a block, they > run to the merchant and pay, then broadcast the block. In a simpler variant > of this attack you make purchases as normal with a modified wallet that > always submits a double spend to the service, and then N% of the time where > N is the percentage of overall hash power the dishonest miners have, you > get your money back minus their fee. > > N does not need to be very high to render Bitcoin much less useful. Real > time transactions are very important. Although I never expected it when I > 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. > Even with their woeful security many merchants see <1-2% credit card > chargeback rates, and chargebacks can be disputed. In fact merchants win > about 40% of chargeback disputes. So if N was only, say, 5%, and there was > a large enough population of users who were systematically trying to > defraud merchants, we'd already be having worse security than magstripe > credit cards. EMV transactions have loss rates in the noise, so for > merchants who take those Bitcoin would be dramatically less secure. > > The idea of discouraging blocks that perform Finney attacks by having > honest miners refuse to build on them has been proposed. But it has a > couple of problems: > > 1. It's hard to automatically detect Finney attacks. Looking for blocks > that contain unseen transactions that override the mempool doesn't work - > the dishonest users could broadcast all their double spends once a Finney > block was found and then broadcast the block immediately afterwards, thus > making the block look like any other would in the presence of double spends. > > 2. If they could be automatically identified, it possibly could be > converted into a DoS on the network by broadcasting double spends in such a > way that the system races, and every miner produces a block that looks like > a Finney attack to some of the others. The chain would stop advancing. > > 3. Miners who want to vote "no" on a block take a big risk, they could > be on the losing side of the fork and end up wasting their work. > > We can resolve these problems with a couple of tweaks: > > 1. Dishonest blocks can be identified out of band, by having honest > miners submit double spends against themselves to the service anonymously > using a separate tool. When their own double spend appears they know the > block is bad. > > 2. Miners can vote to reallocate the coinbase value of bad blocks before > they mature. If a majority of blocks leading up to maturity vote for > reallocation, the value goes into a pot that subsequent blocks are allowed > to claim for themselves. Thus there is no risk to voting "no" on a block, > the work done by the Finney attacker is not wasted, and users do not have > to suffer through huge reorgs. > > This may seem a radical suggestion, but I think it's much less radical than > some of the others being thrown around. > > The above approach works as long as the majority of hashpower is honest, > defined to mean, working to stop double spending. This is the same security > property as described in the white paper, thus this introduces no new > security assumptions. Note that assuming *all* miners are dishonest and are > willing to double spend automatically resolves the Bitcoin experiment as a > failure, because that would invalidate the entire theory upon which the > system is built. That doesn't mean the assumption is wrong! It may be that > an entirely unregulated market for double spending prevention cannot work > and the participants eventually all end up trashing the commons - but the > hope is that smart incentives can replace the traditional reliance on law > and regulation to avoid this. > > The voting mechanism would only apply to coinbases, not arbitrary > transactions, thus it cannot be used to steal arbitrary users bitcoins. A > majority of miners can already reallocate coinbases by forking them out, > but this wastes energy and work presenting a significant discouragement to > vote unless you already know via some out of band mechanism that you have a > solid majority. Placing votes into the coinbase scriptSig as is done with > other things avoids that problem. > > The identification of Finney blocks relies on miners to take explicit > action, like downloading and running a tool that submits votes via RPC. It > can be expected that double spending services would try to identify and > block the sentinel transactions, which is why it's better to have the code > that fights this arms race be out of process and developed externally to > Bitcoin Core itself, which should ultimately just enforce the new (forking) > rule change. > > ------------------------------------------------------------------------------ > 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 > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ----- End forwarded message -----