Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwZRg-0000Sp-Sc for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:07:44 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.48 as permitted sender) client-ip=209.85.219.48; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f48.google.com; Received: from mail-oa0-f48.google.com ([209.85.219.48]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwZRf-0007bm-4i for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 16:07:44 +0000 Received: by mail-oa0-f48.google.com with SMTP id m1so5968256oag.7 for ; Mon, 16 Jun 2014 09:07:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.115.199 with SMTP id jq7mr3235837obb.70.1402934857571; Mon, 16 Jun 2014 09:07:37 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 09:07:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 18:07:37 +0200 X-Google-Sender-Auth: 4H_wFdi68pxMtfQM8EuMrGobVjU Message-ID: From: Mike Hearn To: Daniel Rice Content-Type: multipart/alternative; boundary=047d7b678120d42a2c04fbf6397e 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: 1WwZRf-0007bm-4i Cc: Bitcoin Dev , Lawrence Nahum 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:07:45 -0000 --047d7b678120d42a2c04fbf6397e Content-Type: text/plain; charset=UTF-8 > > Come to think of it, is the payment protocol really the place to put this > instant provider signature > Yes it's the right place. The original attempt at this concept was in fact called *green addresses* and the idea was you could identify a spend from a trusted wallet by checking which keys were being used to sign. But the problem is, lack of privacy. Everyone can see what wallet provider you use. Also it'd be inefficient to have in the chain. There's no reason for the extra signatures to be there: double spend risk is something only the recipient cares about. --047d7b678120d42a2c04fbf6397e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Come to think of it, is the payment proto= col really the place to put this instant provider signature

Yes it's the right place. The or= iginal attempt at this concept was in fact called green addresses=C2= =A0and the idea was you could identify a spend from a trusted wallet by che= cking which keys were being used to sign. But the problem is, lack of priva= cy. Everyone can see what wallet provider you use.

Also it'd be inefficient to have in the chain. Ther= e's no reason for the extra signatures to be there: double spend risk i= s something only the recipient cares about.=C2=A0
--047d7b678120d42a2c04fbf6397e--