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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwZ9A-0001kP-2W for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 15:48:36 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.179 as permitted sender) client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f179.google.com; Received: from mail-ob0-f179.google.com ([209.85.214.179]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwZ98-0001tL-Cb for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 15:48:36 +0000 Received: by mail-ob0-f179.google.com with SMTP id uz6so6016187obc.10 for ; Mon, 16 Jun 2014 08:48:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.114.229 with SMTP id jj5mr21019584obb.53.1402933708669; Mon, 16 Jun 2014 08:48:28 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 08:48:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 17:48:28 +0200 X-Google-Sender-Auth: rS4XYbr7fCunbfkEpQc5jcjLxRs Message-ID: From: Mike Hearn To: Paul Goldstein Content-Type: multipart/alternative; boundary=001a11c2f644594a3b04fbf5f53f X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1WwZ98-0001tL-Cb Cc: Bitcoin Dev 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 15:48:36 -0000 --001a11c2f644594a3b04fbf5f53f Content-Type: text/plain; charset=UTF-8 > > Mike Hearn, why don't we just have all nodes report attempted double > spends through the node network. > 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. 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 :-) 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. --001a11c2f644594a3b04fbf5f53f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike Hearn, why don't we just have all nodes report at= tempted double spends through the node network.

=
Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements this = exact scheme. It can solve some kinds of double spends (probably), but othe= rs - like ones done by corrupt miners (see bitundo) - can't be solved t= his way.

Lawrence's motivation for this BIP is essentially t= o act as a backup in case the Bitcoin native double spending protections en= d up being too weak to be useful. It reintroduces a notion of centralised t= rust as a layer on top of the Bitcoin protocol, but only for cases where th= e 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 t= o payment fraud go up, we can fall back to TTPs for a while until someone f= inds 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 :-= )

In practice of course this is something payment process= ors 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 aro= und a handful of payment processing companies.


--001a11c2f644594a3b04fbf5f53f--