path: root/c2/6789f45deb08899490d9c954cc6f6cc31cc4ba

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <kevinsisco61784@gmail.com>) id 1WczCE-0003uX-UO
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 15:34:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.41 as permitted sender)
	client-ip=209.85.192.41; envelope-from=kevinsisco61784@gmail.com;
	helo=mail-qg0-f41.google.com; 
Received: from mail-qg0-f41.google.com ([209.85.192.41])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WczCD-0000NB-Jw
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 15:34:50 +0000
Received: by mail-qg0-f41.google.com with SMTP id j107so432639qga.14
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Apr 2014 08:34:44 -0700 (PDT)
X-Received: by 10.224.167.12 with SMTP id o12mr58233959qay.77.1398267284104;
	Wed, 23 Apr 2014 08:34:44 -0700 (PDT)
Received: from [192.168.1.115] (ool-43521013.dyn.optonline.net. [67.82.16.19])
	by mx.google.com with ESMTPSA id
	a6sm2285440qaj.15.2014.04.23.08.34.42
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 23 Apr 2014 08:34:43 -0700 (PDT)
Message-ID: <5357DD8F.6050308@gmail.com>
Date: Wed, 23 Apr 2014 11:34:39 -0400
From: Kevin <kevinsisco61784@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
In-Reply-To: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080602050706050009010205"
X-Spam-Score: -0.3 (/)
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 [209.85.192.41 listed in list.dnswl.org]
	-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
	(kevinsisco61784[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (kevinsisco61784[at]gmail.com)
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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: 1WczCD-0000NB-Jw
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 15:34:51 -0000

This is a multi-part message in MIME format.
--------------080602050706050009010205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 4/23/2014 3:55 AM, Mike Hearn 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. 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
I have some questions:
1.  How can we work towards solving the double-spending problem?
2.  Is it possible to "scan" for double-spending and correct it?
3.  Is the network at large not secure enough?


-- 
Kevin


--------------080602050706050009010205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 4/23/2014 3:55 AM, Mike Hearn wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.&nbsp;
        <div>
          <br>
        </div>
        <div>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.</div>
        <div>Even with their woeful security many merchants see &lt;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.&nbsp;</div>
        <div><br>
        </div>
        <div>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:</div>
        <div>
          <ol>
            <li>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.<br>
              <br>
            </li>
            <li>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.<br>
              <br>
            </li>
            <li>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.</li>
          </ol>
          <div>We can resolve these problems with a couple of tweaks:</div>
        </div>
        <div>
          <ol>
            <li>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.<br>
              <br>
            </li>
            <li>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.</li>
          </ol>
          <div>This may seem a radical suggestion, but I think it's much
            less radical than some of the others being thrown around.</div>
        </div>
        <div><br>
        </div>
        <div>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 <i>all</i>&nbsp;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.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
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
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ExoPlatform">http://p.sf.net/sfu/ExoPlatform</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    I have some questions:<br>
    1.&nbsp; How can we work towards solving the double-spending problem?<br>
    2.&nbsp; Is it possible to "scan" for double-spending and correct it?<br>
    3.&nbsp; Is the network at large not secure enough?<br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Kevin
</pre>
  </body>
</html>

--------------080602050706050009010205--