path: root/5d/eed120a2b7a92178240b5f19cb2c6b14a4bdcd

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <btcdev@quinnharris.me>) id 1UedWv-00076D-Bt
	for bitcoin-development@lists.sourceforge.net;
	Tue, 21 May 2013 03:46:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of quinnharris.me
	designates 67.223.164.214 as permitted sender)
	client-ip=67.223.164.214; envelope-from=btcdev@quinnharris.me;
	helo=fza.durangomail.com; 
Received: from fza.durangomail.com ([67.223.164.214])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1UedWs-00047m-Sn for bitcoin-development@lists.sourceforge.net;
	Tue, 21 May 2013 03:46:29 +0000
Received: from localhost (localhost [127.0.0.1])
	by fza.durangomail.com (Postfix) with ESMTP id 9564C1EB009;
	Mon, 20 May 2013 21:46:20 -0600 (MDT)
X-Virus-Scanned: amavisd-new at fza.durangomail.com
Received: from fza.durangomail.com ([127.0.0.1])
	by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Y3j4fjevsGAw; Mon, 20 May 2013 21:46:18 -0600 (MDT)
Received: from localhost (localhost [127.0.0.1])
	by fza.durangomail.com (Postfix) with ESMTP id E6D311EB00C;
	Mon, 20 May 2013 21:46:17 -0600 (MDT)
