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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WwdfE-0000XO-V1 for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 20:38:00 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.220.178 as permitted sender) client-ip=209.85.220.178; envelope-from=drice@greenmangosystems.com; helo=mail-vc0-f178.google.com; Received: from mail-vc0-f178.google.com ([209.85.220.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WwdfD-0002Po-54 for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 20:38:00 +0000 Received: by mail-vc0-f178.google.com with SMTP id ij19so5607643vcb.9 for ; Mon, 16 Jun 2014 13:37:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1leq6+cRn1kVbVQI+EqoBosMa0ee39OKKYf+hAwbkAk=; b=Lr1wPkrNr7hZPdwBaKQMRm6YPlorVUVyqA63+EP5hlzyeaDLoOMoBADeq3d3PQIe0X /Ujnj8F6+C3UgOK9RNuxcdc1H1wBcYfphZkbZSu6NU93iBix2bXH3KqCQJFXWXZHaNx4 ev9mFtypZtm4Gf/2SUJyxvaYrRcVhRFc0+nDVQyKypq9BkYE6nQ5pTbDBDnuWUQAf+u1 XhgQoGI7P0phwRY+WB8cD39LWn2HXyw5dEqKRU+Gje7V7l2mEnKWUYxVwV2ePz6tjJGt gpocut88NCw609AhqayavVQGU37LoGhfUfnsgBzNwu9534RKamnNQAidvYE1+dOf0/jA 4NHw== X-Gm-Message-State: ALoCoQlFlHRxYciG6iPe2w7620By8mkgnFOVjitTSf/9X9YO4nfxw7lQ6ryo5Q+3R68L9quEjrPF MIME-Version: 1.0 X-Received: by 10.58.236.170 with SMTP id uv10mr3317853vec.31.1402951072968; Mon, 16 Jun 2014 13:37:52 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 13:37:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 13:37:52 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7bdc1a9c577c6804fbfa005c X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1WwdfD-0002Po-54 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 20:38:01 -0000 --047d7bdc1a9c577c6804fbfa005c Content-Type: text/plain; charset=UTF-8 True, that would work, but still how are you going to bootstrap the trust? TREZOR is well known, but in a future where there could be 100 different companies trying to release a similar product to TREZOR it seems like one company could corner the market by being the only one that is an accepted instant provider at most vendors. It seems to encourage monopoly unless there is a standard way to bootstrap trust in your signature. On Mon, Jun 16, 2014 at 1:32 PM, Mike Hearn wrote: > On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice > wrote: > >> I'm trying to think through how to encourage the maximum number of >> instant signature providers and avoid the VISA monopoly. Ideal case would >> be that people can even be their own instant provider. >> > > A provider does not have to be an interactive third party. One reason I > suggested using X.509 is so secure hardware devices like the TREZOR could > also be instant providers. The hardware would be tamperproof and assert > using a secret key embedded in it that the tx came from a genuine, > unflashed TREZOR. The the server can know the device won't double spend. > > In this way you have decentralised anti-double spending. Of course, it's > an old solution. MintChip sort of worked a bit like this. > --047d7bdc1a9c577c6804fbfa005c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
True, that would work, but still how are you going to boot= strap the trust? TREZOR is well known, but in a future where there could be= 100 different companies trying to release a similar product to TREZOR it s= eems like one company could corner the market by being the only one that is= an accepted instant provider at most vendors. It seems to encourage monopo= ly unless there is a standard way to bootstrap trust in your signature.


On Mon, Jun 1= 6, 2014 at 1:32 PM, Mike Hearn <mike@plan99.net> wrote:
On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice= @greenmangosystems.com> wrote:
I'm trying to thin= k through how to encourage the maximum number of instant signature provider= s and avoid the VISA monopoly. Ideal case would be that people can even be = their own instant provider.

A provider does not have to be= an interactive third party. One reason I suggested using X.509 is so secur= e hardware devices like the TREZOR could also be instant providers. The har= dware would be tamperproof and assert using a secret key embedded in it tha= t the tx came from a genuine, unflashed TREZOR. The the server can know the= device won't double spend.

In this way you have decentralised anti-double spending= . Of course, it's an old solution. MintChip sort of worked a bit like t= his.

--047d7bdc1a9c577c6804fbfa005c--