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,

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

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

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

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

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

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

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.

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

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 >

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

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

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