How to find the attestation transaction id from an ots info file?

[dhimmel]

I get the following output from running ots info on one of my .ots files:

File sha256 hash: 3e8931c7a0ff54b4c77ec845dd17a385d8705c285c88521d1428b39ab06421e7
Timestamp:
append b1cbf92d328dee6f4c7ecd19ab94969e
sha256
prepend ed788ebf68555688fd41e529d1eae955fbb0b7e8e3d63ed59c9f3eed29b309e1
sha256
 -> append 8be1d43da44c76954746861b77a63ff4
    sha256
    prepend 58b9e977
    append 8bda26c3e2fce829
    verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')
    sha256
    append a5b22aa26333881605966bb2fe2fe17f0a088064806c3c2e4ec15bf440a6c313
    sha256
    append 367bb32757561efee9331a8e0900f9c25f2e0949fb7584961791a9b51d480c76
    sha256
    prepend e69566cbb104e5090e15feff190ff6167677cd8d126c561272e2a924527ecdb9
    sha256
    append 168afd2a028d45f901a496e6f60477c4d4242b33ad1d16ab153e3a56c678822f
    sha256
    prepend d79c3fb7dccd0b28250f47e4291d76339c2c99cc0807f6e33d0863fd35e176bf
    sha256
    append 3796a0de7d3138e47e340663d4483cc52fa49ebe5f8ce62ce5debde91d2da81a
    sha256
    prepend 0100000001eded3975b617be12b4d9d26f600dbff09e122ce69222b6e8a038a43f14c77da2000000004847304402200d18dd24aba0b18cdb43ded74e5fe44f2e7491195a3d726218f35a797d5c164902207c8bf3ecb9c5cc8c2553cb6c6fc5d99716334f2dca14676190fe45985d24fee001fdffffff0282733100000000002321037b28af5bfc4ed21e78e541fc12a11bbcc4bdbf7ca59bef70aade644f97bb2d04ac0000000000000000226a20
    append f6f30600
    sha256
    sha256
    append def74ac2a943a41eb16169d8b30fcd8a06725ccc18cf006edd9d940e36fd9631
    sha256
    sha256
    append 4952ed708ffdde79d0a86e63711c7b6bcc5dc1b18e9034fdfc87afa64c570b19
    sha256
    sha256
    prepend 8d25dd5023fdfba3de713ff4df9e88fbf0e6792e190a87287f9b76915aec31bb
    sha256
    sha256
    append a5110f3b1f7a704a7481544e4740e1c7d79f2fddf71c4a9d0e8faff969b5a7ed
    sha256
    sha256
    append 5d9af3aa699fcae46a2a94638d0e9b4324fed74c613109333dddf18b2ee41c21
    sha256
    sha256
    append 0a603cd8d29516dc5477068d6b51defce1ce77e7189d6bb9b341b5cb8eeca536
    sha256
    sha256
    append 40e4872db15121979ed490225c0f963ded20722e35d2c1e8062c7bfd9a9c4a3f
    sha256
    sha256
    prepend b5074d6ab193566a1cc4d8bfcde8602a0b6b3720da69c10e0e994ec58a91d016
    sha256
    sha256
    prepend 133ddf23c6eca380669b91fd025417b89524a555f378e984777b5dec1006a78c
    sha256
    sha256
    append dddc977af3f5dce8721d26e1331f80a76ef472f9bff3b4e735a4364dddae443e
    sha256
    sha256
    prepend 03cf82f6463395be306282122933ba3b774a0f6c278529ca4b9c8df7f005d3b8
    sha256
    sha256
    append 0d26ec24c36996d60adeab2e80b374185a897b00fbc0e582084ed43c9cc91cbf
    sha256
    sha256
    verify BitcoinBlockHeaderAttestation(455671)
 -> append c37914ced3ae02f1c43e8ef19ec11c1c
    sha256
    prepend 58b9e977
    append bfea8361e1410f2f
    verify PendingAttestation('https://bob.btc.calendar.opentimestamps.org')

I see the attestation transaction was included in block 455671. But how can I tell which transaction roots the OpenTransactions merkle tree? Pointing me to more information on how to read an ots info file would also be helpful.

