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

> 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 future

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

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 compress

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

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 chance

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

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 Blum

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

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. S

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

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 b

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

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.

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 differe

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

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/0

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

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 sit

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

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

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

Hi Russell, This is probably a dumb question, but I'd like to get some clarity on your proposal. OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey. Presumably, the message would then have to get constructed as part of the Script execution. What would such a message look lik

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

Good morning Russell, While I am sympathetic to this argument from first principles, as I understand it, it requires that provided witness inputs will become larger, compared to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`. For instance, to simulate `SIGHASH_ANYPREVOUT`

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

Good morning Jeremy, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, May 22, 2019 4:10 PM, Jeremy wrote: > > * I do not think CoinJoin is much improved by this opcode. > >   Typically, you would sign off only if one of the outputs of the CoinJoin > > transact

Re: [bitcoin-dev] Taproot proposal

On Wed, May 22, 2019 at 10:06 PM Pieter Wuille wrote: > On Tue, 21 May 2019 at 10:20, Russell O'Connor > wrote: > > > > Regarding Tapscript, the specification calls for the final value of the > stack being a single non-false value: > > > >> The tapscript is executed according to the rules in the

Re: [bitcoin-dev] Taproot proposal

On Tue, 21 May 2019 at 10:20, Russell O'Connor wrote: > > Regarding Tapscript, the specification calls for the final value of the stack > being a single non-false value: > >> The tapscript is executed according to the rules in the following section, >> with the initial stack as input >> II.

[bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for Bitcoin via new Script operations. However, I think that these proposals miss the mark when it comes to how they approach Bitcoin Script and language f

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

On Wed, May 22, 2019 at 06:04:27AM +, ZmnSCPxj via bitcoin-dev wrote: > * I do not think CoinJoin is much improved by this opcode. I think (especially with cross-input sig aggregation) it makes it easier to do a coinjoin during a high fee period -- if you're willing to wait 'til fees are lower

Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal

On Wed, May 22, 2019 at 12:17:31PM +0930, Rusty Russell wrote: >I prefer to >change the bip introduction to expliclty shout "THESE SIGNATURE >HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it >SIGHASH_UNSAFE_ANYPREVOUT. > 4. "Rebinding is a new power in bitcoin, and