op_energy_notes.txt

TODO:

For best results, OP_ENERGY should be adopted in conjunction with bip "Prevent Manipulation of Transaction Fee rate by Miners."

Todo: write bip "Prevent Manipulation of Transaction Fee Rate by Miners".



Further mitigating this attack is that nodes could mark "suspicious" blocks with significantly out of expected fee rate transactions, and delay them as confirmed, to increase this risk.  See bip "Prevent Manipulation of Transaction Fee Rate by Miners.


***************************
review old definition:
OP_ENERGY redefines the NOP_TBD1 opcode. It takes two block numbers as arguments, and prices the cost in hashes to mine this span of blocks. A working miner is more likely to find a block within a given span if competing total-network hashrate during the span period is lower than expected, and less likely if hashrate is higher. So the price in hashes is adjusted accordingly. Longer spans allow more accurate measurements, shorter spans more granularity in trading. 

<pre>
OP_ENERGY block1 block2 = hashes / satoshis 
  where 
      hashes = expectedHashes * ( expectedSeconds / seconds )
            where
              blocks = block2 - block1
              expectedSeconds = 600 * blocks
              seconds = mediantime (block2) - mediantime (block1)
              expectedHashes = chainwork (block2) - chainwork (block1)
      satoshis = chainRevenue(block2) - chainRevenue(block1)
            where chainRevenue(block) = sum of all miner rewards (subsidy + fees) up to this block
/ = integer division done on uin5256 integers, same as target, and throwing out remainder
</pre>
can anything here be salvaged?




Increasing hashrate implies more expensive (in hashes) future bitcoin, and an efficient market should discount this to make present bitcoin more expensive as well. Indeed, 
todo(much of this should go in motivation section)





 this suggests higher demand for new blocks, and a higher probability of an upward difficulty adjustment in future. An efficient market should translate more expensive future bitcoin into higher prices in the present. 
***************************



black scholes an approximatin
  assumptions
    increments are independent (not true) (?)

binary call on difficulty might be easier

maybe take more financial pricing out of bip, move it into whitepaper


earlier definition
<pre>
satoshis = subsidy (n) + fee (n)
blocktime = mediantime (n+1) - mediantime (n)
hashes  = ( 2 ^ 256 / target (n) ) * ( 600 / blocktime )
price = hashes / satoshis
</pre>


need to understand chainwork better. Can OP_ENERGY be more simply expressed in terms of chainwork? 
  Although it's exposed in jsonrpc interface, it's hard to find good documentation on this. 
  So it seems like you could also get hashes from a to b by subtracting chainwork(b) - chainwork(a)
   https://bitcoin.stackexchange.com/questions/26869/what-is-chainwork


https://github.com/bitcoin/bitcoin/blob/4326515f01d7938bb448e7a9338dcc9c98497847/src/chain.h
    //! (memory only) Total amount of work (expected number of hashes) in the chain up to and including this block
    arith_uint256 nChainWork{};

/** Return the time it would take to redo the work difference between from and to, assuming the current hashrate corresponds to the difficulty at tip, in seconds. */
int64_t GetBlockProofEquivalentTime(const CBlockIndex& to, const CBlockIndex& from, const CBlockIndex& tip, const Consensus::Params&);


https://github.com/bitcoin/bitcoin/blob/4326515f01d7938bb448e7a9338dcc9c98497847/src/chain.cpp
"arith_uint256 GetBlockProof(const CBlockIndex& block)
{
    arith_uint256 bnTarget;
    bool fNegative;
    bool fOverflow;
    bnTarget.SetCompact(block.nBits, &fNegative, &fOverflow);
    if (fNegative || fOverflow || bnTarget == 0)
        return 0;
    // We need to compute 2**256 / (bnTarget+1), but we can't represent 2**256
    // as it's too large for an arith_uint256. However, as 2**256 is at least as large
    // as bnTarget+1, it is equal to ((2**256 - bnTarget - 1) / (bnTarget+1)) + 1,
    // or ~bnTarget / (bnTarget+1) + 1.
    return (~bnTarget / (bnTarget + 1)) + 1;
}"
"int64_t GetBlockProofEquivalentTime(const CBlockIndex& to, const CBlockIndex& from, const CBlockIndex& tip, const Consensus::Params& params)
{
    arith_uint256 r;
    int sign = 1;
    if (to.nChainWork > from.nChainWork) {
        r = to.nChainWork - from.nChainWork;
    } else {
        r = from.nChainWork - to.nChainWork;
        sign = -1;
    }
    r = r * arith_uint256(params.nPowTargetSpacing) / GetBlockProof(tip);
    if (r.bits() > 63) {
        return sign * std::numeric_limits<int64_t>::max();
    }
    return sign * r.GetLow64();
}"
https://github.com/bitcoin/bitcoin/search?q=nChainWork

