Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-24 Thread Tamas Blummer via bitcoin-dev 
yes, log2work is already computed and would be a strictly increasing value, 
like time. Thank you for this suggestion. I think attempting an implementation 
will give further clues it this more suitable to express the same.

Tamas Blummer

> On May 24, 2019, at 10:36, Natanael  wrote:
> 
> On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev 
>  > wrote:
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
> 
> To deal with potentially wildly varying difficulty, could the value exposed 
> be the sum of accumulated PoW, or in other words the sum of each block's 
> difficulty value in the entire chain? This should be a value that will only 
> rise unless a reorg happens after a difficulty drop happens (only likely to 
> be the result of users manually blacklisting an otherwise valid block that is 
> several blocks back in the chain).
> 
> This mimics the effect of the block number which only grows. So if you're 
> starting at time A with difficulty X, then you'd estimate what you think the 
> accumulated PoW ought to be at time B with expected difficulty Y (as compared 
> to the current value at time A), and put that value into the script.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-24 Thread Natanael via bitcoin-dev 
On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.


To deal with potentially wildly varying difficulty, could the value exposed
be the sum of accumulated PoW, or in other words the sum of each block's
difficulty value in the entire chain? This should be a value that will only
rise unless a reorg happens after a difficulty drop happens (only likely to
be the result of users manually blacklisting an otherwise valid block that
is several blocks back in the chain).

This mimics the effect of the block number which only grows. So if you're
starting at time A with difficulty X, then you'd estimate what you think
the accumulated PoW ought to be at time B with expected difficulty Y (as
compared to the current value at time A), and put that value into the
script.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-24 Thread Johnson Lau via bitcoin-dev 
A gamble like this, decentralised or not, is easy to manipulate since 
difficulty is determined entirely by the last block in a cycle

> On 24 May 2019, at 1:42 AM, Tamas Blummer via bitcoin-dev 
>  wrote:
> 
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
> 
> I think we could do much better than them natively within Bitcoin.
> 
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into. 
> The output script may then decide comparing that value with a strike which 
> key can spend it. 
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet. 
> The winner would broadcast. 
> 
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
> 
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
> 
> Do you see a fault in this proposal or want to contribute?
> 
> Tamas Blummer 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Tamas Blummer via bitcoin-dev 

> On May 23, 2019, at 21:45, Pieter Wuille  wrote:
> 
> On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
>  wrote:
>> 
>> Difficulty change has profound impact on miner’s production thereby 
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional 
>> trading venues. Some might soon list difficulty futures.
>> 
>> I think we could do much better than them natively within Bitcoin.
>> 
>> A better solution could be a transaction that uses nLocktime denominated in 
>> block height, such that it is valid after the difficulty adjusted block in 
>> the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>> the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which 
>> key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who 
>> entered the bet.
>> The winner would broadcast.
> 
> If the difficulty can be directly observed by the script language, you
> would need to re-evaluate all scripts in unconfirmed transactions
> whenever the difficulty changes. This complicates implementation of
> mempools, but it also makes reasoning about validity of (chains of)
> unconfirmed transactions harder, as an unconfirmed predecessor may
> have conditions that change over time.
> 
> For things like block time/height, this is solved by not having the
> script itself observe the context state directly, but instead having
> an assertion on the state outside of script (nLockTime for absolute
> time/height and nSequence for relative), and then having opcodes
> inside script that observe the assertion (OP_CLTV and OP_CSV). By
> doing so, script validity is a single context-free yes or not that can
> be evaluated once, and the variable part is just transaction-level
> reasoning that doesn't involve a full script interpreter.
> Additionally, the supported assertions are restricted in such a way
> that if they are true within a particular block, they're also true in
> any descendant, removing the complexity of reasoning about validity
> (apart from the inevitable reasoning about possible double-spend
> before confirmation).
> 
> I feel a similar construction is needed for observing block
> difficulty. This can be done by either having an opcode that as a side
> effect of execution "posts" an assertion (e.g. "difficulty at block
> height X is at least Y"), instead of putting the difficulty on the
> stack. An alternative is having the assertion be part of the
> transaction structure (for example in the annex we propose in
> bip-taproot), and having an opcode that observes the difficulty
> assertion inside script.

Thanks for these suggestions I will follow up while preparing the BIP.

> 
> I don't have a strong opinion either way on the usefulness of having
> difficulty-dependent transaction/scripts.
> 

This is the best reception I could have hoped for :)

