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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <jgarzik@bitpay.com>) id 1Wcoi9-0002J9-8b for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 04:23:05 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 74.125.82.45 as permitted sender) client-ip=74.125.82.45; envelope-from=jgarzik@bitpay.com; helo=mail-wg0-f45.google.com; Received: from mail-wg0-f45.google.com ([74.125.82.45]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wcoi5-0001Dr-Sv for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 04:23:05 +0000 Received: by mail-wg0-f45.google.com with SMTP id l18so325255wgh.16 for <bitcoin-development@lists.sourceforge.net>; Tue, 22 Apr 2014 21:22:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=BBFF5eUs0cW6mYo3K4U2HghskmBJc32JMK3KTgxDo+4=; b=cTmTs6u9UZuHNlrgE29spgW9e5RjxrjZ0yodUZXeIsPKniTkCNmZgoxicWgwo1Nzx+ yp5v7P0Uy2WaRH57bchghx9r6Oe0wYx0tlDvrs1RajZ33AuqfbmY3tRUlCsZM4lajCgH FdcMskD5xhOw/HDeHagr+1llgO+Pe9q9IEYmSpLjSKf/8q9BbF8Q+vZ1MVVlli3CjPVx MNK/RLaGoMy8zz0RFYLL6JIKy5Q22o0HT2hIH7oT5D4re8mkqHyEQ3DkRjqLm5FmbSe0 Xw8nmeidCf7dTqDrkf67BGiuEjY8zU08/SR0fNKMCa4bwCHpdTukhwB1rZLI1a7v/p++ zvoA== X-Gm-Message-State: ALoCoQnTGjWRuOShl1ARIFrqAojSBPN9Ila6UvoNxv34T7RVGiiV04ev+oRUekOwEQ7DAPPbBrE5 X-Received: by 10.180.85.10 with SMTP id d10mr30181wiz.0.1398226975637; Tue, 22 Apr 2014 21:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.243.138 with HTTP; Tue, 22 Apr 2014 21:22:35 -0700 (PDT) In-Reply-To: <53574581.3040004@thinlink.com> References: <20140422213128.GB2578@savin> <53574581.3040004@thinlink.com> From: Jeff Garzik <jgarzik@bitpay.com> Date: Wed, 23 Apr 2014 00:22:35 -0400 Message-ID: <CAJHLa0M8A6xpWMm1tCBCSTT=Q4Ks6ZCCXWdX_t62-4x+9_eRZg@mail.gmail.com> To: Tom Harding <tomh@thinlink.com> Content-Type: text/plain; charset=ISO-8859-1 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 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: 1Wcoi5-0001Dr-Sv Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> Subject: Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise 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 04:23:05 -0000 A lot of these "should the network..." questions depend on business rules and business models. Even if a 0-conf double spend is possible in a given business situation, the incentives quite often are aligned to avoid double-spend attempts in any case. Any physical good being shipped can "accept" the transaction, and then wait for confirmations before shipping. Digital goods might be accepted for 0-conf payment from users who have a good history with the merchant. The 0-conf attacker will tend to /not/ be a regular user, and also have many other typical markers of a fraudster. The subset of (a) double-spend attackers making a one-time or short-term attack on (b) a naive merchant with mistuned business rules will tend to be very small. On Wed, Apr 23, 2014 at 12:45 AM, Tom Harding <tomh@thinlink.com> wrote: > > Since no complete solution to preventing 0-confirmation respends in the > bitcoin network has been proposed, or is likely to exist, when > evaluating partial solutions let's ask "what kind of network does this > move toward?" > > Does the solution move toward a network with simple rules, where the > certainty that decreases from the many-confirmations state, down to 1 > confirmation, does not immediately disappear just below the time of 1 > confirmation? > > A network where transaction submitters consider their (final) > transactions to be unchangeable the moment they are transmitted, and > where the network's goal is to confirm only transactions all of whose > UTXO's have not yet been seen in a final transaction's input, has a > chance to be such a network. If respend attempts are broadcast widely, > then after a time on the order of transaction propagation time (<< 1 > minute) has passed, participants have a good chance to avoid relying on > a transaction whose funds are spent to someone else. This is both > because after this time the network is unlikely to split on the primacy > of one spend, and because the recipient, able to see a respend attempt, > can withhold delivery of the good or service until confirmation. > > Or, does the solution move toward a network that > - Requires participants to have knowledge of the policies of multiple > entities, like Eligius and whoever maintains the blacklist mentioned belo= w? > - Requires a transaction submitter to intently monitor transactions > and try to climb over the top of attempted respends with > "scorched-earth" triple spends, until a random moment some time between, > let's say, 5 and 15 minutes in the future? > - Punts the problem to off-network solutions? > > > On 4/22/2014 1:31 PM, Peter Todd wrote: >> You may have seen my reddit post of the same title a few days ago: >> >> http://www.reddit.com/r/Bitcoin/comments/239bj1/doublespending_unconfirm= ed_transactions_is_a_lot/ >> >> I've done some more experiments since, with good results. For instance >> here's a real-world double-spend of the gambling service Lucky Bit: >> >> Original: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd= 20 >> >> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f= 79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a= 38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca= 7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401ff= fffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888= ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270= 000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000 >> >> Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce= 88582a >> >> 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f= 79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed5= 63390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c= 476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401ff= fffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888= ac00000000 >> >> The double-spend was mined by Eligius and made use of the fact that >> Eligius blacklists transactions to a number of addresses considered to >> be "spam" by the pool operators; affected transactions are not added to >> the Eligus mempool at all. Lucky Bit has a real-time display of bets as >> they are accepted; I simply watched that display to determine whether or >> not I had lost. With Eligius at 8% and the house edge at 1.75% the >> attack is profitable when automated. My replace-by-fee patch(1) was >> used, although as there are only a handful of such nodes running - none >> connected directly to Eligius from what I can determine - I submitted >> the double-spend transactions to Eligius directly via their pushtxn >> webform.(2) >> >> Of course, this is an especially difficult case, as you must send the >> double-spend after the original transaction - normally just sending a >> non-standard tx to Eligius first would suffice. Note how this defeats >> Andresen's double-spend-relay patch(3) as proposed since the >> double-spend is a non-standard transaction. >> >> In discussion with Lucky Bit they have added case-specific code to >> reject transactions with known blacklisted outputs; the above >> double-spend I preformed is no longer possible. Of course, if the >> (reused) Lucky Bit addresses are added to that blacklist, that approach >> isn't viable - I suggest they switch to a scheme where addresses are not >> reused. (per-customer? rotated?) They also have added code to keep track >> of double-spend occurances and trigger human intervention prior to >> unacceptable losses. Longer term as with most services (e.g. Just-Dice) >> they intend to move to off-chain transactions. They are also considering >> implementing replace-by-fee scorched earth(4) - in their case a single >> pool, such as Eligius, implementing it would be enough to make the >> attack unprofitable. It may also be enough security to allow users to >> use their deposits prior to the first confirmation in a Just-Dice style >> off-chain implementation. >> >> 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1 >> >> 2) http://eligius.st/~wizkid057/newstats/pushtxn.php >> >> 3) https://github.com/bitcoin/bitcoin/pull/3354 and >> https://github.com/bitcoin/bitcoin/pull/3883 >> >> 4) https://bitcointalk.org/index.php?topic=3D251233.msg2669189#msg266918= 9 > > -------------------------------------------------------------------------= ----- > 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 --=20 Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/