Andrew Poelstra
Andrew Poelstra
Thanks for your comment. IEEE754 can't represent any decimal digits because it is a binary-point format (eg famously 0.1 cannot be represented precisely). In particular I was seeing wrong values...
Manually constructed a `.ots` with txid `ff1dca15029d1df57a601f180308bcb6b91f2e8e129668452eaf066cd0668fa6` and verified that it parsed correctly, but since it is still unconfirmed I can't chase it all the way down to a Merkle...
Here is a .ots that uses this going to block 466872 https://download.wpsoftware.net/bitcoin/wizardry/andytoshi.s2c.ots Sadly I can't get a file for which this will verify as the original data was the text...
Actually how about just `Secp256k1Commitment`? This doesn't necessarily have to appear in a signature.
Update with renames, also changed the copyright year from 2016 to 2017
Oh! It was actually vim silently adding a `0x0a` to my file even though I made sure there were no newlines. I removed it with a hex editor and everything...
Ok, added
Yes, sorry, I generated very many keys a very long time ago and have not gotten through them all.. hence the uncompressed keys. This is totally separate from sign-to-contract.
Sign-to-contract does not introduce a discrete log assumption. It depends only on the security of the underlying hash (in this case, SHA256).
@LeoComandini in Bitcoin we always serialize points as 33 bytes rather than using DER. Everything is much nicer with fixed-length objects. @petertodd Sure, there is a (almost) bijection between 32-byte...