> Cheers,
> 
> --
> Pieter



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Nathan Cook via bitcoin-dev 
You're right, I didn't remember the whole procedure. You provide the
80-byte header in the spend script, duplicate it on the stack, hash it, and
compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on
the header with OP_AND to extract the difficulty. You can compare two
compressed difficulties directly by using more bit masking to separate the
exponent and mantissa.

On Thu, 23 May 2019 at 22:54, Tamas Blummer  wrote:

> Block hash can suggest much higher difficulty than what is in effect, so
> OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the
> level of the bet.
>
> > On May 23, 2019, at 21:45, Tamas Blummer 
> wrote:
> >
> > I see. The uncompressing needs to be done either to compare. How are
> chances for that BIP?
> >
> > This BIP would be explicitly offering risk managment of miners biggest
> risk.
> > Doing so without relying on external markets or oracle, self cointained
> would be an impressive and adequate feature.
> >
> > Tamas Blummer
> >
> >> On May 23, 2019, at 21:21, Nathan Cook  wrote:
> >>
> >> It's true that it fetches the block hash; the idea is to compare the
> block hash's numeric value to the desired (uncompressed) difficulty
> directly, using a 256-bit version of OP_LESSTHAN.
> >>
> >> Nathan Cook
> >>
> >>
> >> On Thu, 23 May 2019 at 22:18, Tamas Blummer 
> wrote:
> >> That opcode would not help as it fetches block hash and not the content
> of the header.
> >>
> >>> On May 23, 2019, at 21:05, Nathan Cook  wrote:
> >>>
> >>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by
> Luke Dashjr (
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you
> also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
> and the ensuing thread.
> >>>
> >>> Nathan Cook
> >>>
> >>>
> >>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> Difficulty change has profound impact on miner’s production thereby
> introduce the biggest risk while considering an investment.
> >>> Commodity markets offer futures and options to hedge risks on
> traditional trading venues. Some might soon list difficulty futures.
> >>>
> >>> I think we could do much better than them natively within Bitcoin.
> >>>
> >>> A better solution could be a transaction that uses nLocktime
> denominated in block height, such that it is valid after the difficulty
> adjusted block in the future.
> >>> A new OP_DIFFICULTY opcode would put onto stack the value of
> difficulty for the block the transaction is included into.
> >>> The output script may then decide comparing that value with a strike
> which key can spend it.
> >>> The input of the transaction would be a multi-sig escrow of those who
> entered the bet.
> >>> The winner would broadcast.
> >>>
> >>> Once signed by both the transaction would not carry any counterparty
> risk and would not need an oracle to settle according to the bet.
> >>>
> >>> I plan to draft a BIP for this as I think this opcode would serve
> significant economic interest of Bitcoin economy, and is compatible with
> Bitcoin’s aim not to introduce 3rd party to do so.
> >>>
> >>> Do you see a fault in this proposal or want to contribute?
> >>>
> >>> Tamas Blummer
> >>>
> >>> ___
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Tamas Blummer via bitcoin-dev 
Block hash can suggest much higher difficulty than what is in effect, so 
OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the level 
of the bet.

> On May 23, 2019, at 21:45, Tamas Blummer  wrote:
> 
> I see. The uncompressing needs to be done either to compare. How are chances 
> for that BIP?
> 
> This BIP would be explicitly offering risk managment of miners biggest risk.
> Doing so without relying on external markets or oracle, self cointained would 
> be an impressive and adequate feature.
> 
> Tamas Blummer
> 
>> On May 23, 2019, at 21:21, Nathan Cook  wrote:
>> 
>> It's true that it fetches the block hash; the idea is to compare the block 
>> hash's numeric value to the desired (uncompressed) difficulty directly, 
>> using a 256-bit version of OP_LESSTHAN.
>> 
>> Nathan Cook
>> 
>> 
>> On Thu, 23 May 2019 at 22:18, Tamas Blummer  wrote:
>> That opcode would not help as it fetches block hash and not the content of 
>> the header.
>> 
>>> On May 23, 2019, at 21:05, Nathan Cook  wrote:
>>> 
>>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke 
>>> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) 
>>> if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. 
>>> See 
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>>>  and the ensuing thread.
>>> 
>>> Nathan Cook
>>> 
>>> 
>>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev 
>>>  wrote:
>>> Difficulty change has profound impact on miner’s production thereby 
>>> introduce the biggest risk while considering an investment.
>>> Commodity markets offer futures and options to hedge risks on traditional 
>>> trading venues. Some might soon list difficulty futures.
>>> 
>>> I think we could do much better than them natively within Bitcoin.
>>> 
>>> A better solution could be a transaction that uses nLocktime denominated in 
>>> block height, such that it is valid after the difficulty adjusted block in 
>>> the future.
>>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>>> the block the transaction is included into.
>>> The output script may then decide comparing that value with a strike which 
>>> key can spend it.
>>> The input of the transaction would be a multi-sig escrow of those who 
>>> entered the bet.
>>> The winner would broadcast.
>>> 
>>> Once signed by both the transaction would not carry any counterparty risk 
>>> and would not need an oracle to settle according to the bet.
>>> 
>>> I plan to draft a BIP for this as I think this opcode would serve 
>>> significant economic interest of Bitcoin economy, and is compatible with 
>>> Bitcoin’s aim not to introduce 3rd party to do so.
>>> 
>>> Do you see a fault in this proposal or want to contribute?
>>> 
>>> Tamas Blummer
>>> 
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Tamas Blummer via bitcoin-dev 
I see. The uncompressing needs to be done either to compare. How are chances 
for that BIP?

