Every financial market has bets, some are bets on the availability of a certain product, the price of a certain product at a certain point in time and on productivity and all markets depend on supply and demand, in metal markets the supply is the amount of metal that was produced this year, in Bitcoin that amount is fixed so people can’t bet on it. What you can bet on is how much it costs to mine Bitcoin at a certain time, specifically the difficulty, as the difficulty rises miners need more powerful, and probably more expensive, machines to be able to compete.

For anyone wanting to enter the mining business, this is the biggest risk there is, and while commodity markets offer futures and options to hedge risks, currently Bitcoin doesn’t employ this.

That’s why developer Tamas Blummer suggested the OP_DIFFICULTY, an opcode to enable hedges without any 3rd party interference, settled on the blockchain.

Nayuta, a team currently developing a new Lightning Network implementation called ptarmigan, announced the release of a wireshark plugin for the Lightning Network (BOLT) protocol. The plugin is hosted here.

It’s alpha version, but it can decode some BOLT message. Currently, this software works for Nayuta’s implementation(ptarmigan) and Éclair. When ptarmigan is compiled with some option, it write out key information file. This Wireshark plug-in decode packet using that file. When you use Éclair, this software parse log file.

Alejandro Ranchal Pedrosa and Tucci-Piergiovanni proposed a new BIP to extend OP_CSV¹ and/or OP_CLTV² to allow and interpret negative values.

The discussion that followed concluded that the BIP would be breaking a fundamental rule which is that valid transactions remain valid. This could lead to loss of funds when several transactions are made invalid.

OP_RETURN code has some interesting, but highly controversial, applications. It’s used to mark a transaction output as invalid, allowing users to burn bitcoin, its also used to add some data to a transaction or store data on the blockchain, which you shouldn’t do.

Some use OP_RETURN prefixes as a way of confirming that they are behind this transaction, using colored coins or storing data.

Recently there were discussions on how to claim these OP prefixes but some members of the community thought it was a bad idea as it would allow censorship and reduce anonymity.

This relates to an old BIP from 2016, but work on this BIP is still in progress.

Dmytro Piatkivskyi started the following discussion on lightning-dev regarding the topic of channel rebalancing.

There has been a lot of discussion on sending cycle transactions to oneself to ’re-balance’ the network. On LN mailing list [1] or numerous places elsewhere. There has been even a paper suggesting a smart mechanism to do the re-balancing (see Revive or Liquidity network [2]). My question is what do we actually get from it? [3] states that the distribution of funds in channels does not really affect the network liquidity. I can see cheaper fees or shorter paths if the network is kept balanced. But don’t you think that a smart fee strategy will do the job?

To save your time, [4] explains the gist from [3].

• [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
• [2] https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
• [3] https://arxiv.org/abs/1007.0515
• [4] https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31