Implement Hashrate Derivatives

[huey735]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Description

This protocol is inspired by Jeremy Rubin's POWSWAP @JeremyRubin

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). Which means that there should be a lower-bound time safety measure.

More on the topic:

• Twitter thread by Rene Pickhardt

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.

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.

How to present this

It's important that we decide on a visual language that can minimize interpretation errors. @pedromvpg

[chimp1984]

What should be the use case for such a scheme?
It might be useful for miners for some sort of hedge (have not thought about how it makes sense for them, but I can imagine there might be some use case) but the risks involved from the rules how time stamps are regulated in Bitcoin are way too high IMO that miners would consider it a fair contest. For abusing their power to set the timestamp in their favor the larger miners would gain benefit over smaller miners.
Any other serious use case beside pure Casino gambling?

[huey735]

Any other serious use case beside pure Casino gambling?

No.

For abusing their power to set the timestamp in their favor the larger miners would gain benefit over smaller miners.

I believe this can be protected against with enough time between the bet and the times the traders get to broadcast their payout. And it'd require most miners to actively attack the network in this manner for it be a serious threat.
I haven't run the numbers for the above (not sure I am able to) so I may be greatly undermining the threats.

[chimp1984]

I believe this can be protected against with enough time between the bet and the times the traders get to broadcast their payout. And it'd require most miners to actively attack the network in this manner for it be a serious threat.
I haven't run the numbers for the above (not sure I am able to) so I may be greatly undermining the threats.

The winning chances are directly proportional to the mining hashrate power of a miner. So big miners have advantage over smaller ones. I doubt that would be a interesting use case/reason to engage for them anyway, but I don't see any serious hedge use case.

[chimp1984]

Alternative idea: Hedge on miner fees. Make a bet that average miner fees of last 100 blocks at given block is bigger or smaller as a certain value. Again not safe once miners enters the game... but might have some use case for ppl who spend much money on miner fees and it depends on blockchain data only.

[huey735]

I'm attracted to the idea of having the bitcoin network act as an oracle for the bet being made. That reduces greatly the responsibilities of the Bisq network and software. Any data other than blockheight and timestamp would require Bisq or other third party to arbitrate.

[huey735]

There seems to be little interest in this proposal. The few comments that were made to me (outside this issue) were mostly negative:

i can't understand why we would confuse, obfuscate, intermingle, (some other adjective i can't think of) Bisq with betting. Bisq is a trading platform. Whyy are we talking about gambling?

I'm on the side that adding betting isn't a good idea. It wouldn't be a true betting thing anyway where you could bet on many events, sports etc., but only one pretty obscure thing, so wouldn't bring much to the table, however it could be detrimental, betting isn't seen in a positive way by many after all.

[sqrrm]

I think it's an interesting idea but I don't really feel it aligns with where bisq is right now. At some point it might be more reasonable to look at these kinds of contracts.

There is value in being able to hedge hash rate, and many other things, so I don't consider it to be gambling. This proposal is particularly nice in that the resolution is on chain so it's an atomic operation with no need for arbitration. I would let users handle the broadcast themselves, either through bisq or through some other means.

It's tricky to limit the handling of BTC by bisq since an offer needs to be available to be taken and automatically fund the 2of2 tx. If both sides have to take a manual funding step during the offer take process it's much less likely to succeed.

[huey735]

@sqrrm I don't fully understand what you mean by:

It's tricky to limit the handling of BTC by bisq since an offer needs to be available to be taken and automatically fund the 2of2 tx. If both sides have to take a manual funding step during the offer take process it's much less likely to succeed.

So pardon if the following is misguided. At an ideal case I'm imagining something like JoinMarket's maker-taker model. The makers wallet remains online and will sign transactions if they fit a set of rules. As maker you don't have to pay fees to make your funds available. The taker comes and proposes a transaction and the makers sign it automatically as long as it fits the rules.

[sqrrm]

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.

So pardon if the following is misguided. At an ideal case I'm imagining something like JoinMarket's maker-taker model. The makers wallet remains online and will sign transactions if they fit a set of rules. As maker you don't have to pay fees to make your funds available. The taker comes and proposes a transaction and the makers sign it automatically as long as it fits the rules.

I was commenting on allowing funding of these transactions from an external wallet. It's not obvious to me how that could be done on the maker side avoiding having it handled by a hot wallet, in this case the bisq client. On the taker side it might be doable but even there the signing on the cold wallet side would have to follow the bisq protocol to setup the 2of2 tx, that is also tricky.

[nyxnor]

There is value in being able to hedge hash rate, and many other things, so I don't consider it to be gambling. This proposal is particularly nice in that the resolution is on chain so it's an atomic operation with no need for arbitration. I would let users handle the broadcast themselves, either through bisq or through some other means.

I was commenting on allowing funding of these transactions from an external wallet. It's not obvious to me how that could be done on the maker side avoiding having it handled by a hot wallet, in this case the bisq client. On the taker side it might be doable but even there the signing on the cold wallet side would have to follow the bisq protocol to setup the 2of2 tx, that is also tricky.

I´m not very familiarized with this topic, so this is gonna be a brief commentary.
I think sqmrr better described here (quoted above), not different from the author's first post.
Based on bisq telegram, they arent commenting here, but they think its not very detailed the benefits or it is just gambling.
But back to the referenced above, the contracts can be done by who wants, I one doesnt want, there is no need to discorauge.
Yes, the risks of assembling the contract by both parties following the protocol to the transaction be signed.

[Conza88]

Great work on the ideas. However, a "no" for me, for now.

Reason: other priorities should take precedence = Bisq focusing on improving general trading/exchanges.

What's involved in that?

• Communication i.e. better at extending offers to others (Proposal to increase liquidity on Bisq by allowing each offer to have multiple payment methods and currencies associated with it. #288) [Proposal to increase liquidity on Bisq by allowing each offer to have multiple payment methods and currencies associated with it]
• Improve communication between traders once taken (#5074) [Improve "Portfolio" icon to aid communication between traders]
• Improve communication between arbitrators/mediators if any escalations by (#5044) [Add ability for mediator's & arbitrator's to see "Trader Chat" (upon escalation)]

[huey735]

@MwithM I'm closing this issue given that lack of interest.

Summary

Overall negative sentiment

• Bisq is not for gambling
• There are more urgent proposals