Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wcx7m-0003vP-7q for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 13:22:06 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.47 as permitted sender) client-ip=74.125.82.47; envelope-from=andyparkins@gmail.com; helo=mail-wg0-f47.google.com; Received: from mail-wg0-f47.google.com ([74.125.82.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wcx7k-00038w-8M for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 13:22:06 +0000 Received: by mail-wg0-f47.google.com with SMTP id x12so835136wgg.18 for ; Wed, 23 Apr 2014 06:21:58 -0700 (PDT) X-Received: by 10.195.13.76 with SMTP id ew12mr529830wjd.80.1398259318102; Wed, 23 Apr 2014 06:21:58 -0700 (PDT) Received: from grissom.localnet ([91.84.15.31]) by mx.google.com with ESMTPSA id q2sm29013104wix.5.2014.04.23.06.21.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 06:21:57 -0700 (PDT) From: Andy Parkins To: Mike Hearn Date: Wed, 23 Apr 2014 14:21:53 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-1-686-pae; KDE/4.8.4; i686; ; ) References: <201404231239.20202.andyparkins@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201404231421.53349.andyparkins@gmail.com> 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 (andyparkins[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: 1Wcx7k-00038w-8M Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks 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 13:22:06 -0000 On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote: > OK, sure, let's say most Bitcoin users will be honest (we hope). But > unfortunately in a situation where fraud is possible users wouldn't > necessarily distribute evenly over transactions. That's true, but even in the worst that that 5% hashing power attack means that 95% of the time, your attack fails. That means you end up paying for what you bought. Also, you're again changing the comparison basis -- your CC figures were for the entire industry, not the most badly affected merchant. You can't say "one particular bitcoin merchant suffers 5% fraud, therefore that's worse than the 2% fraud averaged across all CC merchants". > If a merchant is selling something of value repeatedly, then a small > number of scammers can go back and try their luck over and over. I'm not > sure how many trades fall into such an exploitable category, though. > > Also, there's the philosophical question of how honest people really are > when there's no consequences to their actions. For instance, if most There _are_ consequences though: 95% of the time, you end up buying something and paying for it. Viewed another way, if I buy something repeatedly from an at risk merchant (and there won't be many; as you pointed out, mail order is completely unaffected as you can simply wait for your confirmations) that costs, say 0.01 BTC per item, then I have to buy 100 of them to get 5 of them for free. Do I really want 100 of them? Even if I do want them, then I've had to supply capital of 1 BTC to earn 0.05 BTC in kind. If what I'm buying is another form of money (as with exchanges, or perhaps casinos) when that "in kind" is just as liquid as the BTC, then fair enough, there is a risk, but that just incentivises the merchant in those cases to not allow withdrawal/deposit until 6 confirmations have been received. Those merchants then move from "at risk" to "not at risk". I'm still struggling to see how bitcoin could ever be as bad as CC fraud. Andy -- Dr Andy Parkins andyparkins@gmail.com