https://github.com/bitcoin/bitcoin/search?q=GetBlockProofEquivalentTime

"This answer doesn't precisely define "work". The work of a block is actually defined as floor(2^256 / (target + 1)), where 'target' is the target threshold converted from the 'nBits' field of the block header. (See the GetBlockProof function in src/pow.cpp.) – Daira Hopwood Feb 4 '17 at 4:45"
https://bitcoin.stackexchange.com/questions/29742/strongest-vs-longest-chain-and-orphaned-blocks



Alternative definition
(Alternative definition: 
  One block: target * delta * revenue (lower numbers are a higher price)
  Multi blocks: sum(individual prices) (don't need to normalize)
I prefer the sum of prices definition because... why? 
Does it have to do with pricing around halvings? 
Maybe I should try it both ways and see which one gives nicer prices.
The current definition also has the advantage that it avoids division.)



Hashrate is difficulty target * time delta
  The lower it is, the higher the hashrate.
  Need to make sure there are no overflows. 
  Need floating point multiplication. 



Next topics.
Lightning example, with routing

It's the same contract as before, but now Alice wants to buy it from Charlie, routing through Bob. It seems to me this is possible, reusing the construction described before by ZmnSCPxJ. The initial channels are set up in the usual way. Then Charlie negotiates a futures contract with Alice. A signed but unbroadcasted futures sale contract is created between all three participants, using lightning routiung. After everything is signed the lightning route looks like (ignoring routing fees).

Alice <- 100 (FutDiff 30) 70 -> Bob <- 52.6 (FutDiff 30) 117.4 -> Charlie




Within a 2016 block difficulty regime, the remaining blocks are more or less energetically expensive depending on how quickly they are found. This, the constantly varying hashrate, is gauged with a difficulty and a timestamp delta. 

Moving forward (note to self), it may be time to prioritize breaking the bip down into a smaller technical focused bip, with the non-core material broken out into supporting documents: whitepaper, or others . This is the same problem I identified in my last "summary" email to the john maeck group. Onboarding is too difficult now. 
I'd like to do another phone call today if that's ok. It really helps me to have another person to bounce ideas with. Rubber ducking?






Polemic stuff


<pre>
Todo: would it be better to measure the inverse? IE, bitcoin price of hashes? 
  Pros: energy traders care about price of energy
        harbinger of future where everything is priced in bitcoin
          Then again, if the price of bitcoin is more volatile than the price of energy, it makes more sense for now to price bitcoin in energy than the other way around.
  Cons: chart wise, it looks like inverse price of use price of bitcoin, which is what most people care about today, which is confusing
        Price is dropping hugely over time, resulting in tiny number. We could scale it up at the beginning I suppose. 
        Floating point can be used for fractions. 
</pre>

This price is a lagging measure, but over long timespans roughly corresponds to real world energy prices. 


Over long enough periods of time, the energy cost of mining a bitcoin is roughly the hashrate divided by the block reward. That is, in a given block reward regime, if the hashrate doubles, it takes twice as much energy to mine the same bitcoin. All other things between equal then, it should take half as much bitcoin to buy the same amount of energy. This is obviously not always true over short timespans, but it is true in the long run, and this fact can be used to speculate and/or hedge energy priced in bitcoin. 

So, a


these two opcodes enable a wide variety of instruments for pricing the future price of energy in bitcoin. 

In this fashion

Market forces obscure the correlation, particularly during price extremes (crashes and manias), but over a long enough time frame, the relationship holds quite well. It can be used to speculate, trade, and hedge. -- this should be its own blog post, or white paper.


Since energy is currently priced in fiat currency, one could also, albeit indirectly, speculate on the bitcoin price of fiat. 

With cheap, private, anonymous, safe difficulty speculation on chain, it is not inconceivable that one day the majority of energy trading will migrate to the bitcoin blockchain. Transaction fees generated by such an immense volume of transactions would help keep bitcoin secure as the block reward dwindles. 

More near term, on chain difficulty speculation would likely be used to attempt to fiat trade by proxy, on chain. The on chain proxy trade is inferior to what is available on centralized exchanges, in terms of tracking prices with accuracy. However, it has the benefit of being private, anonymous, and without counterparty (or oracle) risk. Many centralized fiat exchanges exit scam. Another benefit: gains are also paid directly in bitcoin, meaning reduced friction getting in and out of fiat. With low liquidity and primitive market structure, attempts to trade fiat by proxy will be of uncertain quality, but the better the liquidity the closer the on chain energy proxy will track fiat, and not just energy, prices. This reduces the need for centralized fiat exchanges, which are a serious weakness for the bitcoin ecosystem. 

That being said, centralized exchanges may also benefit from OP_BLOCKDIFFICULTY. Exchanges have first look at trades conducted on their own exchange, and this can be used for arbitraging on-chain trades that they market-make.


(difficulty) This is a unitless number, but it roughly tracks real changes in energy prices, when the pricing is done in bitcoin. So


My personal intuition is that it would be easier to build up a market around the first technique, with a joinmarket-like feel, as it composes more nicely. Ultimately the free market decides. 


Fuck! Do I need to build a floating point representation in Haskell?
  Nah! Might be fun though,. 



=== Synthetic Derivatives ===

Two ways to do this. 
1) more cases in a single output
2) build up transactions out of multiple outputs (perhaps similar to conjoin pool with makers and takers)




 by composing these simple binaries. By adding more price ticks to the synthetic futures, such compound synthetic derivatives can be made arbitrarily granular, at the expense of higher transaction costs.