This BIP would be explicitly offering risk managment of miners biggest risk.
Doing so without relying on external markets or oracle, self cointained would 
be an impressive and adequate feature.

Tamas Blummer

> On May 23, 2019, at 21:21, Nathan Cook  wrote:
> 
> It's true that it fetches the block hash; the idea is to compare the block 
> hash's numeric value to the desired (uncompressed) difficulty directly, using 
> a 256-bit version of OP_LESSTHAN.
> 
> Nathan Cook
> 
> 
> On Thu, 23 May 2019 at 22:18, Tamas Blummer  wrote:
> That opcode would not help as it fetches block hash and not the content of 
> the header.
> 
>> On May 23, 2019, at 21:05, Nathan Cook  wrote:
>> 
>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke 
>> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if 
>> you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>>  and the ensuing thread.
>> 
>> Nathan Cook
>> 
>> 
>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev 
>>  wrote:
>> Difficulty change has profound impact on miner’s production thereby 
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional 
>> trading venues. Some might soon list difficulty futures.
>> 
>> I think we could do much better than them natively within Bitcoin.
>> 
>> A better solution could be a transaction that uses nLocktime denominated in 
>> block height, such that it is valid after the difficulty adjusted block in 
>> the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>> the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which 
>> key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who 
>> entered the bet.
>> The winner would broadcast.
>> 
>> Once signed by both the transaction would not carry any counterparty risk 
>> and would not need an oracle to settle according to the bet.
>> 
>> I plan to draft a BIP for this as I think this opcode would serve 
>> significant economic interest of Bitcoin economy, and is compatible with 
>> Bitcoin’s aim not to introduce 3rd party to do so.
>> 
>> Do you see a fault in this proposal or want to contribute?
>> 
>> Tamas Blummer
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Pieter Wuille via bitcoin-dev 
On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
 wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into.
