Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #27989

Re: Green Array energy consumption: a reality check.

Show key headers only | View raw

On Tue, 21 Jan 2014 07:49:12 -0500, <mszepien@gmail.com> wrote:

>> [discussion over importance of hashing speed for Bitcoin]
>
> The proof of work problem consists of hashing a block containing recent
> transactions, so that the hash has a certain number of leading zeros
> (it's a small bit more complicated than that, see
> [link], but this suffices for the sake of
> argument). In a sense it's true that all machines on the network are
> trying to solve the same problem, but they are all doing it
> independently, by altering a nonce appended to the block, in order to
> try to get the hash value below the target. Thus, the machine which has
> the highest hash rate will, over time, validate the most blocks and thus
> mine the most coins, [...]

For that, we're in agreement.

> [...] but for any given block, it's a matter of chance
> which machine happens to produce the first hash that meets the target.

I think that's a faulty assumption to think it's "a matter of chance
as to which machine happens to produce the first hash that meets the
target."

AIUI, the vast majority of machines using to solve this are using
the exact same code and therefore algorithm.  This means they're
solving the same altered nonces in the same manner.  So, even if
they're using a random number generation to "randomly" attempt
different alterations of the nonce, their PRNG starts from and
runs through the exact same psuedo-random sequence.  I.e., first
come, first wins.

For it to be a matter of chance as to which machine validates a block,
each machine must be using a different algorithm or different PRNG in
order to solve a different altered nonce.  I.e., the probability that
multiple machines are attempting the solve the exact same altered nonce
is seems exceptionally large - IMO - due to the use of the same code
or same algorithm.  Therefore, the fastest machine wins.

> Consider again my two hypothetical machines. Suppose I run them each for
> the same amount of time (averaged over a sufficiently large number of
> blocks), then their relative mining revenue would follow the ratio
> T1/T2, the faster machine having mined more coins. However, this tells
> us nothing about the profitability of either machine,  since we haven't
> factored in the cost of operating them. It is possible that the slower
> machine is the only profitable one of the two, despite having mined
> fewer coins.

True, it's possible, although it's unlikely.  Your assumptions are based
on both machines being successful at mining, and having completely
independent chances of successful mining, and it's unknown as to what
the fixed and operating costs are.

Since the profitability of two machines is relative and on-going, you could
have a $50,000 ASIC that's not profitable for 10 years, and a $3  
microcontroller
that's profitable with just one successful mining.  That's assuming the
micro _ever_ has a successful mining.  It's clear that other machines are
out mining $3 machine so it machine may *never* pay off.  Of course, it's
a more likely scenario the two machines are similarly priced or at least
much closer together in prices.  If one is $4,000 and the other is $5,000
and faster, their profitability depends on their rate of successful mining
versus their cost to operate plus their fixed costs ($4k and $5k).  If the
slower machine has lower electricity operating costs, either due to less
consumption or lower prices, it's on-going costs are increasing at a slower
rate than the $5k machine, but it's costs start from a lower base, i.e.,  
$1K
less, so it has the cost advantage.  However, the rate of successful mining
of the $4,000 machine will be lower since it's slower, i.e., it'll be  
recovering
it's fixed cost plus operating cost at a lower rate too.  It's therefore  
more
likely the more expensive $5k machine recovers it's investment and  
operating
first, but determining exactly where, or if so, depends on a graph (or  
algebra)
which accurately drawn costs.  This of course assumes that both machines'
chances for each and every altered nonce, or hash attempt, or mining  
attempt,
is equal and independent of the other machine, which it isn't.  Machines  
use
the same code or same algorithm or same PRNG and attempt to solve the same  
block.


Rod Pemberton

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Green Array energy consumption: a reality check. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 15:18 +0000
  Re: Green Array energy consumption: a reality check. Tristan Plumb <firth@trstn.net> - 2014-01-12 17:02 +0000
    Re: Green Array energy consumption: a reality check. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 17:27 +0000
      Re: Green Array energy consumption: a reality check. Tristan Plumb <firth@trstn.net> - 2014-01-12 22:40 +0000
        Re: Green Array energy consumption: a reality check. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-12 23:03 +0000
          Re: Green Array energy consumption: a reality check. Paul Rubin <no.email@nospam.invalid> - 2014-01-12 16:54 -0800
  Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 02:45 -0500
    Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 02:54 -0500
      Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 02:57 -0500
    Re: Green Array energy consumption: a reality check. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-13 12:32 +0000
      Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-13 09:52 -0500
        Re: Green Array energy consumption: a reality check. mszepien@gmail.com - 2014-01-19 11:01 -0800
          Re: Green Array energy consumption: a reality check. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 19:38 +0000
            Re: Green Array energy consumption: a reality check. mszepien@gmail.com - 2014-01-19 13:40 -0800
              Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 17:50 -0500
                Re: Green Array energy consumption: a reality check. mszepien@gmail.com - 2014-01-20 12:55 -0800
                Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:34 -0500
                Re: Green Array energy consumption: a reality check. mszepien@gmail.com - 2014-01-21 04:49 -0800
                Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 10:48 -0500
                Re: Green Array energy consumption: a reality check. mszepien@gmail.com - 2014-01-21 14:37 -0800
                Re: Green Array energy consumption: a reality check. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-22 19:30 +0000
    Re: Green Array energy consumption: a reality check. "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-27 16:26 -0500

csiph-web