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 <m...@plan99.net> wrote:
> On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <dr...@greenmangosystems.com
> > 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
>
>
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
