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
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
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
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. Sl
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 ha
On 1 October 2016 at 08:02, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.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 c
