Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2016-10-01 📝 Original message:On Saturday, October 01, ...
📅 Original date posted:2016-10-01
📝 Original message:On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote:
> Prefer a three-arg version (gbits-to-compare, blocknum, hash):
> - If <bits> is 0 or > 256, invalid.
> - If the hash length is not (<bits> + 7) / 8, invalid.
This means zero padding on-chain, which would be undesirable.
Rather "at most" and have the consensus implementation do the padding.
> - If the hash unused bits are not 0, invalid.
Why?
> - Otherwise <bits> of hash is compared to lower <bits> of blockhash.
Lower in what endian? Why only that endian? Why only lower? I can see a
possible use case where one wants to look at only the high bits to ensure
their transaction is only valid in a block with at least a certain
difficulty...
> This version also lets you play gambling games on-chain!
>
> Or maybe I've just put another nail in CBAH's coffin?
Or maybe resurrected it...
Luke
📝 Original message:On Saturday, October 01, 2016 4:01:04 AM Rusty Russell wrote:
> Prefer a three-arg version (gbits-to-compare, blocknum, hash):
> - If <bits> is 0 or > 256, invalid.
> - If the hash length is not (<bits> + 7) / 8, invalid.
This means zero padding on-chain, which would be undesirable.
Rather "at most" and have the consensus implementation do the padding.
> - If the hash unused bits are not 0, invalid.
Why?
> - Otherwise <bits> of hash is compared to lower <bits> of blockhash.
Lower in what endian? Why only that endian? Why only lower? I can see a
possible use case where one wants to look at only the high bits to ensure
their transaction is only valid in a block with at least a certain
difficulty...
> This version also lets you play gambling games on-chain!
>
> Or maybe I've just put another nail in CBAH's coffin?
Or maybe resurrected it...
Luke