[bisq-network/proposals] Implement Hashrate Derivatives (#298)

huey735 notifications at github.com
Thu Jan 21 13:45:10 CET 2021


> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

<!-- Please do not remove the text above. -->

## Description

Alice and Bob want to bet on how many blocks the bitcoin network will produce in a certain period.

On 2021/01/21 12:00:00 (1579608000) at block 667016

Alice: I bet there will be 2016 blocks produced in the next 2 weeks. In other words the chaintip will be equal or higher than 669032 by 2021/02/04 (1580817600).

Bob: I believe that it will produce more than that.

Both of them agree on an amount and send funds to a 2-of-2 multisig controlled by both of them.

If Bob is right, the block height (669032) will happen before the date Alice mentioned (1580817600) so Bob gets a payout transaction sending funds from the multisig to him with a block-height-locktime of 669032 .

And Alice gets a transaction sending funds from the multisig to her with a timestamp-locktime of 1580817600.

It's important to note that Bob could also have taken Alice's bet on the opposite side. That there would be less blocks produced in that time. In this case Alice would get the payout transaction with the block-height-locktime and Bob the one with the timestamp-locktime. The one who believes more blocks will be produced in a given period gets the payout with block-height-locktime.

## Risks
### Bitcoin miners

The timestamp, unlike the block height, [is relatively malleable (required reading)](https://blog.bitmex.com/bitcoins-block-timestamp-protection-rules/). Which means that there should be a lower-bound time safety measure.

More on the topic:
- [Twitter thread by Rene Pickhardt](https://twitter.com/renepickhardt/status/1266478238047617038)

### Blockspace market
Given a volatile blockspace market it's important that we be careful that the [transaction depositing funds into the multisig be confirmed in a timely manner](https://github.com/bisq-network/proposals/issues/287).


## To consider
### Start simple
There are many ways to tinker with this derivative: odds, possibility to renegotiate the derivatives, time-frames for the bet, etc. We should focus on implementing the simplest version first and later consider changing it to add more aspects it.

### Broadcasting the Payout transaction
By the end of the exchange between Alice and Bob, each will have a bitcoin transaction that becomes valid after a certain point in time. We can:
- leave the responsibility of the broadcasting to them - this is simpler to implement and leaves all the responsibility to the individuals
- have Bisq provide the service for them - this require more work and puts more responsibility on the Bisq Network

### Reduce interactivity with the Bisq wallet
It'd be great to somehow reduce the time the funds would need to be controlled by Bisq's hot wallet keys. We should aim for the users to be able to fund the bet from an external wallet and get the payout in an external wallet. This would possibly increase the amounts being bet on.

### Fees
For trading Bisq, currently has a fee model with a lower bound of 5k sats per trader or a set percentage. X for offer makers and Y for offer takers where the X and Y don't change despite the trade amounts.

This may not be ideal for bets with ranging hypothetically from 0.1 btc to 100 btc.

### Reduce trade protocol to 1 single transaction
The current trade protocol involves 4 transaction:
- maker trading fee
- taker trading fee
- deposit into mulsitig
- payout

[**This may be reduced to a single transaction**](https://github.com/bisq-network/proposals/issues/279).

### How to present this
It's important that we decide on a visual language that can minimize interpretation errors. @pedromvpg


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/298
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210121/a367f4ba/attachment.htm>


More information about the bisq-github mailing list