> The output script may then decide comparing that value with a strike which 
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet.
> The winner would broadcast.

If the difficulty can be directly observed by the script language, you
would need to re-evaluate all scripts in unconfirmed transactions
whenever the difficulty changes. This complicates implementation of
mempools, but it also makes reasoning about validity of (chains of)
unconfirmed transactions harder, as an unconfirmed predecessor may
have conditions that change over time.

For things like block time/height, this is solved by not having the
script itself observe the context state directly, but instead having
an assertion on the state outside of script (nLockTime for absolute
time/height and nSequence for relative), and then having opcodes
inside script that observe the assertion (OP_CLTV and OP_CSV). By
doing so, script validity is a single context-free yes or not that can
be evaluated once, and the variable part is just transaction-level
reasoning that doesn't involve a full script interpreter.
Additionally, the supported assertions are restricted in such a way
that if they are true within a particular block, they're also true in
any descendant, removing the complexity of reasoning about validity
(apart from the inevitable reasoning about possible double-spend
before confirmation).

I feel a similar construction is needed for observing block
difficulty. This can be done by either having an opcode that as a side
effect of execution "posts" an assertion (e.g. "difficulty at block
height X is at least Y"), instead of putting the difficulty on the
stack. An alternative is having the assertion be part of the
transaction structure (for example in the annex we propose in
bip-taproot), and having an opcode that observes the difficulty
assertion inside script.

I don't have a strong opinion either way on the usefulness of having
difficulty-dependent transaction/scripts.

Cheers,

-- 
Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Nathan Cook via bitcoin-dev 
It's true that it fetches the block hash; the idea is to compare the block
hash's numeric value to the desired (uncompressed) difficulty directly,
using a 256-bit version of OP_LESSTHAN.

Nathan Cook


On Thu, 23 May 2019 at 22:18, Tamas Blummer  wrote:

> That opcode would not help as it fetches block hash and not the content of
> the header.
>
> On May 23, 2019, at 21:05, Nathan Cook  wrote:
>
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
> if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
> See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>  and
> the ensuing thread.
>
> Nathan Cook
>
>
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Difficulty change has profound impact on miner’s production thereby
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional
>> trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated
>> in block height, such that it is valid after the difficulty adjusted block
>> in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty
>> for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike
>> which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who
>> entered the bet.
>> The winner would broadcast.
>>
>> Once signed by both the transaction would not carry any counterparty risk
>> and would not need an oracle to settle according to the bet.
>>
>> I plan to draft a BIP for this as I think this opcode would serve
>> significant economic interest of Bitcoin economy, and is compatible with
>> Bitcoin’s aim not to introduce 3rd party to do so.
>>
>> Do you see a fault in this proposal or want to contribute?
>>
>> Tamas Blummer
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Tamas Blummer via bitcoin-dev 
That opcode would not help as it fetches block hash and not the content of the 
header.

> On May 23, 2019, at 21:05, Nathan Cook  wrote:
> 
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke 
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki 
> ) if you 
> also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
>  
> 
>  and the ensuing thread.
> 
> Nathan Cook
> 
> 
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev 
>  > wrote:
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
> 
> I think we could do much better than them natively within Bitcoin.
> 
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into.
> The output script may then decide comparing that value with a strike which 
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet.
> The winner would broadcast.
> 
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
> 
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
> 
> Do you see a fault in this proposal or want to contribute?
> 
> Tamas Blummer
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org 
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Tamas Blummer via bitcoin-dev 
The parameter used is property of the block just like the block height is a 
property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.

The transaction itself was not invalid in a re-org but evtl. others spending it 
if the difficulty on that fork is different,
this is however intended as then on that fork the other was the winner.

Tamas Blummer

