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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wco8P-00026V-5R for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 03:46:09 +0000 X-ACL-Warn: Received: from mail-pd0-f178.google.com ([209.85.192.178]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wco8L-0006J2-Hd for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 03:46:09 +0000 Received: by mail-pd0-f178.google.com with SMTP id x10so321417pdj.23 for ; Tue, 22 Apr 2014 20:45:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tMxo/Vh3mX2YSo1l25j3tEn/2wRQ2x8Z10mPMhWYjqE=; b=ARzq41TRDzbhr6lSvBQ6OOI8hsHzYNBYckPDjODQl4dCtcT37XTzWueMV0PFfDSyry pvl8ZiT/dbBI8LDRUMxiR7g6SiofGnrfI6tWs2bvrYYRuK6b7101VnoCLWlGyu+W77Ps 30+fvINYX7RLeqDjkmqaprFscwrOYZ33YbWKez7E2hXig81F+6GICB+vXBOOyhBbpz/u oEJUjLHg7mZEy394mtkdJTptP+Syh/zLuqz9lptNDUJKYIXphhWTQcO4lEZ2QZMmJDJ8 iYxW29zDIEQ1uNJlvitoaRs0gGF3d6qY0XgpHGtcbd9SHwHnGEdfVwjLzjkVuV5hDdP1 xo0w== X-Gm-Message-State: ALoCoQkjzHixTx9HYTx4yMqPC2MHZ77Oglj7BWMWoxM8FZPaOXzEC+iUAru2H2354oXPLt6/lRtu X-Received: by 10.68.178.162 with SMTP id cz2mr49667933pbc.51.1398224759608; Tue, 22 Apr 2014 20:45:59 -0700 (PDT) Received: from [192.168.1.89] (99-6-44-248.lightspeed.sntcca.sbcglobal.net. [99.6.44.248]) by mx.google.com with ESMTPSA id z3sm210739886pas.15.2014.04.22.20.45.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Apr 2014 20:45:59 -0700 (PDT) Message-ID: <53574581.3040004@thinlink.com> Date: Tue, 22 Apr 2014 20:45:53 -0800 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20140422213128.GB2578@savin> In-Reply-To: <20140422213128.GB2578@savin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.178 listed in list.dnswl.org] X-Headers-End: 1Wco8L-0006J2-Hd 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 03:46:09 -0000 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 below? - 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_unconfirmed_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: 7801c3b996716025dbac946ca7a123b7c1c5429341738e8a6286a389de51bd20 > > 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a4730440220692d09f5415f23118f865b81430990a15517954fd14a8bda74a5a38c4f2f39450220391f6251e39cdd3cab7363b912b897146a0a78e295f6ecd23b078c9f64ca7ae8012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff030c4d0f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac400d0300000000001976a914da5dde8abec4f3b67561bcd06aaf28b790cff75588ac10270000000000001976a914c4c5d791fcb4654a1ef5e03fe0ad3d9c598f982788ac00000000 > > Double-spend: f4e8e930bdfa3666b4a46c67544e356876a72ec70060130b2c7078c4ce88582a > > 01000000012a14c8e6ce1e625513847b2ff271b3e6a1849f2a634c601b7f383ef710483f79000000006a473044022074f0c6912b482c6b51f1a91fb2bdca3f3dde3a3aed4fc54bd5ed563390011c2d02202719fe49578591edfbdd4b79ceeaa7f9550e4323748b3dbdd4135f38e70c476d012103a11c09c09874833eedc58a031d01d161ab4d2eba3874959537c5609ef5d5401fffffffff01d9c90f00000000001976a914d5245b64fcf8e873a9d1c0bfe2d258492bec6cc888ac00000000 > > 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=251233.msg2669189#msg2669189