How long does it take for attestation to take place?

[marsrobertson]

If you want to try yourself, files are uploaded here: https://github.com/marsrobertson/marsrobertson.com/tree/gh-pages/files

Now it's 14:51.

Tried version installed locally on my machine ots stamp as well as the main website.

Multiple Bitcoin blocks have passed.

• Is there any reason why is it taking so long?
• What is the expected wait time?
• What shall I do if I need to obtain Open Timestamp instantly?

[petertodd]

Basically it takes time for a transaction to get mined.

But your timestamp is complete the moment you make it in the sense that you will be any to verify it later: you don't have to do anything for that process to complete.

On May 31, 2019 9:55:03 AM EDT, Mars Robertson notifications@github.com wrote:

If you want to try yourself, files are uploaded here: https://github.com/marsrobertson/marsrobertson.com/tree/gh-pages/files

Now it's 14:51.

Tried version installed locally on my machine ots stamp as well as the main website.

Multiple Bitcoin blocks have passed.

• Is there any reason why is it taking so long?
• What is the expected wait time?
• What shall I do if I need to obtain Open Timestamp instantly?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/opentimestamps/opentimestamps.org/issues/45

[marsrobertson]

Yesterday I was waiting a few hours and still "pending attestation"

Today I'm trying again and "bitcoin block height 578710 not found"

I understand in theory no action needed, in reality it's troublesome.

Files are here for anyone to test: https://github.com/marsrobertson/marsrobertson.com/tree/gh-pages/files

Cobra Bitcoin Twitter archive FROM WEB.xlsx
Cobra Bitcoin Twitter archive FROM WEB.xlsx.ots
Cobra Bitcoin Twitter archive.xlsx
Cobra Bitcoin Twitter archive.xlsx.ots

(tried both web version on locally installed ots stamp)

[marsrobertson]

last night

this morning

File: https://github.com/marsrobertson/marsrobertson.com/raw/gh-pages/files/random-building.png OTS: https://github.com/marsrobertson/marsrobertson.com/raw/gh-pages/files/random-building.png.ots

[marsrobertson]

I gave it some time...

Still "Pending attestation"

It's a difficult situation for me - I love Bitcoin - I love all the use cases. The inability to demonstrate OpenTimestamps is tricky...

Can you try and reproduce, verify that it's not just me?

[RCasatta]

I tried your random building test and it works as expected (It could be we had problem with blockexplorer some time ago which are now resolved)

About your last try, it takes about a day for a receipt to be completed and from the dates I can see this time hasn't passed yet

[marsrobertson]

@RCasatta thanks!

I've just tried again and it works

I thought that 1 confirmation is enough? Can you please help me understand:

"about a day for a receipt to be completed"

Also the old example works!

(previously FAILURE, Bitcoin block not found)

[petertodd]

I thought that 1 confirmation is enough? Can you please help me understand:

The timestamp calendars wait a few confirmations before adding the proof to the database, because the current codebase doesn't handle reorgs to timestamps in the database without manual intervention.

Besides, the validity of a timestamp with just one confirmation is dubious - maybe a miner produced a block for the purpose of faking a timestamp? The client doesn't display timestamps to more than one day precision for this kind of reason.

[marsrobertson]

With Bitcoin, people who use it, some of them know:

• mempool (0-conf)
• RBF
• 1 conf
• 2 conf

It is up to end-user to decide whether they require 6 conf, it is up to the merchant software to highlight in the user interface: "this transaction is RBF, be aware of double-spend"

With Open Timestamps, I think it also perfectly possible to allow users to decide:

• 1 conf
• 2 conf
• ...
• 6 conf

For simplicity, I am OK to display in the UI how many confirmations have passed (if less than 6) and after that show the date.

"about a day" - is there a justifiable reason for that or maybe 6 conf is enough?

---

The timestamp calendars wait a few confirmations before adding the proof to the database

timestamps in the database

Are you referring https://github.com/opentimestamps/opentimestamps-server saving stuff to the database?

I thought that my .ots, original file, and Bitcoin blockchain are sufficient to verify. What if 100 years from now none of the existing servers (and their databases) exist?

(keen to better understand the architecture, always on the side of adoption and usability)

[petertodd]

For simplicity, I am OK to display in the UI how many confirmations have passed (if less than 6) and after that show the date.

I'm not. It's misleading because decentralized blockchain timestamps just don't work like that, and we shouldn't encourage uninformed users to think that they do.

"about a day" - is there a justifiable reason for that or maybe 6 conf is enough?

Here's a writeup of the issue that I posted to bitcoin-dev awhile back: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013120.html

Anyway, the reality is that timestamps are rarely verified immediately, except for demonstrations.

I thought that my .ots, original file, and Bitcoin blockchain are sufficient to verify. What if 100 years from now none of the existing servers (and their databases) exist?

Only if you've run the upgrade command to get a local copy of the rest of the proof. You can see this by inspecting the actual timestamp with ots info: prior to running upgrade it's missing part of the data.

This is an intentional tradeoff to make saving the timestamps immediately in a permanent form to be feasible: everyone keeping their own copy of all the calendar data is feasible, as the calendar data is relatively small. Our tooling to actually do that isn't great (see https://github.com/opentimestamps/opentimestamps-server/blob/master/otsd-backup.py for a good start) But I'm working on improving that.