> On May 23, 2019, at 21:03, Jorge Timón  wrote:
> 
> The complains I could imagine about this, (apart from being a very
> specific use case) are the same complains I heard about op_expiry.
> Namely, that in a reorg, the same tx, having been valid in a given
> block could potentially become invalid in some other block mining it.
> I guess in this case the situation is less likely in this case than
> with op_expiry, but it is still possible.
> Another complain I could imagine is this kind of forces the
> implementation to break some existing encapsulations, but I guess
> those are just implementation details not that relevant here.
> I personally don't have strong feelings towards this proposal one way
> or the other, I'm just imagining what other people may complain about.
> 
> On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
>  wrote:
>> 
>> Difficulty change has profound impact on miner’s production thereby 
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional 
>> trading venues. Some might soon list difficulty futures.
>> 
>> I think we could do much better than them natively within Bitcoin.
>> 
>> A better solution could be a transaction that uses nLocktime denominated in 
>> block height, such that it is valid after the difficulty adjusted block in 
>> the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
>> the block the transaction is included into.
>> The output script may then decide comparing that value with a strike which 
>> key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who 
>> entered the bet.
>> The winner would broadcast.
>> 
>> Once signed by both the transaction would not carry any counterparty risk 
>> and would not need an oracle to settle according to the bet.
>> 
>> I plan to draft a BIP for this as I think this opcode would serve 
>> significant economic interest of Bitcoin economy, and is compatible with 
>> Bitcoin’s aim not to introduce 3rd party to do so.
>> 
>> Do you see a fault in this proposal or want to contribute?
>> 
>> Tamas Blummer
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Nathan Cook via bitcoin-dev 
You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html
and
the ensuing thread.

Nathan Cook


On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Difficulty change has profound impact on miner’s production thereby
> introduce the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional
> trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated
> in block height, such that it is valid after the difficulty adjusted block
> in the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty
> for the block the transaction is included into.
> The output script may then decide comparing that value with a strike which
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who
> entered the bet.
> The winner would broadcast.
>
> Once signed by both the transaction would not carry any counterparty risk
> and would not need an oracle to settle according to the bet.
>
> I plan to draft a BIP for this as I think this opcode would serve
> significant economic interest of Bitcoin economy, and is compatible with
> Bitcoin’s aim not to introduce 3rd party to do so.
>
> Do you see a fault in this proposal or want to contribute?
>
> Tamas Blummer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Jorge Timón via bitcoin-dev 
The complains I could imagine about this, (apart from being a very
specific use case) are the same complains I heard about op_expiry.
Namely, that in a reorg, the same tx, having been valid in a given
block could potentially become invalid in some other block mining it.
I guess in this case the situation is less likely in this case than
with op_expiry, but it is still possible.
Another complain I could imagine is this kind of forces the
implementation to break some existing encapsulations, but I guess
those are just implementation details not that relevant here.
I personally don't have strong feelings towards this proposal one way
or the other, I'm just imagining what other people may complain about.

On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
 wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into.
> The output script may then decide comparing that value with a strike which 
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet.
> The winner would broadcast.
>
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
>
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
>
> Do you see a fault in this proposal or want to contribute?
>
> Tamas Blummer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Tamas Blummer via bitcoin-dev 
Difficulty change has profound impact on miner’s production thereby introduce 
the biggest risk while considering an investment.
Commodity markets offer futures and options to hedge risks on traditional 
trading venues. Some might soon list difficulty futures.

I think we could do much better than them natively within Bitcoin.

A better solution could be a transaction that uses nLocktime denominated in 
block height, such that it is valid after the difficulty adjusted block in the 
future.
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the 
block the transaction is included into. 
The output script may then decide comparing that value with a strike which key 
can spend it. 
The input of the transaction would be a multi-sig escrow of those who entered 
the bet. 
The winner would broadcast. 

Once signed by both the transaction would not carry any counterparty risk and 
would not need an oracle to settle according to the bet.

I plan to draft a BIP for this as I think this opcode would serve significant 
economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim not 
to introduce 3rd party to do so.

Do you see a fault in this proposal or want to contribute?

Tamas Blummer 

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev