From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1Uedej-0002bM-2d for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 03:54:33 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.178 as permitted sender) client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f178.google.com; Received: from mail-lb0-f178.google.com ([209.85.217.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Uedei-0004dc-7k for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 03:54:33 +0000 Received: by mail-lb0-f178.google.com with SMTP id w10so260348lbi.37 for ; Mon, 20 May 2013 20:54:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.26.225 with SMTP id o1mr240866lag.43.1369108465400; Mon, 20 May 2013 20:54:25 -0700 (PDT) Received: by 10.112.69.140 with HTTP; Mon, 20 May 2013 20:54:25 -0700 (PDT) In-Reply-To: References: <519AC3A8.1020306@quinnharris.me> Date: Mon, 20 May 2013 20:54:25 -0700 Message-ID: From: Gregory Maxwell To: Pieter Wuille 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: 1Uedei-0004dc-7k Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Double Spend Notification 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: Tue, 21 May 2013 03:54:33 -0000 On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille wr= ote: > On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus wrot= e: >> So the decision has been made to make 0-conf double spends trivial, so n= o >> one will ever trust 0-confs. If a later transaction appears with a large= r >> fee, it will be considered to be the valid one, and the first one droppe= d, >> as long as the first one has not been confirmed. This makes undoing a >> mistaken transaction possible. > This has been suggested, but I know of no such decision having been made. Indeed. I've argued against it pretty aggressively, but I am starting to find arguments for and against pure fee-based replacement more equally persuasive. Regardless of the eventual outcome, fees today aren't a major motivator vs subsidy and overall network health=E2=80=94 and even if some protection isn't 100% there are plenty of cases where the risk is averaged across many small transactions and any reduction of risk is a reduction in operating cost. (No one is going to double spend your soda machine at high speed=E2=80=94 so you can like increase your prices by the amount of successful double spends you experience and call it done) On the other hand, it's well established that people underestimate the costs of unlikely risks. More deterministic behavior can result in safer interactions more than _better_ behavior. If we believe that in the long term self-interest will result in pure-fee based replacement being wide spread then it is also good to not build a dependency on behavior that will not last. One point that was only recently exposed to me is that replacement combined with child-pays-for-parent creates a new kind of double spend _defense_: If someone double spends a payment to an online key of yours, you can instantly produce a child transaction that pays 100% of the double spend to fees... so a double spender can hurt you but not profit from it. (and if your side of the transaction is potentially/partially reversible he will lose)... But then again, a race to burn more money is kinda ... odd and even if the benefit of resisting the double spends is only a short term benefit, a short term benefit can be greatly important in encouraging Bitcoin adoption. ... and the long term behavior is far from certain. So at least from my position it's far from clear what should be done here. I've noticed a number of people who seem to be swayed by replace by fee=E2=80=94 or at least its inevitability if not value. So even ignoring developers there may evolve a community consensus here regardless of what I think about it. My SO pointed that that the transaction burning race described above sounds like an economists wet dream: it's one of those silly cases they use in experiments to probe human behavior... except it sounds like a possible eventual outcome in systems used by people. Perhaps it would be useful to point some graduate students at this question and see what they can come up with about it.