https://duckduckgo.com/?q=wikipedia+binary+options&ia=web



Transactions costs themselves can be defrayed by transacting the option contracts using lightning channels. If difficulty speculation proves popular, this will grow the lightning network, which generates transaction fees for miners. There may also be privacy opportunities from combining binary markets with conjoin or other mixing protocols. 

Contract sellers with many lightning channels open can earn bitcoin by making markets. 







Centralized exchanges benefit, 
































Op_energy notes

==Motivation==

During a block subsidy regime -- that is not crossing a halving boundary -- difficulty is the price of bitcoin in energy. Difficulty target is the price of energy in bitcoin. 
The relationship is not perfectly 1 to 1, but it roughly tracks over time. If the difficulty target halves, the energy price of bitcoin doubles. And for bitcoin holders, the price of energy in bitcoin halves. (Roughly.)

This all means that making the block difficulty target visible to script makes a variety of non-custodial, non-oracle requiring, synthetic energy derivatives available for on-chain settlement between untrusting parties.

=== Cash or Nothing Binary Option on Difficulty === 

https://en.wikipedia.org/wiki/Binary_option

Alice bets Bob that the difficulty will increase at the next adjustment. Hashrate looks weak, and the adjustment is coming soon, so Bob is willing to give Alice 2 to 1 odds on that. Alice pays Bob 5,000 sat to buy the option. Bob puts 10,000 sat into a binary that matures at the next adjustment. If the difficulty rises Alice can spend it, otherwise Bob can spend it.

The binary has two outputs, which confirm as a single transaction, created collaboratively in a zero-trust way. 
Output 1: Alice pays Bob, spendable immediately by Bob.
Output 2: The binary. Spendable at maturity. To decide who wins it compares difficulty at bet time, with difficulty at maturity. 

=== Bounded Difficulty Future === 

Binaries are the atoms of op_difficulty derivatives. Synthetic futures, puts, calls, etc, can be built up from binaries. Here is an example that builds up a future, using "ticks" of binaries. 

