Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wwdu1-0001BN-BA for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 20:53:17 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of greenmangosystems.com designates 209.85.128.169 as permitted sender) client-ip=209.85.128.169; envelope-from=drice@greenmangosystems.com; helo=mail-ve0-f169.google.com; Received: from mail-ve0-f169.google.com ([209.85.128.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wwdtz-0003OR-GV for bitcoin-development@lists.sourceforge.net; Mon, 16 Jun 2014 20:53:17 +0000 Received: by mail-ve0-f169.google.com with SMTP id pa12so6812125veb.28 for ; Mon, 16 Jun 2014 13:53:09 -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=Drq1Mna46MsMAGLukvRUTw81kKILyNrgUWqt1dG48z4=; b=Ws0jQS+lt3ZyF5GtPTU6LhGUuV+gdYtPPmOnP4jCXn4eEahHuDexSMIiy6lgFxTqUa 1zJOLHq9546kEWJ0n2G+N8fo3rN3xaWQJ/yKcy8PIZxeel4M+swe9EzbUvYIuHiDPH+T CjOeFiC1g+qrJvM1jFr07yMh+PW4NDAEEgYH+B18wwj4oV0sgS8AFSdLD7ZHKi7hjYP1 YbiWWjbwLdAdTMwU8H++iVik29bRoj+poct11mQ560MbncnBe7d4WF2OztuNiPu9XdkP gkRmGM7S7lFGgYcexWST3xUVOUKOw65+UP3tAnxYmoHqvfmMnjPcoHO/zha4M6hpziwX Obvg== X-Gm-Message-State: ALoCoQkDqFxaButQeg8oH7XeKIC0nz8RZqCnrSspp69yy2Io9SbRPXa14gD585pKWFYSIHRWP2Cf MIME-Version: 1.0 X-Received: by 10.220.94.146 with SMTP id z18mr2317583vcm.40.1402951989534; Mon, 16 Jun 2014 13:53:09 -0700 (PDT) Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 13:53:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Jun 2014 13:53:09 -0700 Message-ID: From: Daniel Rice To: Mike Hearn Content-Type: multipart/alternative; boundary=001a11c1e9d0f9352304fbfa3603 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: 1Wwdtz-0003OR-GV 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:53:17 -0000 --001a11c1e9d0f9352304fbfa3603 Content-Type: text/plain; charset=UTF-8 The trust can be more automated in this case than it can with CAs. The difference is that when a CA does something it shouldn't, like generates an extra cert for a government to use in spoofing a site, nobody knows about it, unless they mess up. Double spends on the network can be monitored and stored for history. Merchants can and will share information on instant provider trust with eachother, so they will essentially be able to build up a credit history on a given instant provider without really knowing who they are. On Mon, Jun 16, 2014 at 1:46 PM, Mike Hearn wrote: > On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice > wrote: > >> 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's no different to the CA problem. People can only mentally handle a few > trust anchors, so for SSL it goes: > > 1 User -> 2-3 browser makers -> 100's of CAs -> millions of websites > > The trust starts out narrowly funnelled and grows outwards as things get > outsourced. > > For this it'd go > > 1 merchant -> 4-5 payment processing engines -> dozens of hardware > manufacturers -> hundreds of thousands of devices > > > --001a11c1e9d0f9352304fbfa3603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The trust can be more automated in this case than it can w= ith CAs. The difference is that when a CA does something it shouldn't, = like generates an extra cert for a government to use in spoofing a site, no= body knows about it, unless they mess up. Double spends on the network can = be monitored and stored for history. Merchants can and will share informati= on on instant provider trust with eachother, so they will essentially be ab= le to build up a credit history on a given instant provider without really = knowing who they are.


On Mon, Jun 1= 6, 2014 at 1:46 PM, Mike Hearn <mike@plan99.net> wrote:
On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <drice= @greenmangosystems.com> wrote:
True, that would work, but = still how are you going to bootstrap the trust? TREZOR is well known, but i= n 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 marke= t by being the only one that is an accepted instant provider at most vendor= s

It's no different to the CA prob= lem. People can only mentally handle a few trust anchors, so for SSL it goe= s:

=C2=A0 =C2=A01 User -> 2-3 browser makers -&= gt; 100's of CAs -> millions of websites

The trust starts out narrowly funnelled and grows outwa= rds as things get outsourced.

For this it'd go=

=C2=A0 =C2=A01 merchant -> 4-5 payment process= ing engines -> dozens of hardware manufacturers -> hundreds of thousa= nds of devices



--001a11c1e9d0f9352304fbfa3603--