X-Virus-Scanned: amavisd-new at fza.durangomail.com
Received: from fza.durangomail.com ([127.0.0.1])
	by localhost (fza.durangomail.com [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id GiVbFmcdIN_U; Mon, 20 May 2013 21:46:17 -0600 (MDT)
Received: from [192.168.1.74] (172-3-184-238.lightspeed.sntcca.sbcglobal.net
	[172.3.184.238])
	by fza.durangomail.com (Postfix) with ESMTPSA id 13E1D1EB009;
	Mon, 20 May 2013 21:46:16 -0600 (MDT)
Message-ID: <519AEE07.8020301@quinnharris.me>
Date: Mon, 20 May 2013 21:46:15 -0600
From: Quinn Harris <btcdev@quinnharris.me>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Robert Backhaus <robbak@robbak.com>
References: <519AC3A8.1020306@quinnharris.me>
	<CA+i0-i_+Tes+ePRqmDGEXDQ_L=S5y8gHBKk77zaLgTGOS3OMyA@mail.gmail.com>
In-Reply-To: <CA+i0-i_+Tes+ePRqmDGEXDQ_L=S5y8gHBKk77zaLgTGOS3OMyA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000600070103030000050409"
X-Spam-Score: -0.5 (/)
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 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1UedWs-00047m-Sn
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Double Spend Notification
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: Tue, 21 May 2013 03:46:29 -0000

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

A part of my reason for sending this email was a quick discussion I had 
with Gavin at the BitCoin conference.  I was under the strong impression 
that double spend notification was something he approved of and was 
considering implementing himself.

In the case of a double spend, If the receiving end gets a timely 
notification (few seconds) it isn't that important that any one of the 
two (or more) transactions is chosen over another.  The receiving side 
can treat a double spend as a failed transaction as it should be proof 
that the buyer is acting maliciously or has had their private keys 
compromised.

I am aware Peter Todd has implemented replace by fee and is operating a 
node on testnet doing this.  I think he is rightly pointing out that the 
current behaviour of dropping all second spends is based largely on the 
good will of nodes and can absolutly contradict the perceived self 
interest of those running miners.  Accordingly relying on this behaviour 
can be precarious. It was from reading his emails to this list or 
bitcointalk that I recognized how essential it was to not transmit the 
second transaction if double spend notification had any hope of being 
worth much.

This is controversial because reliable 0-conf transactions are desirable 
but as you said there really is no way to ensure significant integrity 
in a decentralized way.  Replace by fee would make what transactions get 
into blocks more predictable and eliminate any expectation of reliable 0 
conf transactions.  The question is if this consistency is a better 
choice than a double spend notification that is far from perfect but 
today its still useful and in practice can probably be trusted as much 
as credit cards.

A more strict version of replace by fee could be implemented that only 
replaces transactions with ones that don't reduce any output quantity 
and accordingly require introducing a new input.  This would allow 
increasing transaction fees on a transaction without hurting someone who 
trusted a 0 conf transaction.  This seems like feature bloat to me but 
it wouldn't reduce 0 conf integrity.

Unfortunately, I don't see a way to make everyone happy on this issue.  
Though, I expect everyone would either prefer double spend notification 
or always replace by higher fee over what we have now.

- Quinn



On 05/20/2013 07:24 PM, Robert Backhaus wrote:
> Personally, I agree, but a different decision has been made by the 
> main devs.
>
> The issue is this: consider two transactions in the unconfirmed pool. 
> One transaction has 2BTC input, 1.5BTC to one address (the payment), 
> .4995 to another address (change) and .0005 standard fee. Another 
> transaction appears - Same input, 1BTC to one address, .999 to 
> another, and .001 fee. Which one would a miner include? On pure self 
> interest, the second one, because it has twice the fee. Anyway, the 
> miner has no real way of knowing which transaction was real, and which 
> the fraudulent double-spend. The network does not keep accurate 
> timestamps, so it has no way of really knowing which is first. A bit 
> of artificial DDOS-type overload on the recipient's system, and the 
> real transaction could easily appear last.
>
> So the decision has been made to make 0-conf double spends trivial, so 
> no one will ever trust 0-confs. If a later transaction appears with a 
> larger fee, it will be considered to be the valid one, and the first 
> one dropped, as long as the first one has not been confirmed. This 
> makes undoing a mistaken transaction possible.
>
> So anyone needing 0-conf-like speed will have to make other 
> arangements, such as contracting with enough mining pool power to 
> never drop their transactions unless confirmed multiple times. Secure 
> 0-confs is an impossible target with blockchain cyrpto-currencies as 
> the stand. Any ideas on how to make them work are welcome, of course - 
> as long as we haven't heard them too many times before.
>
>
> On 21 May 2013 10:45, Quinn Harris <btcdev@quinnharris.me 
> <mailto:btcdev@quinnharris.me>> wrote:
>
>     The current BitCoin implementation is subject to relatively easy
>     double
>     spend attack for 0 confirmation payments.  Yet 0 confirmation payments
>     are needed for typical in person transactions like most purchases at a
>     local business.
>
>     Notably, it is easy to transmit two transactions from the same
>     output at
>     the same time to different sets of nodes on the network by using two
>     instances of bitcoind with same wallet file and a spend on each daemon
>     initiated by RPC by some easy to implement code.  If the first attempt
>     to pay the merchant doesn't go through because they received the
>     "wrong"
>     transaction it could be quickly followed up with another initiated
>     spend
>     from a different output switching which daemon sends the
>     transaction the
>     merchant is expecting.  This means an unsophisticated attacker can
>     reliably get away with this attack and it would be worth while for
>     small
>     transactions.  Given this, I would be reluctant to trust 0
>     confirmation
>     transactions at all though I think many do in practice.  Someone could
>     write and publish a special daemon to execute this attack further
>     reducing the cost.
>
>     Right now a node will drop any second spend of the same output in the
>     memory pool.  After the first transaction has propagated through the
>     network issuing a second double spend transaction isn't likely to be
>     seen by a significant number of miners as most nodes especially non
>     miner nodes will drop this transaction.  Today, it is necessary to
>     transmit both transactions on the network nearly simultaneously to
>     reliably get away with this simple attack.  If in this case, the
>     receiving end is quickly notified of the double spend this attack
>     becomes more more difficult to get away with.
>
>     If the second transaction is relayed instead of being dropped to
>     notify
>     the receiving party of the double spend, most miners will receive both
>     transactions and it is possible that some or even many of the miners
>     would replace the first transaction with the second if it has a higher
>     fee as it would be in their short term interest. This can happen some
>     time after the first transaction has propagated through the network so
>     the receiving end wouldn't get a timely notification of the double
>     spend.  Depending on the choices of the miners, this approach to
>     double
>     spend notification could exacerbate the very problem it was attempting
>     to fix compared to the current implementation.  While miners might
>     continue to drop the second spends, the easy availability of the
>     second
>     spends would increase the short term reward for changing this policy.
>
>     This problem can be fixed if instead of sending the second
>     transaction a
>     new double spend message is sent with proof of the double spend
>     but not
>     the complete transactions.  This would allow the receiving end to be
>     quickly notified of a double spend while in no way increase the chance
>     over the current implementation that a double spend would be
>     successful.
>
>     The proof of the double spend would include the scriptSig (input) from
>     the original transactions and the hashes from the "simplified"
>     transaction used by OP_CHECKSIG of the scriptPubKey (output) but
>     not the
>     entire transaction.  This is the hash computed by the SignatureHash
>     function in script.cpp.   The double spend notification message should
>     contain proofs of both signed transaction spending the same output
>     ordered by hash to produce a canonical proof for a specific two
>     transactions.  To reduce DOS potential, the proof should not be
>     relayed
>     unless one of the original transactions has been received to ensure
>     there is some commitment to the block chain and different double spend
>     proofs of the same output should not be relayed.  The forwarding of
>     transactions should remain exactly the same as it is now where the
>     second transaction is dropped but a double spend message is
>     transmitted
>     if appropriate.
>
>     The existing block chain needs to be checked to make sure the proof of
>     double spend couldn't have been derived from the block chain and a
>     single spend in the memory pool.  This could happen if there was
>     already
>     an identical transaction in the block chain.  This would typically
>     only
>     happen if someone was paying someone else the same amount they had
>     before and neither side changed addresses.  In this case double spend
>     detection wouldn't be reliable as it could be generated by anyone, but
>     both the sending and receiving client could detect this situation and
>     warn the user.
>
>     It would still be possible for an attacker to send the second
>     transaction directly to powerful miners but this is a distinctly less
>     viable attack than the current double spend attack.
>
>     I would expect this double spend notification implementation to make
>     double spends more costly than they are worth for most cases today
>     that
>     0 confirmation acceptance is needed.  That said over time this
>     provision
>     might become less effective.  As the reward for each block mined
>     decreases, transactions fees will become a more significant part
>     of the
>     mining reward accordingly increasing the incentive to replace
>     transactions with higher fees.  Today most BitCoin participants have a
>     high expectation of significant future appreciation of BitCoins and
>     recognize anything that brings into question the integrity of the
>     system
>     is likely to reduce that future value so they have a long term self
>     interest to keep up the impression of integrity.  As BitCoin becomes
>     more establish this incentive will decrease.
>
>     On the other hand, non mining nodes have no incentive to replace by
>     fee.  The continued increased capital costs of mining would likely
>     increase the proportion of non mining nodes typically run by those
>     with
>     an incentive to assure integrity of the network such as merchants.
>      But
>     increasing transaction volume is likely to increase node costs which
>     would push out non mining nodes with lower incentive more than mining
>     nodes.  Accordingly increasing block size would have a tendency to
>     reduce the effectiveness of double spend notification.  The primary
>     point is there are multiple counteracting forces that make predicting
>     the future effectiveness of double spend notification uncertain.
>
>     I don't believe this necessary warrants conceding that we can not
>     provide any protection from non trusted 0 confirmations
>     transaction as a
>     replace by fee implementation would do.  But it would still be
>     important
>     to work towards more robust solutions notably various forms of 3rd
>     party
>     trust.  This could be tamper resistant devices trusted to not
>     duplicate
>     spends, 3rd party certificates with proof the transaction was spent by
>     the holder of the certificate or multi signature transactions on the
>     block chain that must be signed by a trusted 3rd party to spend.  I
>     would expect it would take significantly longer for the companies and
>     technologies to be built to implement this on a wide scale than adding
>     double spend proof messages to the current implementation.  In
>     addition,
>     there will likely always be some use cases where a 3rd party
>     (centralization) is not viable.
>
>     Should a BIP and pull request implementing a double spend notification
>     as described be accepted?
>
>     - Quinn
>
>
>
>     ------------------------------------------------------------------------------
>     Try New Relic Now & We'll Send You this Cool Shirt
>     New Relic is the only SaaS-based application performance
>     monitoring service
>     that delivers powerful full stack analytics. Optimize and monitor your
>     browser, app, & servers with just a few lines of code. Try New Relic
>     and get this awesome Nerd Life shirt!
>     http://p.sf.net/sfu/newrelic_d2d_may
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


--------------000600070103030000050409
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 text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">A part of my reason for sending this
      email was a quick discussion I had with Gavin at the BitCoin
      conference.&nbsp; I was under the strong impression that double spend
      notification was something he approved of and was considering
      implementing himself.<br>
      <br>
      In the case of a double spend, If the receiving end gets a timely
      notification (few seconds) it isn't that important that any one of
      the two (or more) transactions is chosen over another.&nbsp; The
      receiving side can treat a double spend as a failed transaction as
      it should be proof that the buyer is acting maliciously or has had
      their private keys compromised.<br>
      <br>
      I am aware Peter Todd has implemented replace by fee and is
      operating a node on testnet doing this.&nbsp; I think he is rightly
      pointing out that the current behaviour of dropping all second
      spends is based largely on the good will of nodes and can
      absolutly contradict the perceived self interest of those running
      miners.&nbsp; Accordingly relying on this behaviour can be precarious.&nbsp;
      It was from reading his emails to this list or bitcointalk that I
      recognized how essential it was to not transmit the second
      transaction if double spend notification had any hope of being
      worth much.<br>
      <br>
      This is controversial because reliable 0-conf transactions are
      desirable but as you said there really is no way to ensure
      significant integrity in a decentralized way.&nbsp; Replace by fee
      would make what transactions get into blocks more predictable and
      eliminate any expectation of reliable 0 conf transactions.&nbsp; The
      question is if this consistency is a better choice than a double
      spend notification that is far from perfect but today its still
      useful and in practice can probably be trusted as much as credit
      cards.<br>
      <br>
      A more strict version of replace by fee could be implemented that
      only replaces transactions with ones that don't reduce any output
      quantity and accordingly require introducing a new input.&nbsp; This
      would allow increasing transaction fees on a transaction without
      hurting someone who trusted a 0 conf transaction.&nbsp; This seems like
      feature bloat to me but it wouldn't reduce 0 conf integrity.<br>
      <br>
      Unfortunately, I don't see a way to make everyone happy on this
      issue.&nbsp; Though, I expect everyone would either prefer double spend
      notification or always replace by higher fee over what we have
      now.<br>
      <br>
      - Quinn<br>
      <br>
      <br>
      <br>
      On 05/20/2013 07:24 PM, Robert Backhaus wrote:<br>
    </div>
    <blockquote
cite="mid:CA+i0-i_+Tes+ePRqmDGEXDQ_L=S5y8gHBKk77zaLgTGOS3OMyA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>Personally, I agree, but a different decision has been
              made by the main devs.<br>
              <br>
            </div>
            The issue is this: consider two transactions in the
            unconfirmed pool. One transaction has 2BTC input, 1.5BTC to
            one address (the payment), .4995 to another address (change)
            and .0005 standard fee. Another transaction appears - Same
            input, 1BTC to one address, .999 to another, and .001 fee.
            Which one would a miner include? On pure self interest, the
            second one, because it has twice the fee. Anyway, the miner
            has no real way of knowing which transaction was real, and
            which the fraudulent double-spend. The network does not keep
            accurate timestamps, so it has no way of really knowing
            which is first. A bit of artificial DDOS-type overload on
            the recipient's system, and the real transaction could
            easily appear last.<br>
            <br>
          </div>
          So the decision has been made to make 0-conf double spends
          trivial, so no one will ever trust 0-confs. If a later
          transaction appears with a larger fee, it will be considered
          to be the valid one, and the first one dropped, as long as the
          first one has not been confirmed. This makes undoing a
          mistaken transaction possible.<br>
          <br>
        </div>
        So anyone needing 0-conf-like speed will have to make other
        arangements, such as contracting with enough mining pool power
        to never drop their transactions unless confirmed multiple
        times. Secure 0-confs is an impossible target with blockchain
        cyrpto-currencies as the stand. Any ideas on how to make them
        work are welcome, of course - as long as we haven't heard them
        too many times before.<br>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On 21 May 2013 10:45, Quinn Harris <span
            dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:btcdev@quinnharris.me" target="_blank">btcdev@quinnharris.me</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">The
            current BitCoin implementation is subject to relatively easy
            double<br>
            spend attack for 0 confirmation payments. &nbsp;Yet 0
            confirmation payments<br>
            are needed for typical in person transactions like most
            purchases at a<br>
            local business.<br>
            <br>
            Notably, it is easy to transmit two transactions from the
            same output at<br>
            the same time to different sets of nodes on the network by
            using two<br>
            instances of bitcoind with same wallet file and a spend on
            each daemon<br>
            initiated by RPC by some easy to implement code. &nbsp;If the
            first attempt<br>
            to pay the merchant doesn't go through because they received
            the "wrong"<br>
            transaction it could be quickly followed up with another
            initiated spend<br>
            from a different output switching which daemon sends the
            transaction the<br>
            merchant is expecting. &nbsp;This means an unsophisticated
            attacker can<br>
            reliably get away with this attack and it would be worth
            while for small<br>
            transactions. &nbsp;Given this, I would be reluctant to trust 0
            confirmation<br>
            transactions at all though I think many do in practice.
            &nbsp;Someone could<br>
            write and publish a special daemon to execute this attack
            further<br>
            reducing the cost.<br>
            <br>
            Right now a node will drop any second spend of the same
            output in the<br>
            memory pool. &nbsp;After the first transaction has propagated
            through the<br>
            network issuing a second double spend transaction isn't
            likely to be<br>
            seen by a significant number of miners as most nodes
            especially non<br>
            miner nodes will drop this transaction. &nbsp;Today, it is
            necessary to<br>
            transmit both transactions on the network nearly
            simultaneously to<br>
            reliably get away with this simple attack. &nbsp;If in this case,
            the<br>
            receiving end is quickly notified of the double spend this
            attack<br>
            becomes more more difficult to get away with.<br>
            <br>
            If the second transaction is relayed instead of being
            dropped to notify<br>
            the receiving party of the double spend, most miners will
            receive both<br>
            transactions and it is possible that some or even many of
            the miners<br>
            would replace the first transaction with the second if it
            has a higher<br>
            fee as it would be in their short term interest. This can
            happen some<br>
            time after the first transaction has propagated through the
            network so<br>
            the receiving end wouldn't get a timely notification of the
            double<br>
            spend. &nbsp;Depending on the choices of the miners, this
            approach to double<br>
            spend notification could exacerbate the very problem it was
            attempting<br>
            to fix compared to the current implementation. &nbsp;While miners
            might<br>
            continue to drop the second spends, the easy availability of
            the second<br>
            spends would increase the short term reward for changing
            this policy.<br>
            <br>
            This problem can be fixed if instead of sending the second
            transaction a<br>
            new double spend message is sent with proof of the double
            spend but not<br>
            the complete transactions. &nbsp;This would allow the receiving
            end to be<br>
            quickly notified of a double spend while in no way increase
            the chance<br>
            over the current implementation that a double spend would be
            successful.<br>
            <br>
            The proof of the double spend would include the scriptSig
            (input) from<br>
            the original transactions and the hashes from the
            "simplified"<br>
            transaction used by OP_CHECKSIG of the scriptPubKey (output)
            but not the<br>
            entire transaction. &nbsp;This is the hash computed by the
            SignatureHash<br>
            function in script.cpp. &nbsp; The double spend notification
            message should<br>
            contain proofs of both signed transaction spending the same
            output<br>
            ordered by hash to produce a canonical proof for a specific
            two<br>
            transactions. &nbsp;To reduce DOS potential, the proof should not
            be relayed<br>
            unless one of the original transactions has been received to
            ensure<br>
            there is some commitment to the block chain and different
            double spend<br>
            proofs of the same output should not be relayed. &nbsp;The
            forwarding of<br>
            transactions should remain exactly the same as it is now
            where the<br>
            second transaction is dropped but a double spend message is
            transmitted<br>
            if appropriate.<br>
            <br>
            The existing block chain needs to be checked to make sure
            the proof of<br>
            double spend couldn't have been derived from the block chain
            and a<br>
            single spend in the memory pool. &nbsp;This could happen if there
            was already<br>
            an identical transaction in the block chain. &nbsp;This would
            typically only<br>
            happen if someone was paying someone else the same amount
            they had<br>
            before and neither side changed addresses. &nbsp;In this case
            double spend<br>
            detection wouldn't be reliable as it could be generated by
            anyone, but<br>
            both the sending and receiving client could detect this
            situation and<br>
            warn the user.<br>
            <br>
            It would still be possible for an attacker to send the
            second<br>
            transaction directly to powerful miners but this is a
            distinctly less<br>
            viable attack than the current double spend attack.<br>
            <br>
            I would expect this double spend notification implementation
            to make<br>
            double spends more costly than they are worth for most cases
            today that<br>
            0 confirmation acceptance is needed. &nbsp;That said over time
            this provision<br>
            might become less effective. &nbsp;As the reward for each block
            mined<br>
            decreases, transactions fees will become a more significant
            part of the<br>
            mining reward accordingly increasing the incentive to
            replace<br>
            transactions with higher fees. &nbsp;Today most BitCoin
            participants have a<br>
            high expectation of significant future appreciation of
            BitCoins and<br>
            recognize anything that brings into question the integrity
            of the system<br>
            is likely to reduce that future value so they have a long
            term self<br>
            interest to keep up the impression of integrity. &nbsp;As BitCoin
            becomes<br>
            more establish this incentive will decrease.<br>
            <br>
            On the other hand, non mining nodes have no incentive to
            replace by<br>
            fee. &nbsp;The continued increased capital costs of mining would
            likely<br>
            increase the proportion of non mining nodes typically run by
            those with<br>
            an incentive to assure integrity of the network such as
            merchants. &nbsp;But<br>
            increasing transaction volume is likely to increase node
            costs which<br>
            would push out non mining nodes with lower incentive more
            than mining<br>
            nodes. &nbsp;Accordingly increasing block size would have a
            tendency to<br>
            reduce the effectiveness of double spend notification. &nbsp;The
            primary<br>
            point is there are multiple counteracting forces that make
            predicting<br>
            the future effectiveness of double spend notification
            uncertain.<br>
            <br>
            I don't believe this necessary warrants conceding that we
            can not<br>
            provide any protection from non trusted 0 confirmations
            transaction as a<br>
            replace by fee implementation would do. &nbsp;But it would still
            be important<br>
            to work towards more robust solutions notably various forms
            of 3rd party<br>
            trust. &nbsp;This could be tamper resistant devices trusted to
            not duplicate<br>
            spends, 3rd party certificates with proof the transaction
            was spent by<br>
            the holder of the certificate or multi signature
            transactions on the<br>
            block chain that must be signed by a trusted 3rd party to
            spend. &nbsp;I<br>
            would expect it would take significantly longer for the
            companies and<br>
            technologies to be built to implement this on a wide scale
            than adding<br>
            double spend proof messages to the current implementation.
            &nbsp;In addition,<br>
            there will likely always be some use cases where a 3rd party<br>
            (centralization) is not viable.<br>
            <br>
            Should a BIP and pull request implementing a double spend
            notification<br>
            as described be accepted?<br>
            <br>
            - Quinn<br>
            <br>
            <br>
            <br>
------------------------------------------------------------------------------<br>
            Try New Relic Now &amp; We'll Send You this Cool Shirt<br>
            New Relic is the only SaaS-based application performance
            monitoring service<br>
            that delivers powerful full stack analytics. Optimize and
            monitor your<br>
            browser, app, &amp; servers with just a few lines of code.
            Try New Relic<br>
            and get this awesome Nerd Life shirt! <a
              moz-do-not-send="true"
              href="http://p.sf.net/sfu/newrelic_d2d_may"
              target="_blank">http://p.sf.net/sfu/newrelic_d2d_may</a><br>
            _______________________________________________<br>
            Bitcoin-development mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
            <a moz-do-not-send="true"
              href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
              target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------000600070103030000050409--