Tampering during Bitcoin TX confirmation

[phptek]

The possibility exists for tampering to occur in the time elapsed between an object's publication, and the Bitcoin transaction in which that published version's hash is embedded, is confirmed.

A user could publish an article, and parts of it could be subject to unauthorised change (outside of manual verification by proof reading for example) until the relevant Bitcoin transaction is confirmed, and the Chainpoint network is able to return a proof.

Some way should be found to preclude this from happening using perhaps an alternative 3rd party service to temporarily provide tamper evident services such as a simple AWS lambda - a "poor mans hash verification service" if you like. This would only be in service while the chainpoint network is unable to provide a proof response from the Bitcoin network.

[stoneloup]

while not a perfect solution, since in the Chainpoint process, the first proof that comes back is the one from the Chainpoint calendar ("type" : "cal") in about 5-15 secs. with this, there would be no need to worry about the 90 mins time gap before the Bitcoin proof ("type" : "btc") came back, or at least the window where changes could be made to the underlying hashed content would be greatly reduced from 90 mins down to 15 secs.

[phptek]

While you're technically correct, we are however wholly contingent on Bitcoin's PoW for an immutible data store, something that isn't ensured from Chainpoint's network (otherwise we'd just use Chainpoint and forget about Bitcoin), this assumes you're alluding to the temporary use of Chainpoint in this specific case. If you meant something else, apologies. Could you possibly further detail the solution? (However rough).

Thanks for your interest btw!