back to using regular integers for everything, except final pack step

bip-op_energy.mediawiki

@@ -23,7 +23,7 @@ todo: maybe this should be future_energy_price
 Roughly, price is: 
 
 <pre>
-(miner hashes / miner revenue) * (expected seconds / actual seconds) 
+(miner work / miner revenue) * (expected seconds / actual seconds) 
 </pre>
 
 Assuming stable revenue: 
@@ -37,23 +37,30 @@ So, generalizing from difficulty epoch to any block span, price is expected futu
 The exact definition is: 
 
 <pre>
-op_energy_price block1 block2 = ( hashes * expectedSeconds ) / (actualSeconds * satoshis)
+op_energy_price block1 block2 = pack_uint256 price'
   where        
-      hashes = chainwork (block2) - chainwork (block1) 
-      satoshis = if revenue == 0 then 1 else revenue 
-            where revenue = chainRevenue (block2) - chainRevenue (block1)
+      price' = ( work * expectedSeconds ) `div` (actualSeconds * revenue)
+      work = chainwork (block2) - chainwork (block1) 
+      revenue = if revenue' == 0 then 1 else revenue'
+            where revenue' = chainRevenue (block2) - chainRevenue (block1)
                   chainRevenue is sum of all coinbase rewards (coinbase) up to this block
-      expectedSeconds = pack ( 600 * (block2 - block1) )
-      actualSeconds = pack ( median_time_past (block2) - median_time_past (block1) )
-        where median_time_past is median time of previous 11 blocks as defined in bip 113
-      inputs -- chainwork, chainRevenue, expectedSeconds, actualSeconds -- are cbits compressed.
-      arithmetic operations -- subtract, multiply, divide -- are on cbits
+      expectedSeconds = 600 * (block2 - block1) 
+      actualSeconds = if actualSeconds' = 0 then 1 else actualSeconds'
+            where actualSeconds' = median_time_past (block2) - median_time_past (block1)
+                  median_time_past is median time of previous 11 blocks as defined in bip 113
+      pack_cbits = compress integer, ie same compression used for target in block header
 </pre>
 
-
 * Due to cbits packing, there could theoreticaly be overflow issues, ie if chainWork overflows 2^256. But, practically, this seems to be impossible. Because bitcoin is already using on the order of 0.1% of global energy. A great many orders of magnitude more than 1000x would be required for overflow to be a problem. 
 
-* ActualSeconds is guaranteed to be positive, as the 11 block median time past increases with every block. This is because, per protocol rules, the block time stamp must be greater than the block median time past <ref>https://en.bitcoin.it/wiki/Block_timestamp</ref>.
+* ActualSeconds should be guaranteed to be positive. Because the 11 block median time past should increase with every block. Because, per protocol rules, the block time stamp must be greater than the block median time past <ref>https://en.bitcoin.it/wiki/Block_timestamp</ref>.
+However, while true in theory, this seems not to be the case in practice. 
+eg, blocks 646123 and 646124.
+This is why there is a divide by zero check for actualSeconds. That is, not needed in theory, but seems to be needed in practice.
+Todo investigate further. 
+
+todo: is pack_cbits(1) nonzero? It should be, but just have brian sanity check this.
+Otherwise I could see a potential issue with divide by zero for actualSeconds. If so, can do the same set to 1, as for satoshis. 
 
 ===Script Interpreter Behavior===