Proof of Work -> atmospheric carbon

[Jerry Leichter]

On Jan 27, 2009, at 2:35 PM, Hal Finney wrote:

> John Gilmore writes:
>> The last thing we need is to deploy a system designed to burn all
>> available cycles, consuming electricity and generating carbon  
>> dioxide,
>> all over the Internet, in order to produce small amounts of bitbux to
>> get emails or spams through.
>
> It's interesting to consider the ultimate technological resolution  
> to this
> issue. Will a global-scale proof-of-work based system inherently  
> consume
> substantial amounts of energy? Or are there ways of doing computing
> which would allow such a system to use only moderate energy  
> consumption? ...
[Proposals to use reversible computation, which in principle consume  
no energy, elided.]

There's a contradiction here between the computer science and economic  
parts of the problem
being discussed.  What gives a digital coin value is exactly that  
there is some real-world expense in creating it.  We talk about "proof  
of work", but in fact "work" done by a computer doesn't, in and of  
itself, have any value.  It gets a value only when it's a limited  
resource *which might have been used for something else* - i.e., the  
value of the spare cycles that might be thrown at doing the  
computations comes from the opportunity cost incurred.  If this were  
not so, anyone could just create as many as they wanted at no cost to  
themselves.  In fact, this is behind the cost model 'bot herders using  
other people's machines.  But ultimately that only works for the 'bot  
herders because there is no significant loss to the owners of those  
machines either!

Now, if instead we used algorithms not based on some abstraction  
notion of "work", but on the equivalent power that had to be  
dissipated to do the computation, then the value of a digital token  
would truly be grounded in the real world.  Spare cycles would no  
longer be "free" - they would show up on your power bill.  Sure, the  
'bot herders wouldn't have to pay - but if the owners of the "pwned"  
machines saw a real cost, they would have an incentive to do something  
about it (which they basically don't, today).

Eliminating the power cost puts you back to amortizing the fixed cost  
of the CPU and memory doing the computation - a cost that's dropping  
all the time.  I don't see how you get to an economically viable  
mechanism that way.

So, how do you tie the cost of a token to power?  Curiously, something  
of the sort has already been proposed.  It's been pointed out - I'm  
afraid I don't have the reference - that CPU's keep getting faster and  
more parallel and a high rate, but memories, while they are getting  
enormously bigger, aren't getting much faster.  So what the paper I  
read proposed is hash functions that are expensive, not in CPU  
seconds, but in memory reads and writes.  Memory writes are inherently  
non-reversible so inherently cost power; a high-memory-write algorithm  
is also one that uses power.

(BTW, a number of years back, a VC friend ran by me a proposal to buy  
the spare cycles on people's set-top boxes - which have pretty hefty  
chips in them - and rent out the resulting "distributed compute  
server".  The claim was that you didn't have to pay people much of  
anything for use of their boxes - you'd only do it when they were  
otherwise unoccupied, so they should be happy to get even very small  
payments.  I pointed out the cost they had neglected:  Increased power  
use.  Sure, individuals probably wouldn't notice - but at some point  
some consumer organization would.  The resulting bad publicity would  
kill the business.  We did a bit of calculation to add that in to what  
would be paid to the box owners and the whole enterprise started  
looking less interesting from a purely economic point of view - not  
that it didn't have plenty of other problems.)

                                                         -- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com