Thomas Hartman [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-16 📝 Original message:First, I would like to pay ...
📅 Original date posted:2020-08-16
📝 Original message:First, I would like to pay respects to tamas blummer, RIP.
https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
Tamas proposed an additional opcode for enabling bitcoin difficulty
futures, on this list at
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html
I really like this idea.
1) Trusted third parties are security holes
https://nakamotoinstitute.org/trusted-third-parties/
and oracles (eg discreet log contracts) are really just trusted third
parties in a blockchain's clothing. So truly ttp-free oracle-free on
chain contracts are good.
2) Difficulty is a proxy for energy, which is a proxy for usd, which
is what everyone currently cares about, which is bad. Energy is real.
Bitcoin traders should care about future difficulty, not future usd
price.
So in sum I think this is a very good idea, and I would like to
continue this work. Ideally I would like to see to completion the BIP
that Tamas was unable to produce.
Some initial thoughts on the technical merits.
My understanding is that adding a single op_difficulty operation as
proposed would enable not true difficulty futures but binary options
on difficulty.
https://en.wikipedia.org/wiki/Binary_option
As the wikipedia article notes, "While binary options may be used in
theoretical asset pricing, they are prone to fraud in their
applications and hence banned by regulators in many jurisdictions as a
form of gambling." The trouble is that because of the all or nothing
nature binary options are more of a gamble than a hedge. They are
popular with scammers, and even licensed binary options exchanges such
as nadex are under constant scrutiny by regulators.
Because any form of trusted third party-free / oracle free speculation
would encourage economic use of blockchain space and support the
transaction fee market, perhaps an economic case can be made for naive
op_difficulty as above even it has more of a flavor of gambling than
hedging. I think at a psychological level it would be good for a
ttp-free difficulty speculation tool to capture mindshare.
That being said, true difficulty futures -- real hedging and not just
gambling -- would be far healthier for bitcoin than binary options. I
am trying to wrangle what additional opcodes and protocol changes
would be required beyond just op_difficulty, to get true difficulty
futures on chain.
I envision something like this. To give some context: Current
difficulty is 16.9 Trillion. We're a week in to the current difficulty
regime so there's aboout 1000 blocks to retarget, and predicted next
difficuly is 18.5 Trillion. So let's pretend we sell a difficulty
future that pays out in sats, of the next difficulty divided by a
trillion. A reasonable price for this would be, say, 17.4 sats.
So in our op_difficulty utxo, one address (the futures buyer) would
get current difficulty / trillion, and the other address (the seller)
would get however much value is locked in the utxo, minus that amount
and miner fee. The payout would be limited by however much value is
locked in the utxo. Since difficulty adjusts very slowly I don't think
overflowing the locked up value would be much of a problem in
practice. We also want a mechanism to enable on-chain purchase of such
a contract, say for 17.4 sats.
One additional opcode that apparently would be required is division.
Some version of rshift could also do.
I am not clear if there is a way to solve the accounting for the
payouts, but perhaps there is a way to do this with covenants.
I'm somewhat new to protocol and script. I would appreciate if anyone
has any further advice on this.
Cheers, Thomas.
📝 Original message:First, I would like to pay respects to tamas blummer, RIP.
https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
Tamas proposed an additional opcode for enabling bitcoin difficulty
futures, on this list at
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html
I really like this idea.
1) Trusted third parties are security holes
https://nakamotoinstitute.org/trusted-third-parties/
and oracles (eg discreet log contracts) are really just trusted third
parties in a blockchain's clothing. So truly ttp-free oracle-free on
chain contracts are good.
2) Difficulty is a proxy for energy, which is a proxy for usd, which
is what everyone currently cares about, which is bad. Energy is real.
Bitcoin traders should care about future difficulty, not future usd
price.
So in sum I think this is a very good idea, and I would like to
continue this work. Ideally I would like to see to completion the BIP
that Tamas was unable to produce.
Some initial thoughts on the technical merits.
My understanding is that adding a single op_difficulty operation as
proposed would enable not true difficulty futures but binary options
on difficulty.
https://en.wikipedia.org/wiki/Binary_option
As the wikipedia article notes, "While binary options may be used in
theoretical asset pricing, they are prone to fraud in their
applications and hence banned by regulators in many jurisdictions as a
form of gambling." The trouble is that because of the all or nothing
nature binary options are more of a gamble than a hedge. They are
popular with scammers, and even licensed binary options exchanges such
as nadex are under constant scrutiny by regulators.
Because any form of trusted third party-free / oracle free speculation
would encourage economic use of blockchain space and support the
transaction fee market, perhaps an economic case can be made for naive
op_difficulty as above even it has more of a flavor of gambling than
hedging. I think at a psychological level it would be good for a
ttp-free difficulty speculation tool to capture mindshare.
That being said, true difficulty futures -- real hedging and not just
gambling -- would be far healthier for bitcoin than binary options. I
am trying to wrangle what additional opcodes and protocol changes
would be required beyond just op_difficulty, to get true difficulty
futures on chain.
I envision something like this. To give some context: Current
difficulty is 16.9 Trillion. We're a week in to the current difficulty
regime so there's aboout 1000 blocks to retarget, and predicted next
difficuly is 18.5 Trillion. So let's pretend we sell a difficulty
future that pays out in sats, of the next difficulty divided by a
trillion. A reasonable price for this would be, say, 17.4 sats.
So in our op_difficulty utxo, one address (the futures buyer) would
get current difficulty / trillion, and the other address (the seller)
would get however much value is locked in the utxo, minus that amount
and miner fee. The payout would be limited by however much value is
locked in the utxo. Since difficulty adjusts very slowly I don't think
overflowing the locked up value would be much of a problem in
practice. We also want a mechanism to enable on-chain purchase of such
a contract, say for 17.4 sats.
One additional opcode that apparently would be required is division.
Some version of rshift could also do.
I am not clear if there is a way to solve the accounting for the
payouts, but perhaps there is a way to do this with covenants.
I'm somewhat new to protocol and script. I would appreciate if anyone
has any further advice on this.
Cheers, Thomas.