Alice wants to buy a future from Bob. As with the binary, Bob gets paid up front, and funds the contract. The contract pays out at the maturation block. Depending on the difficulty then, the payout could go to all Alice, all Bob, or some to Alice and some to Bob. 






Current difficulty is 10 Trillion. Alice and Bob figure that the difficulty won't rise or fall by more than 20 percent, by maturity time. So the future is capped at 8T on the low end, and 12T at the high end. Alice and Bob agree on 5 ticks, at 8, 9, 10, 11 and 12T. Each of these ticks is a cash or nothing binary similar to the previous example. If the final difficulty is over 12, all of 

=== Lightning Trades === 

=== Anonymity Pools ===













If this is not the case, then a second opcode OP_DIFFICULTY_LESSTHAN is required.)


Current version bits. 
645347 (current)      171007ea
644618                17109bac



Prelude> (0x1007ea) / (0x109bac)
0.9652471270492857


(Note for reviewers: I believe difficulty targets in packed bits can be compared using the already live OP_LESSTHAN opcode

https://en.bitcoin.it/wiki/Script#Arithmetic

If this is not the case, then a second opcode OP_DIFFICULTY_LESSTHAN is required.)

op_difficulty

what is on the chain is the difficulty target. 
interesting to watch this not change in the beginning of time, and then take off when mining gets going. 





dectoHex x = Numeric.showHex x ""



let 

<let bitsToDiff exponent mantissa = 
  let target1 = ( 0x00ffff * 2**(8*(0x1d - 3)) ) 
       currentTarget =  ( mantissa * 2**(8*(exponent - 3)) )
  in  target1 / currentTarget>



Hashes = D * 2**256 / (0xffff * 2**208)
       = (target_genesis / target_current ) * ( 2**256 / (0xffff * 2**208) )
       = (target_genesis / target_current ) * ( 2**256 / target_genesis )
       = 2**256 / target_current




hashprice_block target blocktime subsidy fee = ( (2 ** 256) / target ) * ( 600 / blocktime ) / (subsidy + fee)







hashes = ( 2**256 / target_current ) * ( 600 / blocktime  )
  Need a floating point algo to give an exact number here. 
  Maybe to make it expressible 
  But let's try something simpler 






price_genesis: 

<pre>
revenue(genesis block) = ( 50 * 100,000,000 ) + 0 
blocktime = 600
hashrate = unpack(0x1d00ffff) / ( unpack(0x1d00ffff) * blocktime ) 
price = 50 * 100000000 * 600 = 3e12
</pre>





Genesis target: 0x1d00ffff
  (bx 0001 1110 0000 0000 1111 1111 1111 1111)
0x00ffff * 2**(8*(0x1d - 3))


(bx 0000 0000 1111 1111 1111 1111) * (bx 10) ** ((bx 1000) *(0x1d - (bx 1000)))



data visualization:

    could try gnuplot
    https://riptutorial.com/gnuplot/example/12382/plot-a-single-data-file

    d3
    https://www.freecodecamp.org/news/how-to-build-historical-price-charts-with-d3-js-72214aaf6ba3/

    make csv files first
    make upwork job posting for data viz guy. ask for ability to zoom in. 

    maybe make a research task for getting btcusd historical data from one or more sources

Pipes.Attoparsec
Pipes.Tutorial


unshelve and retrieve notes


average block reward during subsidy epoch is 3 btc -- (21e6 * 1e8) / ( (2140 - 2009) * (365 * 24 * 6) ) 
assume that miner fee revenue is 10x average block reward, to be safe -- this seems unrealistically high.
So total revenue < 33 btc / block. Is 64 bits safe? 
100,000 years, seems safe enough -- ( 2^^64 / (33e8) ) / (365 * 24 * 6)  => 106353.16


