Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-14 📝 Original message:On Tue, Jun 14, 2022 at ...
📅 Original date posted:2022-06-14
📝 Original message:On Tue, Jun 14, 2022 at 08:45:43AM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> > The basic service that a timestamp service provides is “this content (or at
> > least a digest of this content) existed at least as early as this
> > timestamp.” It says nothing about how long before the timestamp the content
>
> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.
>
> This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.
That approach does not scale. Via merkle trees, the OpenTimestamps system
routinely timestamps tens of thousands of messages with a single transaction:
https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation
Client-side validated .ots files are a necessary requirement to achieve this
scalability.
FWIW the most I've personally done is timestamped 750 million items from the
Internet Archive with a single transaction.
> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.
They can also simply delete their copy of the data, making it impossible to
prove anything about it.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/b7ea831b/attachment-0001.sig>;
📝 Original message:On Tue, Jun 14, 2022 at 08:45:43AM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> > The basic service that a timestamp service provides is “this content (or at
> > least a digest of this content) existed at least as early as this
> > timestamp.” It says nothing about how long before the timestamp the content
>
> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.
>
> This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.
That approach does not scale. Via merkle trees, the OpenTimestamps system
routinely timestamps tens of thousands of messages with a single transaction:
https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation
Client-side validated .ots files are a necessary requirement to achieve this
scalability.
FWIW the most I've personally done is timestamped 750 million items from the
Internet Archive with a single transaction.
> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.
They can also simply delete their copy of the data, making it impossible to
prove anything about it.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/b7ea831b/attachment-0001.sig>;