[Cryptography] blockchain and trustworthy computing

[Peter Todd]

On Mon, Oct 05, 2015 at 12:16:23PM -0400, ianG wrote:
> >I really strongly disagree about the direction of what you're talking
> >about.
> 
> 
> I'm not pushing for a BIP to upturn mainnet, rather I'm thinking
> about the world of private blockchains run for local or specific
> purposes. I.e., the invention of the blockchain, not the one that
> runs BTC.
> 
> Is that still disagreeable?

Yes! Again, I think we need to distinguish math - verification - from
trust - non-verification.

> >I'd define trustworthy computing as being able to trust that a
> >computation was done correctly without you checking it yourself. This
> >implies that SPV clients are taking advantage of trustworthy computing
> >because they trust miners; full nodes are not doing that because they
> >verify the blockchain themselves.
> 
> 
> Right, something like that.  To extend my (somewhat challenged)
> analogy of the VW problem, a blockchain can be a private
> permissioned one that is running inside the car, on all the
> distributed brain chips.  EPA is one of the signatories that can
> access, so it dials in and loads up a program (e.g., smart contract)
> and does some computations.
> 
> In this sense, the EPA is an SPV client user.  It's relying that the
> car has a proper private blockchain on it, but once past that
> hurdle, it's free to run trustworthy programs on there.

So what do you mean by "proper privat blockchain" - what specifically
does that blockchain do to achieve trust?

How does the EPA know the computations were done accurately?

> >In the Bitcoin world I think it's fair to say that most experts are very
> >concerned about the high, and increasing, % of users who use SPV clients
> >rather than run full nodes. While it's hard to predict exactly when this
> >threshold is reached, at some point too few people will be actually
> >verifying the blockchain to sufficiently strongly incentivise miners to
> >follow the rules. For instance, at some point miners can great bitcoins
> >out of thin air to increase their profits.
> 
> 
> Yep - big problem with mainnet.  Fundamental problem here is that
> energy enjoys economies of scale.  If all you are doing is
> converting energy into zeroes, then next door to a Chinese
> powerplant is the best deal going.  If anyone's read the novel
> Accelerando, there are better alternatives coming, for now we're
> stuck with China.

The experience of China is the opposite to the idea that energy enjoys
unlimited economies of scale - the Chinese mining community is
relatively decentralized across China operating farms in a whole variety
of locations. There's a limit to how much cheap/free energy you can get
in one place and how much waste heat you can easily get rid of.

> >Instead there has been work done on going the other direction: using
> >better math to make verifying the blockchain cheaper and more practical.
> >But again, this isn't an example of trustworthy computing! It's standard
> >trustless computing, made more efficient by clever math.
> 
> 
> What is the difference between trustless computing and trustworthy
> computing?

I define trustless computing simply to mean I prove to you I did some
computation accurately with undeniable math. The easiest way to do that
is for you to repeat the computation yourself - the way Bitcoin works.

If we're going to make a meaningful distinction between that idea - what
cryptography does all the time - and "trustworthy computing" the only
concept that comes to mind is schemes that try to use non-cryptographic
techniques to get trust out of systems. (remember the definition of a
trusted component being something that can screw you over) TPM hardware
is one such example; the economic incentives in Bitcoin another
(possible) example. (albeit one apparently undermined by a lack of
verification!)

-- 
'peter'[:-1]@petertodd.org
00000000000000000462dd70a1d1f9c5d26e8c1b08ae9fd2641e918ae42f7725
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151009/235c4cee/attachment.sig>