existing hash markets
    hashrate futures at ftx
    nicehash
        https://www.nicehash.com/my/marketplace/SHA256
        https://www.nicehash.com/support/hash-power-marketplace/general-help/how-to-start-as-a-buyer-of-hash-power
        https://static.nicehash.com/marketing%2FBuying%20Guide_En.pdf
    peernova used to do it, see if johnny dilley can make an intro
    try to connect to local miners or former miners in san juan / rincon

    https://medium.com/@ethansanchez7/tips-and-tricks-on-what-to-take-into-account-when-you-are-own-of-large-asic-farms-2581f5e3747c
    https://www.youtube.com/watch?v=1uqohzL_iDM&t=2s    How to connect ASICs to Hive OS | How to Install and Setup Hive OS| ASIC mining

    mining and hashrate regulation (minerupdate.com)
    btc/usd prices at instruments.kaiko.com

speeding thigs up (maybe not needed)
  https://hackage.haskell.org/package/text-1.2.3.1/docs/Data-Text-Lazy.html#g:5
  https://hackage.haskell.org/package/parsec-3.1.14.0/docs/Text-Parsec-Text-Lazy.html

analyzing weaknesses, risks
  bitcoin wiki confirmation 
    pdf, analysis of hashrate based couble spending
  wikipedia, poisson distribution
  upwork, find a statistician (or ask kevin, or rob z)
  icepac, power tools for epidemiologists
    from google poisson distribution sample size (ie how many blocks, maybe put a minimum on op_energy measurements)
  look at code for getmininginfo, gettxoutsetinfo bitcoin-cli rpc call, how does bitcoin measure hashrate
    I'm assuming this changes with every new block, if it chsanges more often, might be good to know that
    or does it only work if you're mining?

price feeds
  https://www.kaggle.com/mczielinski/bitcoin-historical-data


i believe op_energy is more useful to miners than hashrate
  (can i convince a miner of this)

get audience more segmented
  bip
  whitepaper
  nontechnical (blogs)





https://twitter.com/BitOoda_Crypto
http://bitooda.io/
https://medium.com/efficient-frontier/the-new-financial-tools-for-bitcoins-mining-industry-15801e9a0db1













As an aside, target is stored as a uint256 bitcoin block header field. 
GenesisTarget, the bits target of the bitcoin genesis block, is uint256 encoded in the genesis block as 0x1d00ffff. 
The unpacking to a 256 bit target is as above.




===OP_EXPECTEDENERGY===

The rationale for the hashrate-adjusted price is that faster blocks suggest hashrate is increasing, ie bitcoin is becoming more precious. If the expectation is that the price will rise in the future, this should be reflected by some increase in the spot price. The game theory of mining bears this out. If a large difficulty adjustment is expected, a rational miner with a fixed energy budget would prefer to turn on more miners pre-adjustment, and then turn them off post. IE, he values bitcoin in hashes more highly towards the end of a difficulty regime with an expected large future adjustment.   

Another way of looking at it: every hash is a lottery ticket that has an equal chance of winning some block. However, if the goal is to mine a specific block (or span of blocks), a working miner is more likely to achieve this if competing total-network hashrate during the span period is lower than expected, and less likely if hashrate is higher. 

Hashrate measurements over a short span of blocks are not very meaningful, but this is not disallowed by the proposed mechanism. Longer spans allow more accurate measurement of hashrate trends, shorter spans more granularity in trading. Traders are free to take positions as they wish, or gamble in the case of very short spans. 

Dev Bitcoin Question. 

Does variation in hashrate within a difficulty regime have any effect on rational miner behavior? 
Should higher network hashrate make you want to turn on more personal miners, or the opposite, or neither?
Have there been any papers / studies / guides on this topic? 
  Starting points: the r/bitcoinmining question I asked, which was also answered


patrick dugan call. he knows: 
  grid, 
  james macavity (miner, wants year duration)
  jim buy
  jack mallers
  jack mallers and bitcoin tina, conversation
  market making is hard
  lnmarkets doesn't do custody? how does that work technically?
  patrick likes crosstower
  FCM? Futures Contract Merchant
  If you're not doing custody, what's the next issue? "It's not custody."
    CFTC got abra. Justice went after abra too.
  OECD side, china side
  "more opcodes"
  gambling app, kyc everybody
  incorporate in country that doens't have crs reporting, don't have that de minibus thing
  become #1 gateway, for after opcode goes live
  jumio, helps with tokens? mati. has de minimis threshold, then it's $1/head.
  next steps: 
    exchange licensing. license jim's exchange
    help with data and backtesting
    lead gen
  who is long difficulty?
  matching is a regulated function too
  mining securities
  bitcoin liquid index
     $10,000, brave new coin
     *** coauthor article for deribit insights ****
     bandwidth later this month
     look at r2 of hashrate (and/or op_energy) btc to usd.
     it would be cool if op_energy worked better than hashrate.





