Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2020-08-16 š Original message:On Sun, Aug 16, 2020 at ...
š
Original date posted:2020-08-16
š Original message:On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
Any kind of opcode is a binary option. Either the output can be spent or
it can't.
You could get a pseudo-continuous future by having lots of outputs with
different thresholds.
Alice and Bob create a transaction with 100 outputs and each having 1% of
the future's value.
Output 0: Pay Alice if diff < 1.00 trillion else Bob
Output 1: Pay Alice if diff < 1.01 trillion else Bob
....
Output 98: Pay Alice if diff < 1.98 trillion else Bob
Output 99: Pay Alice if diff < 1.99 trillion else Bob
If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob
gets outputs 25-99. The future has a tick size of 1%. It isn't very
efficient though
It would be good to have the option to specify a block height for the
future too. If it triggered on block time, then miners have an incentive
to give false block times.
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 agree you would need covenants or something similar.
There needs to be a way to check the outputs (value and script) of the
spending transaction. You also need a way for Alice and Bob to create
their spending transaction in sequence.
Output 0: Pay Alice if [output value 0] <= Diff / 1 trillion AND [output
value 1] >= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
To spend her output, Alice has to create a transaction which pays Bob and
assigns the coins in the right ratio. [output value x] means the output
value of the spending transaction for output x.
To get it to work Alice creates a transaction with these restrictions
Output 0:
Script: Anything (Alice gets it to pay herself)
Value: <= Diff / 1 trillion
Output 1:
Script: Must pay to Bob
Value: >= (2 trillion - Diff) / 1 trillion
You also need to handle overflows with the calculations.
Bob can then spend output 1 and get his money.
There is a hold-up risk if Alice doesn't spend her money. You can make the
output script so either of them can spend their coins to avoid that.
Output 0:
Pay Alice if [output value 0] <= Diff / 1 trillion AND [output value 1]
>= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
OR
Pay Bob if [output value 0] <= (2 trillion - Diff) / 1 trillion AND
[output value 1] >= Diff / (1 trillion) AND [output 1 pays to Alice]
You would need a covenant-like instruction to check the output values and
scripts and the diff opcode to get the difficulty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200816/63df27eb/attachment.html>;
š Original message:On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
Any kind of opcode is a binary option. Either the output can be spent or
it can't.
You could get a pseudo-continuous future by having lots of outputs with
different thresholds.
Alice and Bob create a transaction with 100 outputs and each having 1% of
the future's value.
Output 0: Pay Alice if diff < 1.00 trillion else Bob
Output 1: Pay Alice if diff < 1.01 trillion else Bob
....
Output 98: Pay Alice if diff < 1.98 trillion else Bob
Output 99: Pay Alice if diff < 1.99 trillion else Bob
If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob
gets outputs 25-99. The future has a tick size of 1%. It isn't very
efficient though
It would be good to have the option to specify a block height for the
future too. If it triggered on block time, then miners have an incentive
to give false block times.
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 agree you would need covenants or something similar.
There needs to be a way to check the outputs (value and script) of the
spending transaction. You also need a way for Alice and Bob to create
their spending transaction in sequence.
Output 0: Pay Alice if [output value 0] <= Diff / 1 trillion AND [output
value 1] >= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
To spend her output, Alice has to create a transaction which pays Bob and
assigns the coins in the right ratio. [output value x] means the output
value of the spending transaction for output x.
To get it to work Alice creates a transaction with these restrictions
Output 0:
Script: Anything (Alice gets it to pay herself)
Value: <= Diff / 1 trillion
Output 1:
Script: Must pay to Bob
Value: >= (2 trillion - Diff) / 1 trillion
You also need to handle overflows with the calculations.
Bob can then spend output 1 and get his money.
There is a hold-up risk if Alice doesn't spend her money. You can make the
output script so either of them can spend their coins to avoid that.
Output 0:
Pay Alice if [output value 0] <= Diff / 1 trillion AND [output value 1]
>= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
OR
Pay Bob if [output value 0] <= (2 trillion - Diff) / 1 trillion AND
[output value 1] >= Diff / (1 trillion) AND [output 1 pays to Alice]
You would need a covenant-like instruction to check the output values and
scripts and the diff opcode to get the difficulty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200816/63df27eb/attachment.html>;