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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Double-spending unconfirmed transactions
 is a lot easier than most people realise
Precedence: list

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/