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,
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
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
> 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
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
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
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
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.
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
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
>
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
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
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
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
14 matches
Mail list logo
