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 1WdgKY-0003GP-4R for bitcoin-development@lists.sourceforge.net; Fri, 25 Apr 2014 13:38:18 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.171 as permitted sender) client-ip=209.85.223.171; envelope-from=gacrux@gmail.com; helo=mail-ie0-f171.google.com; Received: from mail-ie0-f171.google.com ([209.85.223.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WdgKW-0006Id-8q for bitcoin-development@lists.sourceforge.net; Fri, 25 Apr 2014 13:38:18 +0000 Received: by mail-ie0-f171.google.com with SMTP id ar20so3830378iec.30 for ; Fri, 25 Apr 2014 06:38:11 -0700 (PDT) X-Received: by 10.42.129.9 with SMTP id o9mr7243278ics.38.1398433090983; Fri, 25 Apr 2014 06:38:10 -0700 (PDT) Received: from [192.168.1.150] (60-240-212-53.tpgi.com.au. [60.240.212.53]) by mx.google.com with ESMTPSA id sb11sm8627915igb.0.2014.04.25.06.38.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 06:38:10 -0700 (PDT) Message-ID: <535A653E.1060902@gmail.com> Date: Fri, 25 Apr 2014 23:38:06 +1000 From: Gareth Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Bitcoin Dev References: <5359E9CB.9050703@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=378E4544 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m041PeASdhDJdjudmF9vV5hMsKE4JWXlQ" 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 (gacrux[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: 1WdgKW-0006Id-8q Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory 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: Fri, 25 Apr 2014 13:38:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m041PeASdhDJdjudmF9vV5hMsKE4JWXlQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25/04/14 20:19, Mike Hearn wrote: > You don't get any money back, but you do get an angry shopkeeper ch= asing > you down the street / calling the police / blacklisting you from th= e > store. >=20 >=20 > If they could do that they'd just take the stolen property back and you= > would have failed to spend your money twice. So this is by definition, > not a successful double spend. We are worried about the cases when you > could successfully double spend, and the only thing stopping you is Bit= coin. You might not succeed in catching them, but however small the risk of getting caught is, they're taking that risk for an assured zero gain. Any rational attacker would therefore not bother. I think it's a very elegant solution to the typical "broadcast double spend" attack. Of course it unfortunately does nothing to stop a dishonest mining pool from secretly working on your double spend for a fee. But that breaks down to: * trade first and hope the dishonest pool finds the next block * the dishonest pool finds and withholds the block while you trade We can discount the second one entirely - the orphan risk makes it very expensive to execute, and people are typically accepting zero-conf for low value items like cups of coffee. For high value items it is probably reasonable (and hopefully common practice?) to wait for a block. So we're left with the first situation. As others have noted, given a dishonest pool with 5% total hashrate, a dedicated attack is out (unless you want to end up actually buying goods to 20x the value of the attack in the process.) That leaves the opportunists, who press the "attempt to take-back 70% of this transaction" (remember the pool gets their cut) every time they buy a coffee and very occasionally get lucky. They're the only unsolvable problem I can see here. It remains to be seen how many such opportunists we'll end up with, or how much hashrate the dishonest pool can actually attract. --m041PeASdhDJdjudmF9vV5hMsKE4JWXlQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWmU+AAoJEEY5w2E3jkVEk3EIAMGY2c1Q1V3EEZZFLxyMQsIr RF23fp5FhLnK7jyH2QQ0kfNW5yq4vUZahG2RwtQIlLrAjFGaQSOfkIi48PqnSHpZ eP/fMkj9+BLiF7KSTaiXHYaBA0VQmxhaiIw1gBynrKXo8/+TO1HYpD1lPaWnYIXU +Ykz6NiVQmJJ3xLm1uAQJKwT4yZ8LRL51g65aVPnXYQaNgYURN3nBkCYLWi2t7q4 VGmYa+7EGhG4Y8NWUqexphMlLpXhzIh05wukiFIDWGXReRTfDYKcEjz22/x1i39e RH1k1sEyP8X4HmA378MbKMlgTYDV+5+N+OxvAJiYaa8oVaSt/XaHVHGHb6PqAgI= =4Plk -----END PGP SIGNATURE----- --m041PeASdhDJdjudmF9vV5hMsKE4JWXlQ--