[petertodd]

While you can figure out what the txid is, why do you want to know that? You only need block headers to verify a timestamp; look at how the BitcoinBlockHeaderAttestation code works.

[dhimmel]

While you can figure out what the txid is, why do you want to know that?

I was writing a blog post, and I wanted know how OpenTimestamps calendars record data in the blockchain... so I went looking for an OpenTimestamps transaction. I couldn't find one, but ended up finding a Reddit comment that OP_RETURN is used to embed the data.

look at how the BitcoinBlockHeaderAttestation code works

I see verify_against_blockheader and the following in the BitcoinBlockHeaderAttestation documentation:

Otherwise no additional redundant data about the block header is recorded. This is very intentional: since the attestation contains (nearly) the absolute bare minimum amount of data, we encourage implementations to do the correct thing and get the block header from a by-height index, check that the merkleroots match, and then calculate the time from the header information. Providing more data would encourage implementations to cheat.

So I get that .ots files should contain the bare minimum. But it would be nice if the .info output could more verbosely trace the hash path including the actual transaction ID that commits it to the blockchain. In other words, so I can conceptually understand and verify timestamps, I'd like a more tangible human-readable trace of the attestation. I want to see a hash that I can verify exists in the blockchain.

Let me know if I'm thinking about this incorrectly.

One primary issue is that I'm not sure how to read the .info file. I'm happy to think about more human-readable formats for info output once I understand the current format.

[petertodd]

Ah, that's an interesting blog post! Is it still a draft, or is that the final public post? An interesting follow-up would be a post describing how those same researchers could have done things right.

Note that there is no such thing as ".info output" - the output of ots info isn't meant to be parsed as a file, rather it's meant to be a human-readable display of what's in the timestamp and how that timestamp works. I could probably improve the documentation of that to aid users in understanding what's going on.

Basically, what the info command is showing you is the tree structure of the timestamp, and every operation applied. The arrows are where the tree branches - that's what allows one file to be timestamped by multiple attestations.

The tricky part with adding txids, is the file itself doesn't tell you what is or isn't a tx. So you'd have to add huristics to the info command that tried to guess what parts of the timestamp were a tx, and those heuristics could get it wrong. I'm not opposed to doing that, but I'd want to be careful how it's presented to the user.

As for "verifying what hash is in the blockchain", maybe the thing you actually want is for info to tell you the results of each operation. That'd let you easily see that the final result - what should be the merkle root of the block - is in fact in the Bitcoin chain.

[dhimmel]

Is it still a draft, or is that the final public post? An interesting follow-up would be a post describing how those same researchers could have done things right.

