Published on: 2020-09-02T18:27:00+00:00
In a recent bitcoin-dev mailing list discussion, there have been proposals and discussions regarding the implementation of difficulty futures in Bitcoin. Tamas Blummer had initially proposed an additional opcode for enabling Bitcoin difficulty futures, but Jeremy Rubin introduced an alternate scheme that does not require changes to the Bitcoin protocol. This scheme takes advantage of the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposal involves creating conflicting spends from a multisig, with different nLockTime values based on the current height or time. Depending on the subsequent change in hashrate, either Alice or Bob will receive their payment first. This method can be embedded in a taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.Thomas Hartman expressed admiration for Powswap, a platform that allows users to bet on the future hash rate of the Bitcoin network without protocol changes. However, he raised concerns about watchtowers to prevent fund sweeping by the losing party and the impact on lightning channels. Hartman also suggested the possibility of betting on specific time slices and difficulty thresholds using Powswap. Currently, Powswap only creates contracts from the current time to the future, but Hartman proposed creating synthetic hashrate binaries by subtracting the time from the current time to B from the time from the current time to A. He also questioned the feasibility of betting on the first six blocks after retarget being found under an hour and the new difficulty exceeding a certain threshold.The community mourned the loss of Tamas Blummer, a developer who proposed the opcode for Bitcoin difficulty futures. Jeremy Rubin's scheme was introduced as an alternative method that does not require protocol changes and leverages the difference in maturation time between timelocks and height-locks caused by changes in difficulty. The proposed scheme is compatible with off-chain commitments and can be embedded in a taproot commitment using OP_CLTV or OP_CSV. The author of the discussion proposed using a packed difficulty target instead of using op_diff to calculate the ratio, and expressed their satisfaction with not having to deal with floating point numbers.Tier Nolan proposed a new method for speculation contracts that considers the ratio between future and current difficulty instead of difficulty itself. This ratio can be obtained from packed representations already included in blocks. Nolan provided an example using the current and last difficulties and targets, demonstrating how op_diff could return the ratio for ticks instead of difficulty.The discussion explored the creation of difficulty futures instruments using Taproot MAST and op_diff. The proposed idea involved creating partial versions of difficulty futures funded by Bob and spendable by Alice after a certain number of blocks. A payment from Alice to Bob with a hash lock was also suggested to enable this process. While it would be simpler to have all outputs in the same transaction, the proposed construction requires two signatures for the hash-branch to ensure specific contract payouts.In another email thread, a solution to binary payouts was discussed. Taproot MAST was suggested as an option, and another proposal involved paying outputs based on the diff value using division and binary operators. The payout would be enabled or disabled based on the value of D. This solution has logarithmic performance in terms of the number of ticks.Taproot MAST was mentioned again as a potential solution to enable difficulty futures instruments. The proposal focused on creating partial versions of difficulty futures funded by one party and spendable by another party after a certain period of time. A hash lock on the payment with a preimage secret was suggested to ensure the correct execution of the contract. The goal is to eventually implement this with lightning and high-frequency trading.Thomas Hartman proposed adding an opcode called "op_difficulty" to enable binary options on difficulty futures. However, another approach suggested using taproot's annex concept to create restrictions based on specific difficulty values or ranges. Participants would deposit into a UTXO and construct signed payouts timelocked for the future date. The payouts would go to different parties depending on the predicted difficulty range. Specifying an exact value for the difficulty was considered better for privacy, but it would require multiple signatures for pre-signed payouts.The discussion also touched upon the concept of binary options and pseudo-continuous futures. It was suggested that any opcode can be considered a binary option, but creating numerous outputs with different thresholds is necessary for a pseudo-continuous future. Taproot MAST was mentioned as a way to improve this method by generating fresh keypairs and tapleaf scripts.Another proposal for enabling binary options on difficulty futures involved using an operation called "op_difficulty" or taproot's annex concept. The protocol design included participants depositing into a UTXO and constructing signed payouts timelocked for the future date. The payouts would be based on specific difficulty values or ranges.
Updated on: 2023-08-02T02:37:38.474787+00:00