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 1WwZoG-0003cW-M1 for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:31:04 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WwZoE-0008Hm-Ny for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:31:04 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WwZo7-0004PI-3v for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 18:30:55 +0200 Received: from 93-35-10-132.ip52.fastwebnet.it ([93.35.10.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jun 2014 18:30:55 +0200 Received: from lawrence by 93-35-10-132.ip52.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jun 2014 18:30:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Lawrence Nahum Date: Mon, 16 Jun 2014 16:30:45 +0000 (UTC) Message-ID: References:

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 93.35.10.132 (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36) X-Spam-Score: -2.2 (--) 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 [80.91.229.3 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WwZoE-0008Hm-Ny Subject: Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 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: Mon, 16 Jun 2014 16:31:04 -0000 Mike Hearn plan99.net> writes: > Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements this exact scheme. It can solve some kinds of double spends (probably), but others - like ones done by corrupt miners (see bitundo) - can't be solved this way. I read the comments on the PR. I mean no disrespect but this patch can't prevent double spends minutes apart and a solution is as good as it's weakest link. It also seems to suffer from potential ddos and otherwise may provide a false sense of security. I wouldn't call it a solution in sight just yet. > Lawrence's motivation for this BIP is essentially to act as a backup in case the Bitcoin native double spending protections end up being too weak to be useful. It reintroduces a notion of centralised trust as a layer on top of the Bitcoin protocol, but only for cases where the seller/recipient feels it'd be useful. In this way it gives us slack: if someone is able to reliably double spend and the merchants losses due to payment fraud go up, we can fall back to TTPs for a while until someone finds a solution for Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we now have a better intermediary protocol than SWIFT I wouldn't put it just like that. Sure, it's a backup to the double spend solution in case we don't reach one - but also, even if you reach some reasonable compromise I assume it won't be instant and instant confirmation between exchanges can create huge arbitrage opportunities and as such liquidity. It's not really aimed at the merchant but more at service providers and payment processors - or simply, between users that don't know each other in local traders environments/squares, assuming they are ok trusting a known/respected/reputable third party. > In practice of course this is something payment processors like Bitpay and Coinbase will think about. Individual cafes etc who are just using mobile wallets won't be able to deal with this complexity: if we can't make native Bitcoin work well enough there, we're most likely to just lose that market or watch it become entirely centralised around a handful of payment processing companies. What do you expect for e-commerce and escrow to happen? Don't you think the market will naturally converge to a handful of hubs that will helps with refunds and things like that? Or do you expect to just 'trust' all people on online markets and smaller unknown online shops? I mean, the beauty of Bitcoin is that it brings much more transparency and the tools to build such things without huge barriers to entry and without using closed protocols - not that it solves _every_ problem.