Final, but @profjsb have been discussing ways to "do it right", which would require a system for pre-registration of hypotheses. So in addition to proof of existence, we need solutions for proof of authorship and proof of exclusivity (that multiple versions of the hypothesis didn't exist). We're still brainstorming... any advice welcome.

Regarding OTS info, I'll leave another comment after I have some more time to look into it.

[dhimmel]

the thing you actually want is for info to tell you the results of each operation.

Yes, that would be super helpful.

I also think it would help for the info to be in a structured format, so that it more clearly documents itself. YAML achieves a nice balance between human and machine readability. If you're opposed to a PyYAML dependency, JSON would also be an option.

How about something like the following (sha256_hash is the resulting hash, would not be empty in real example):

file_sha256_hash: 3e8931c7a0ff54b4c77ec845dd17a385d8705c285c88521d1428b39ab06421e7
timestamp:
- append: b1cbf92d328dee6f4c7ecd19ab94969e
  sha256_hash: ''
- prepend: ed788ebf68555688fd41e529d1eae955fbb0b7e8e3d63ed59c9f3eed29b309e1
  sha256_hash: ''
- - append: 8be1d43da44c76954746861b77a63ff4
    sha256_hash: ''
  - append: 8bda26c3e2fce829
    prepend: 58b9e977
    sha256_hash: ''
    verify: PendingAttestation('https://alice.btc.calendar.opentimestamps.org')
  - append: a5b22aa26333881605966bb2fe2fe17f0a088064806c3c2e4ec15bf440a6c313
    sha256_hash: ''
  # skip ahead
  - append: 0d26ec24c36996d60adeab2e80b374185a897b00fbc0e582084ed43c9cc91cbf
    sha256_hash: ''
  - sha256_hash: ''
    verify: BitcoinBlockHeaderAttestation(455671)
  - sha256_hash: ''
- - append: c37914ced3ae02f1c43e8ef19ec11c1c
    sha256_hash: ''
  - append: bfea8361e1410f2f
    prepend: 58b9e977
    sha256_hash: ''
    verify: PendingAttestation('https://bob.btc.calendar.opentimestamps.org')

Such a format would also give you more flexibility to add additional metadata down the road. Additionally, improved machine readability would be nice for users who want to verify a timestamp independently of the OTS codebase.

The tricky part with adding txids, is the file itself doesn't tell you what is or isn't a tx. So you'd have to add huristics to the info command that tried to guess what parts of the timestamp were a tx, and those heuristics could get it wrong. I'm not opposed to doing that, but I'd want to be careful how it's presented to the user.

So one of the sha256_hash values above is a transaction id? You could always add - inferred_txid: true to the dictionary with the hash that is the suspected txid.

The arrows are where the tree branches - that's what allows one file to be timestamped by multiple attestations.

Do you expect that most attestations will share substantial portions of the tree? If not, it may make sense for readability to just use a list structure and duplicate the common portion of the tree.

@petertodd, if you point me to the area of the code that creates the info output (see cmds.py#L489-L503, timestamp.py#L195-L211), I'm happy to take a crack at an implementation.

[RCasatta]

Hi @dhimmel,

In a test branch I have the verbose output info which will print the following:

$ ./ots -v info examples/hello-world.txt.ots
File sha256 hash: 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340
Timestamp:
ripemd160 (03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340)
prepend 0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a914 (1df8859e60bc679503d16dcb870e6ce91a57e9df)
append 88ac00000000 (0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a9141df8859e60bc679503d16dcb870e6ce91a57e9df)
sha256 (0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a9141df8859e60bc679503d16dcb870e6ce91a57e9df88ac00000000)
sha256 (9c6aa9591003377455b6f27fc71b5acfa5fbb2fa49362fa87a25ef0d799dd462)
prepend a987f716c533913c314c78e35d35884cac943fa42cac49d2b2c69f4003f85f88 (ecb27c6264dc88ef9b8a77fa9a53903f4c81be4a2fe2b2519e2daa9d7d0f9f7e)
sha256 (a987f716c533913c314c78e35d35884cac943fa42cac49d2b2c69f4003f85f88ecb27c6264dc88ef9b8a77fa9a53903f4c81be4a2fe2b2519e2daa9d7d0f9f7e)
sha256 (e7b919aef5283e190c46d8cc4df2f1ff5343dcdb730638438cb28c16e0b829f0)
prepend dec55b3487e1e3f722a49b55a7783215862785f4a3acb392846019f71dc64a9d (169be2743153b2bb751136acee44d14200ddc9e49cf6594af8d2d2a2104b6228)
sha256 (dec55b3487e1e3f722a49b55a7783215862785f4a3acb392846019f71dc64a9d169be2743153b2bb751136acee44d14200ddc9e49cf6594af8d2d2a2104b6228)
sha256 (a08c812aaaa5dc42e24674d988d652d42115d1b30470e34431abbc8c74accd0c)
prepend b2ca18f485e080478e025dab3d464b416c0e1ecb6629c9aefce8c8214d042432 (dda599c3662f06e455656173195c805ad31bde2dd7c6e058e3c938d2fa6a6d06)
sha256 (b2ca18f485e080478e025dab3d464b416c0e1ecb6629c9aefce8c8214d042432dda599c3662f06e455656173195c805ad31bde2dd7c6e058e3c938d2fa6a6d06)
sha256 (4f5fb40ee3f02eafe3b9c4c2cdd0787dcc0f6cbf622dd17e04155fa4da74ff75)
append 11b0e90661196ff4b0813c3eda141bab5e91604837bdf7a0c9df37db0e3a1198 (20a48517b9e288c46b48987110b4d62056ec4c5234b1dac7ec2af867b13c850a)
sha256 (20a48517b9e288c46b48987110b4d62056ec4c5234b1dac7ec2af867b13c850a11b0e90661196ff4b0813c3eda141bab5e91604837bdf7a0c9df37db0e3a1198)
sha256 (829037f5e71c2168fdc9169fd1d361b8dc027ec98ecfecfb7b141b29555d4121)
append c34bc1a4a1093ffd148c016b1e664742914e939efabe4d3d356515914b26d9e2 (16a800adc6c37b8bdd800e9b48e67b0b62912061a785c892fad592116b57cab8)
sha256 (16a800adc6c37b8bdd800e9b48e67b0b62912061a785c892fad592116b57cab8c34bc1a4a1093ffd148c016b1e664742914e939efabe4d3d356515914b26d9e2)
sha256 (35372e44256cf9c49a51d7f17185ac4d5417c81cdde359c5e91e89d3c0cdb0f9)
append c3e6e7c38c69f6af24c2be34ebac48257ede61ec0a21b9535e4443277be30646 (535cc781a96fc168ad1abf2757999e77c71ab3aa24b926d73a1ca9c6ba029614)
sha256 (535cc781a96fc168ad1abf2757999e77c71ab3aa24b926d73a1ca9c6ba029614c3e6e7c38c69f6af24c2be34ebac48257ede61ec0a21b9535e4443277be30646)
sha256 (9d5440dbb399e24d04a39f219f84bfba45e9159d52f5be3d56e93291d03b7ae9)
prepend 0798bf8606e00024e5d5d54bf0c960f629dfb9dad69157455b6f2652c0e8de81 (83b0b3b5d451418ddc864bf34afba138fd0541469fa00977756877a6c36fc1dd)
sha256 (0798bf8606e00024e5d5d54bf0c960f629dfb9dad69157455b6f2652c0e8de8183b0b3b5d451418ddc864bf34afba138fd0541469fa00977756877a6c36fc1dd)
sha256 (ae2b925b5e50f03f9b42fbe85368812799e13b19d8812cd7779057395795ac79)
append 3f9ada6d60baa244006bb0aad51448ad2fafb9d4b6487a0999cff26b91f0f536 (d4637af05f82eddc4e4254f340e0bebaf6713c70f21d538736483f07292392c6)
sha256 (d4637af05f82eddc4e4254f340e0bebaf6713c70f21d538736483f07292392c63f9ada6d60baa244006bb0aad51448ad2fafb9d4b6487a0999cff26b91f0f536)
sha256 (af3c11e76808d7aa9753d8478c0d468444db5eb5bc26b7511813bfc5f630e19b)
prepend c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8 (efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45)
sha256 (c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45)
sha256 (04853c771da47330c3f89d117fe84f8f031ac1485572e71f0b8c54a5e5e20df9)
append cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788 (cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788)
sha256 (cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788)
sha256 (8a061c45c453f4af4b9b36b006f90bac2f6fcbe3a9f70f4267c6e623b68b8d4e)
prepend 0be23709859913babd4460bbddf8ed213e7c8773a4b1face30f8acfdf093b705 (3f10376d0aebb4647ff550b60d69ba5ad6b6809d51af6a6476e0312a9433a3bf)
sha256 (0be23709859913babd4460bbddf8ed213e7c8773a4b1face30f8acfdf093b7053f10376d0aebb4647ff550b60d69ba5ad6b6809d51af6a6476e0312a9433a3bf)
sha256 (faa6e88835c144ad73f48992bc05e691a52a9199df02450194f3a03b530dc2d7)
verify BitcoinBlockHeaderAttestation(358391) (007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a)

inside parenthesis you can see the timestamp message at the level of the operation in the same row, you can think it as the value on which the operation is applied. The first message is the sha256 of the hello-world.txt file. The last message is the merkle root of the bitcoin block height 358391. This should be enough and better than the tx id however somewhere in the middle you can find ecb27c6264dc88ef9b8a77fa9a53903f4c81be4a2fe2b2519e2daa9d7d0f9f7e which reversed is 7e9f0f7d9daa2d9e51b2e22f4abe814c3f90539afa778a9bef88dc64627cb2ec which is the bitcoin transaction id you are loooking for.

@petertodd is this output format good enough or do you have any idea to make it better? The transaction id is inconvenient to find because its reversed...

[dhimmel]

@RCasatta thanks for the implementation. It's a big improvement over the previous output.

A good way for new users to understand the format is to look at lines like:

prepend c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8 (efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45)
sha256 (c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45)

since it makes it obvious what the input / function / output is for each line.

One thing that that users should note is that you can't just hash the characters. Instead you have to do the following (Python 3) to account for their hex encoding:

encoded = 'faa6e88835c144ad73f48992bc05e691a52a9199df02450194f3a03b530dc2d7'
decoded = bytearray.fromhex(encoded)
sha_256_hash = hashlib.sha256(decoded)
sha_256_hash.hexdigest()

This operation provides 007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a as seen in the info.

@petertodd is this output format good enough or do you have any idea to make it better?

I still think that in the long run you may want to use a standardized file format. I expect many users will want to do automated tasks using this output.

somewhere in the middle you can find ... the bitcoin transaction id you are loooking for.

Is the underlying issue that the .ots file only stores the BitcoinBlockHeaderAttestation and not the BitcoinTransactionAttestation? It seems like it would be best to store both. I understand that the block header is what actually provides the timestamp, but it's nice to know the nexus between on-chain and off-chain and to see how the calendars make transactions for educational purposes.

[RCasatta]

I still think that in the long run you may want to use a standardized file format. I expect many users will want to do automated tasks using this output.

The standardized file format is the binary ots format. Textual output is useful for debugging and educational purpose. Users shouldn't make automated tasks based on the textual output.

Is the underlying issue that the .ots file only stores the BitcoinBlockHeaderAttestation and not the BitcoinTransactionAttestation? It seems like it would be best to store both. I understand that the block header is what actually provides the timestamp, but it's nice to know the nexus between on-chain and off-chain and to see how the calendars make transactions for educational purposes.

As you understand BitcoinBlockHeaderAttestation is more valuable than BitcoinTransactionAttestation, I don't think there is the need to insert redundant and derivable information inside the ots proof, a possible option is to TAG this information only in the textual output or simply have good documentation to explain design decision.

[petertodd]

Hey, sorry I missed this!

How about we make the text output look something like:

sha256
    == c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45

I think that'd be a bit more clear to users trying to figure out what it means.

[petertodd]

Re: BitcoinTransactionAttestation, my thinking there not only can it always be replaced by a BitcoinBlockHeaderAttestation, verifying a transaction attestation requires a costly and non-scalable transaction index; we really don't want to encourage people to be creating timestamps that are difficult to verify.

[RCasatta]

How about we make the text output look something like:
sha256 == c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45

This is already better.

We should consider also Andrew's more verbose output:
https://gist.github.com/RCasatta/538e7e9bce6dc1158ced877035ce9f1a

[RCasatta]

Here is my last test:

• After == there is the result of the current operation
• There are tags starting with # for bitcoin transaction and merkle root (this are printed with default verbosity currently)
• We could support also text in bold to highlight where the parameter is present in the result example

@petertodd if you think it's ok I'll make the PR

$ ./ots -v info examples/hello-world.txt.ots 
File sha256 hash: 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340
Timestamp:
ripemd160 == 1df8859e60bc679503d16dcb870e6ce91a57e9df
prepend 0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a914 == 0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a9141df8859e60bc679503d16dcb870e6ce91a57e9df
append 88ac00000000 == 0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a9141df8859e60bc679503d16dcb870e6ce91a57e9df88ac00000000
# Bitcoin transaction id 7e9f0f7d9daa2d9e51b2e22f4abe814c3f90539afa778a9bef88dc64627cb2ec
sha256 == 9c6aa9591003377455b6f27fc71b5acfa5fbb2fa49362fa87a25ef0d799dd462
sha256 == ecb27c6264dc88ef9b8a77fa9a53903f4c81be4a2fe2b2519e2daa9d7d0f9f7e
prepend a987f716c533913c314c78e35d35884cac943fa42cac49d2b2c69f4003f85f88 == a987f716c533913c314c78e35d35884cac943fa42cac49d2b2c69f4003f85f88ecb27c6264dc88ef9b8a77fa9a53903f4c81be4a2fe2b2519e2daa9d7d0f9f7e
sha256 == e7b919aef5283e190c46d8cc4df2f1ff5343dcdb730638438cb28c16e0b829f0
sha256 == 169be2743153b2bb751136acee44d14200ddc9e49cf6594af8d2d2a2104b6228
prepend dec55b3487e1e3f722a49b55a7783215862785f4a3acb392846019f71dc64a9d == dec55b3487e1e3f722a49b55a7783215862785f4a3acb392846019f71dc64a9d169be2743153b2bb751136acee44d14200ddc9e49cf6594af8d2d2a2104b6228
sha256 == a08c812aaaa5dc42e24674d988d652d42115d1b30470e34431abbc8c74accd0c
sha256 == dda599c3662f06e455656173195c805ad31bde2dd7c6e058e3c938d2fa6a6d06
prepend b2ca18f485e080478e025dab3d464b416c0e1ecb6629c9aefce8c8214d042432 == b2ca18f485e080478e025dab3d464b416c0e1ecb6629c9aefce8c8214d042432dda599c3662f06e455656173195c805ad31bde2dd7c6e058e3c938d2fa6a6d06
sha256 == 4f5fb40ee3f02eafe3b9c4c2cdd0787dcc0f6cbf622dd17e04155fa4da74ff75
sha256 == 20a48517b9e288c46b48987110b4d62056ec4c5234b1dac7ec2af867b13c850a
append 11b0e90661196ff4b0813c3eda141bab5e91604837bdf7a0c9df37db0e3a1198 == 20a48517b9e288c46b48987110b4d62056ec4c5234b1dac7ec2af867b13c850a11b0e90661196ff4b0813c3eda141bab5e91604837bdf7a0c9df37db0e3a1198
sha256 == 829037f5e71c2168fdc9169fd1d361b8dc027ec98ecfecfb7b141b29555d4121
sha256 == 16a800adc6c37b8bdd800e9b48e67b0b62912061a785c892fad592116b57cab8
append c34bc1a4a1093ffd148c016b1e664742914e939efabe4d3d356515914b26d9e2 == 16a800adc6c37b8bdd800e9b48e67b0b62912061a785c892fad592116b57cab8c34bc1a4a1093ffd148c016b1e664742914e939efabe4d3d356515914b26d9e2
sha256 == 35372e44256cf9c49a51d7f17185ac4d5417c81cdde359c5e91e89d3c0cdb0f9
sha256 == 535cc781a96fc168ad1abf2757999e77c71ab3aa24b926d73a1ca9c6ba029614
append c3e6e7c38c69f6af24c2be34ebac48257ede61ec0a21b9535e4443277be30646 == 535cc781a96fc168ad1abf2757999e77c71ab3aa24b926d73a1ca9c6ba029614c3e6e7c38c69f6af24c2be34ebac48257ede61ec0a21b9535e4443277be30646
sha256 == 9d5440dbb399e24d04a39f219f84bfba45e9159d52f5be3d56e93291d03b7ae9
sha256 == 83b0b3b5d451418ddc864bf34afba138fd0541469fa00977756877a6c36fc1dd
prepend 0798bf8606e00024e5d5d54bf0c960f629dfb9dad69157455b6f2652c0e8de81 == 0798bf8606e00024e5d5d54bf0c960f629dfb9dad69157455b6f2652c0e8de8183b0b3b5d451418ddc864bf34afba138fd0541469fa00977756877a6c36fc1dd
sha256 == ae2b925b5e50f03f9b42fbe85368812799e13b19d8812cd7779057395795ac79
sha256 == d4637af05f82eddc4e4254f340e0bebaf6713c70f21d538736483f07292392c6
append 3f9ada6d60baa244006bb0aad51448ad2fafb9d4b6487a0999cff26b91f0f536 == d4637af05f82eddc4e4254f340e0bebaf6713c70f21d538736483f07292392c63f9ada6d60baa244006bb0aad51448ad2fafb9d4b6487a0999cff26b91f0f536
sha256 == af3c11e76808d7aa9753d8478c0d468444db5eb5bc26b7511813bfc5f630e19b
sha256 == efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45
prepend c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8 == c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8efa898490f9cc0dcd698220e9a9c1acc01b54c1c14b23520ace3cd82341f6b45
sha256 == 04853c771da47330c3f89d117fe84f8f031ac1485572e71f0b8c54a5e5e20df9
sha256 == cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788
append cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788 == cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788
sha256 == 8a061c45c453f4af4b9b36b006f90bac2f6fcbe3a9f70f4267c6e623b68b8d4e
sha256 == 3f10376d0aebb4647ff550b60d69ba5ad6b6809d51af6a6476e0312a9433a3bf
prepend 0be23709859913babd4460bbddf8ed213e7c8773a4b1face30f8acfdf093b705 == 0be23709859913babd4460bbddf8ed213e7c8773a4b1face30f8acfdf093b7053f10376d0aebb4647ff550b60d69ba5ad6b6809d51af6a6476e0312a9433a3bf
sha256 == faa6e88835c144ad73f48992bc05e691a52a9199df02450194f3a03b530dc2d7
sha256 == 007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a
verify BitcoinBlockHeaderAttestation(358391)
# Bitcoin block merkle root 8a1b66ecb7cbd07d8139a7e7d7f2c41aab1f5009b8364aaf61d03ad245e47e00

[dhimmel]

@RCasatta I like your latest format and think you should open the pull request. I'd even favor replacing the default output (not requiring the --verbose flag), since I don't think the current info output is very helpful. You could always support the legacy output with --concise.

One final question, if I look at the metadata for block 358391, I see the Merkle Root of 8a1b66ecb7cbd07d8139a7e7d7f2c41aab1f5009b8364aaf61d03ad245e47e00. However, I do not see the final sha256 hash of 007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a. How does one get from the hash to the merkle root? Shouldn't that operation be included here as part of the cryptographic chain of operations?

[petertodd]

I'm inclined to keep the == stuff as a verbose option; I use info all the time to see how a timestamp was made, but almost never need to know the exact results of each operation.

@RCasatta Otherwise looks good; make that PR!

[petertodd]

@dhimmel Bitcoin uses a non-standard little-endian display for digests; try reading 8a1b66ecb7cbd07d8139a7e7d7f2c41aab1f5009b8364aaf61d03ad245e47e00 backwards. :)

[dhimmel]

Ah I see:

>>> digest = '8a1b66ecb7cbd07d8139a7e7d7f2c41aab1f5009b8364aaf61d03ad245e47e00'
>>> bytes(reversed(bytes.fromhex(digest))).hex()
'007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a'

Good to know. I'm guessing this is a common point of confusion. @RCasatta not sure if you have any ideas on whether the verbose output should add some sort of comment or whether users are just going to have to figure this out.

[petertodd]

I think that confusion is the kind of thing that should be explained in the documentation.

Which speaking of: we need to write up at least some man pages, and preferably a guide to using OpenTimestamps. My blog post is a start, but just a start.

[davterra]

Hi all,
I'm about 18 months late to this conversational party, but I have been deep-diving into OpenTimeStamps the past few days, and I don't see any implementation of the changes discussed so far in this thread.
I'm running it on my bitcoind node, and the output I get with a -v info query is the same as dhimmel referenced in his first comments.

As much as I understand that a mere statement of existence of a stamp in a given block is a sufficient proof, not everyone (including a judge or jury) would understand that, and it would be extremely helpful to be able to show the exact transaction/hash info.

I've also tried dragging the stamped files into the OpenTimeStamp website and examining the detailed digest that results, but I'm still not able to find the specific tx reference. There are a couple of "parse tx" hashes, but they don't seem to lead to a tx with script showing the expected DUP HASH160 output as Peter Todd showed in his post: https://petertodd.org/2016/opentimestamps-announcement#fn:hello-world-address

Am I missing something?
Thanks