fee manipulation:
  https://cis.temple.edu/~jiewu/research/publications/Publication_files/jiang_blockchain_2019.pdf
  https://scalingbitcoin.org/stanford2017/Day2/redesigning-bitcoin-fee-market.pptx.pdf
  https://www.reddit.com/r/Bitcoin/comments/glbc8n/game_theory_of_fees_may_cause_artificial/

r^2 regression analysis
  https://www.investopedia.com/terms/r/r-squared.asp

  clark moody intro


subject: can you sell me (or better still donate) well wrangled btc/usd historical data. Also wanted to tell you about my project because I think you may find it interesting as a fellow bitcoin maxi (OP_ENERGY)

Hi Clark Moody! I am thomas hartman / standardcrypto. Saw you on taproot activation telegram, and decided to email you out of the blue because there's something I need help with, and I think you may both find it of interest and be in a position to help. 

I'm a big fan of your dashboard (checking multiple times a day). Mostly I am interested in mining statistics. I am working on a statistic of my own that I hope will gain popularity in the community and potentially even lead to a protocol upgrade.

My project, "OP_ENERGY" -- 

https://github.com/tphyahoo/bip-thomashartman-op_energy/blob/master/bip-op_energy.mediawiki

tldr: OP_ENERGY measures the cost to mine a single satoshi between two blocks. This can be treated as a price, given in hashes, for energy derivative contracts that can be written and settled on chain. (No oracle required. Similar to powswap / OP_DIFFICULTY if you are familiar with these.)

I'm wondering if you could help me on my OP_ENERGY quest, by providing me with historical btc/usd data at a ten minute (because blocks are 10 minutes) resolution. Either donating if you like my project, selling if this is your business model, or advising me what is the best / most economical way to aquire this data. 

If you donate this, I will promote your dashboard and say nice things about you, and basically do whatever I can to help. Easy, because I'm already a fan. Also open to buy the data if that's your preference and it's something you normally do.

My best bitcon maxi writing is (imho) https://taaalk.co/t/bitcoin-maxima-other-crypto-things

Blog is https://standardcrypto.wordpress.com

I need the btc/usd data to do a regresion test on OP_ENERGY (hashes/satoshi) versus the btcusd price. As part of selling the concept. Of course I would not resell this data. If it is easy for you to do the regression analysis yourself, another option would be to hire you to do this, credit clark moody as the source for the report, and then I wouldn't need the data nor be in a position to resell it if that's something you care about. 

As a final thought, if you like OP_ENERGY, I would love to have this incorporated into the clark moody dashboard. 

Either way, thank you for your dashboard. Also it would be great to chat some time.

best, thomas.



powswap issues
  is there an issue with powswap, where you need watchtowers?
  I think I asked on list about this, and jeremy rubin said no and gave an example, but I didn't understand it. 


==Units: Converting from Difficulty to Hashes==


pure mathematical function of target bits, which is what is actually stored in block headers: Difficulty(block) = targetBits(genesis_block) / targetBits(block).




So, a block with difficulty D requires D * genesis_hashes (2**32 hashes), to mine. The bitcoin-cli getblockheader command gives summary information on both chainwork (number of hashes to mine the entire chain, in hashes), and difficulty (number of hashes to mine the block, in difficulty units). The relationship between these two quantities is

<pre>
chainwork(blockN) = hashes(blockGenesis) + hashes(block2) + ... hashes(blockN)
  where hashes(blockX) = difficulty(blockX) * genesis_hashes
        genesis_hashes = 2**32
</pre>

deleted this, don't think it's needed: The chainwork delta of a single block (chainwork(blockN+1) - chainwork(blockN)) is the expected number of hashes needed to calculate this block.