28 entries in 0.292s
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
punkman: https://blockchain.info/en/charts/hash-rate?timespan=all&showDataPoints=true&daysAverageString=1&show_header=true&scale=0&address=
punkman: and if "prevout" is e6b8aa9ded why the hell does "if (!mapTransactions.count(prevout.hash))" fail??? you just received the thing
punkman: hash of original 0.5.3 source perhaps
punkman: https://blockchain.info/tx/fca843c0b40a1755eee073a719c856baa7fbf5ac28db84804a44a91f52638632 161 conf on the original hash?
punkman: mircea_popescu: how's the hash pow related to ec?
punkman: jurov: I didn't put a hash in my detached sig filename though
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."
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.
punkman: so if you hash tx+something, that's not gonna happen
punkman: the R value thing, instead of using RNG, you can just hash tx+key or something like that.
punkman: the service would notarize the fact that on X date, the contents were something that hashes to Y hash
punkman: also, do you see any benefit in including previous metablock hash in next metablock?
punkman: deed/9ULZPc7yeZ9fQEA1aZ73H6mcv1s2C4gYFAbNTb5urovj << urovj , that deed hash
punkman: re: merkle tree - maybe in the future where we have 100 deeds per bundle, but it's already a hash tree so...
punkman: if you base58decode the deed hash, you get a sha256 hash of raw deed
punkman: that is a deed hash, the "lite" bundle is all the deed hashes
punkman: what hash attack
punkman: it's not a problem, just wait for next deed, hash changes
punkman: hash must be smaller than 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
punkman: deeds are sha256 hashed, hash is b58encoded, b58encoded hashes of all deeds are joined with ",", that string is sha256'd again and that's the private key ☟︎
punkman: so if someone wants to do some independent verification, hash "BXZKQx2iLYyRpUCmdWCqJBvgUdvqWH4EE8TV1ns3pxLZ" with sha256, convert to big int, make Bitcoin private key with big int, verify the key's address is 149LB8VYaT1BdMLyQUL92Kj6KrJfNwcp64.
punkman: I take the hash of each deed, concatenate those to create the "bundle", then hash the bundle and make a private key out of that
punkman: for existing deedbot, the whole bundle goes through sha256, then that hash is manipulated to create a public address
punkman: (by random I mean based on the bundle hash)
punkman: mircea_popescu: because it goes from file hash to pub address
punkman: yo dawg I heard u like difficulty: "The header is signed with the coinbase transaction's private key, and the hash (SHA256(SIG(header, privkey))) of that signature is smaller than a second difficulty parameter Y. "
punkman: and in the interest of not writing things twice, assbot could send each bundle hash here http://www.proofofexistence.com/developers