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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPqng-00076m-C9 for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 11:03:44 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f53.google.com; Received: from mail-wg0-f53.google.com ([74.125.82.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPqne-0001kh-CX for bitcoin-development@lists.sourceforge.net; Mon, 23 Feb 2015 11:03:44 +0000 Received: by mail-wg0-f53.google.com with SMTP id a1so24772163wgh.12 for ; Mon, 23 Feb 2015 03:03:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.14.196 with SMTP id r4mr19251318wic.77.1424689416339; Mon, 23 Feb 2015 03:03:36 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.11 with HTTP; Mon, 23 Feb 2015 03:03:36 -0800 (PST) In-Reply-To: <2953246.T2DHreG0Tu@crushinator> References: <20150222123428.GA6570@savin.petertodd.org> <2953246.T2DHreG0Tu@crushinator> Date: Mon, 23 Feb 2015 12:03:36 +0100 X-Google-Sender-Auth: WXcR1Fxco6_I1wRnH8r-jOPK4pk Message-ID: From: Mike Hearn To: Matt Whitlock Content-Type: multipart/alternative; boundary=f46d04138c7d9389eb050fbf5ad0 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YPqne-0001kh-CX Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4) 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: Mon, 23 Feb 2015 11:03:44 -0000 --f46d04138c7d9389eb050fbf5ad0 Content-Type: text/plain; charset=UTF-8 > > This happened to one of the merchants at the Bitcoin 2013 conference in > San Jose. They sold some T-shirts and accepted zero-confirmation > transactions. The transactions depended on other unconfirmed transactions, > which never confirmed, so this merchant never got their money. > Beyond the fact that this risk can be priced in when enough data is available, I'd be interested to talk to this merchant and dig into what happened a bit. For example: 1. Was the dependent tx non-standard? 2. Was it double spent? 3. Could a wallet have co-operated with the P2P network to detect and flag whatever the issue was? My own experience has been that when this happens, it's usually not the result of outright maliciousness (especially not at a Bitcoin t-shirt seller at a Bitcoin conference!) but rather something messed up somewhere and the software in use just didn't detect it well enough. --f46d04138c7d9389eb050fbf5ad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This happened to one of the merchants at the Bit= coin 2013 conference in San Jose. They sold some T-shirts and accepted zero= -confirmation transactions. The transactions depended on other unconfirmed = transactions, which never confirmed, so this merchant never got their money= .

Beyond the fact that this risk can be= priced in when enough data is available, I'd be interested to talk to = this merchant and dig into what happened a bit.

Fo= r example:
  1. Was the dependent tx non-standard?
  2. Was= it double spent?
  3. Could a wallet have co-operated with the P2P netw= ork to detect and flag whatever the issue was?
My own experie= nce has been that when this happens, it's usually not the result of out= right maliciousness (especially not at a Bitcoin t-shirt seller at a Bitcoi= n conference!) but rather something messed up somewhere and the software in= use just didn't detect it well enough.

--f46d04138c7d9389eb050fbf5ad0--