Matches for from:punkman hash, 33 total results Sorted by newest | relevance
Fri Sep 08 09:36:17 UTC 2017 <punkman> "While current EDA works as intended, fine-tuning is required to address hash power oscillation and other issues. Jihan is confident that updates to EDA will solve the oscillation problem "perfectly" such distribution will stabilize."
Mon Apr 24 11:06:27 UTC 2017 <punkman> from the lolwut dept. - "The FDA's recall notice says that McCain Foods USA, Inc. has voluntarily recalled frozen hash browns sold under the Harris Teeter and Roundy's brands because they may be "contaminated with extraneous golf ball materials, that despite our stringent supply standards may have been inadvertently harvested with potatoes."
Tue Nov 08 09:19:38 UTC 2016 <punkman> "Old implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation. "
Thu Aug 18 17:36:31 UTC 2016 <punkman> "What happens if a signature in input in1 has the SIGHASH_SINGLE flag and there is no corresponding output? It would be reasonable to assume that such a signature is invalid. And indeed Bitcoin’s SignatureHash function returns error code 1 in such a case. However, 1 is never interpreted as an error code but rather as the actual result of the hash function. What a classic bug!"
Tue Aug 09 07:18:39 UTC 2016 <punkman> unavoidable, and if "that's not how you'd run a corp" you're either an ashole or an idiot. but in any case if oyu don't like it you can get stuffed. bitbet pays for miner cartelisation detection and minigame pays for hash research and so on and so forth."
Fri Jun 17 12:02:07 UTC 2016 <punkman> "The development community is proposing a soft fork, (with NO ROLLBACK; no transactions or blocks will be “reversed”) which will make any transactions that make any calls/callcodes/delegatecalls that reduce the balance of an account with code hash 0x7278d050619a624f84f51987149ddb439cdaadfba5966f7cfaea7ad44340a4ba (ie. the DAO and children) lead to the transaction (not just the call, the
Mon Feb 01 15:35:32 UTC 2016 <punkman> mircea_popescu: re:sha3-digest, here's one idea, asic miners can get around recalculating the digest on every hash by changing the merkle-root/timestamp instead of the nonce
Mon Oct 26 08:11:51 UTC 2015 <punkman> hash of original 0.5.3 source perhaps
Sun Oct 04 17:53:53 UTC 2015 <punkman> https://blockchain.info/tx/fca843c0b40a1755eee073a719c856baa7fbf5ac28db84804a44a91f52638632 161 conf on the original hash?
Tue Aug 25 20:18:53 UTC 2015 <punkman> mircea_popescu: how's the hash pow related to ec?
Mon Aug 24 08:42:38 UTC 2015 <punkman> jurov: I didn't put a hash in my detached sig filename though
Sat Aug 22 00:10:55 UTC 2015 <punkman> "The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is hashed. The resulting hash value is what is signed. The left 16 bits of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures."
Tue Jul 07 19:06:27 UTC 2015 <punkman> mircea_popescu: this dies, because you will find a random block which is 00000000000000000000000000000f and game over. << this is incorrect. you don't infer the target from the hash. 256bit target is included in all block headers.
Mon Dec 08 23:33:56 UTC 2014 <punkman> so if you hash tx+something, that's not gonna happen
Mon Dec 08 23:30:20 UTC 2014 <punkman> the R value thing, instead of using RNG, you can just hash tx+key or something like that.
Mon Dec 01 15:06:56 UTC 2014 <punkman> the service would notarize the fact that on X date, the contents were something that hashes to Y hash
Mon Dec 01 14:59:23 UTC 2014 <punkman> also, do you see any benefit in including previous metablock hash in next metablock?
Tue Nov 04 02:09:57 UTC 2014 <punkman> deed/9ULZPc7yeZ9fQEA1aZ73H6mcv1s2C4gYFAbNTb5urovj << urovj , that deed hash