đź“… Original date posted:2022-06-14
đź“ť Original message:Good morning Undiscussed Horrific Abuse, One Victim of Many,
> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.
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 existed, and says nothing about how long after the timestamp the content continues to exist. It also says nothing about uniqueness or validity of the content. For example, a document that existed for a year before its timestamp and was deleted immediately afterwards, and a document that was created the instant before its timestamp and was retained “forever” afterwards would have timestamp that are equally valid (provided you retained the digest of the document to validate the timestamp in the former case). Assurances around uniqueness (for example, preventing double spends) are a proof-of-publication or set-consistency problem, and assurances around validity are a validation problem. These other semantics can be built into systems that also rely on timestamps, but you can have a useful time stamping system without them. This is what OTS provides. When you say it’s “designed to be broken” do you mean that it claims to provide assurances that it doesn’t, or that the set of assurances that it provides are not a useful set.
> I would not be surprised if OTS also fails to add tx history
> containing its hashes to associated wallets, letting them be lost in
> chain forks.
I’ve always used OTS through the cli, which just spits out and works with .ots files, which are sterilized commitment operations. Storage of the ots files for later checking has always been a “problem left to the application” for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to see them!
Best,
rot13maxi
On Tue, Jun 14, 2022 at 7:53 AM, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> I was privately asked for more opinions. I am sharing them publicly below:
>
> It's always been clear that OTS proves longness of duration but not
> shortness. It doesn't demonstrate that an earlier work was not
> published, because it hashes each document hash with private material
> the author must separately publicize. Any unpublished private material
> could be an earlier equivalent to a public proof.
>
> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.
>
> I would not be surprised if OTS also fails to add tx history
> containing its hashes to associated wallets, letting them be lost in
> chain forks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/883de78f/attachment.html>;
rot13maxi [ARCHIVE] /
npub12a…llglz
2023-06-07 23:10:40
in reply to nevent1q…t72u
Author Public Key
npub12aguh8y7hacsxc3c7fsjzkqh95nu9cuh4ec6htx9y3sz75722npqmllglzPublished at
2023-06-07 23:10:40Event JSON
{
"id": "e7911541c5227b6e620b247a74a6ad5d349324d43cbe0681fd6573452f51f73d",
"pubkey": "5751cb9c9ebf71036238f2612158172d27c2e397ae71abacc524602f53ca54c2",
"created_at": 1686179440,
"kind": 1,
"tags": [
[
"e",
"7a1fac01bd74ab25eff8d326c1b8e653af7145818f460a0707ae319166445d1f",
"",
"root"
],
[
"e",
"cabd069f4dca16de8c0bd91ed025eebe1d1b621ab7c5d3e377409387e39f55c9",
"",
"reply"
],
[
"p",
"ee73457a943dc01927ea5fda272d328401fc3850178b7b2a25e69cc647b01402"
]
],
"content": "📅 Original date posted:2022-06-14\n📝 Original message:Good morning Undiscussed Horrific Abuse, One Victim of Many,\n\n\u003e the reason i call this 'designed to be broken' is that it lets people\n\u003e rewrite history to their stories by republishing other people's\n\u003e documents under different contexts.\n\nThe 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 existed, and says nothing about how long after the timestamp the content continues to exist. It also says nothing about uniqueness or validity of the content. For example, a document that existed for a year before its timestamp and was deleted immediately afterwards, and a document that was created the instant before its timestamp and was retained “forever” afterwards would have timestamp that are equally valid (provided you retained the digest of the document to validate the timestamp in the former case). Assurances around uniqueness (for example, preventing double spends) are a proof-of-publication or set-consistency problem, and assurances around validity are a validation problem. These other semantics can be built into systems that also rely on timestamps, but you can have a useful time stamping system without them. This is what OTS provides. When you say it’s “designed to be broken” do you mean that it claims to provide assurances that it doesn’t, or that the set of assurances that it provides are not a useful set.\n\n\u003e I would not be surprised if OTS also fails to add tx history\n\u003e containing its hashes to associated wallets, letting them be lost in\n\u003e chain forks.\n\nI’ve always used OTS through the cli, which just spits out and works with .ots files, which are sterilized commitment operations. Storage of the ots files for later checking has always been a “problem left to the application” for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to see them!\n\nBest,\nrot13maxi\n\nOn Tue, Jun 14, 2022 at 7:53 AM, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I was privately asked for more opinions. I am sharing them publicly below:\n\u003e\n\u003e It's always been clear that OTS proves longness of duration but not\n\u003e shortness. It doesn't demonstrate that an earlier work was not\n\u003e published, because it hashes each document hash with private material\n\u003e the author must separately publicize. Any unpublished private material\n\u003e could be an earlier equivalent to a public proof.\n\u003e\n\u003e the reason i call this 'designed to be broken' is that it lets people\n\u003e rewrite history to their stories by republishing other people's\n\u003e documents under different contexts.\n\u003e\n\u003e I would not be surprised if OTS also fails to add tx history\n\u003e containing its hashes to associated wallets, letting them be lost in\n\u003e chain forks.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220614/883de78f/attachment.html\u003e",
"sig": "0e3751eed6a7c5be00b820be1e48daa5785903fcedd67defa59616a29db45c456ca6d6354d504146dfb93e806ca2e46a7318e80855d783542d1780c920d44516"
}