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
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
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 problem with >100kb transactions isn't that there are a lot of already-signed transactions out there, or even that there are good use cases for them, but that such transactions and use cases could exist, and there is no way of disallowing them without possibly costing someone a lot of money.
Further to recent posts to this list concerning mining with more than one hash function, Adam Perlow and me have a (longish) proposal/analysis on combining multi-hash with bitcoin stake voting on what the mix of hashes should be. Two novelties are: * Targeting a ratio of blocks mined under each
On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev < firstname.lastname@example.org> wrote: > On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote: > > > - Otherwise of hash is compared to lower of blockhash. > > Lower in what endian? Why only that endian? Why only lower? I