Undiscussed Horrific Abuse, One Victim of Many [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2022-06-14 to 2022-06-15
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:06:17

- reply

📅 Original date posted:2022-06-14
📝 Original message:
hey various,
it's been obvious since its inception that opentimestamps is designed
to be broken.
if you have energy to normalise a better system, or support one of the
other better systems that already exists, that's wonderful.
i suspect the opentimestamps ecosystem is very experienced at defending itself.

2023-06-07 23:10:43

- reply

📅 Original date posted:2022-06-14
📝 Original message:> I do reiterate that it is blindingly easy to pin a public hash to the
> bitcoin blockchain that asserts the earliest publication of a document
> or collection of documents, and that this is desperately needed, to
> protect the accuracy of history when it is not safe.
The concern raised here relates to scaling, and here we disagree on
the proper direction of Bitcoin. To me it seems clear that Bitcoin was
designed to scale better than it has. It honestly looks like
developers are arbitrarily avoiding storing much data on chain, with
quickly shoehorned solutions like the lightning protocol. Bitcoin
simply got big too fast. I believe it was intended to handle large
data smoothly: not with single gigabyte blocks that every user must
store, but with simplistically designed and well-backed decentralised
propagation and storage of data. I see that not having happened due to
mostly political issues, and that's unfortunate, but other chains have
made strides here.
I don't think satoshi was familiar with how people behave when they
have a lot of money.

2023-06-07 23:10:43

- reply

📅 Original date posted:2022-06-14
📝 Original message:On 6/14/22, Andrew Poelstra <apoelstra at wpsoftware.net> wrote:
> On Tue, Jun 14, 2022 at 01:15:08PM -0400, Undiscussed Horrific Abuse, One
> Victim of Many via bitcoin-dev wrote:
>> I'm replying to Peter, skipping the other emails.
>>
>> I perceive all these emails as disruptive trolling, ignoring the
>> importance of real timestamping, while handwaving about things that
>> are roughly false and harmful.
>>
>> Since the start of cryptocurrency, Bitcoin has been used to write
>> timestamps that stay intact despite malicious action to arbitrary
>> systems and records, showing the earliest on-chain publication of
>> data. It seems misleading that OTS does not do that, when it is such a
>> prominent system.
>>
>
> Please be cautious with tone and when assuming bad faith. I don't believe
> that Peter is trolling. Also, as politely as I can, when something like
> OTS whose model is dead-simple, well-documented, and has been running for
> years providing significant value to many people, comes under attack for
> being underspecified or failing to do what it says ... this is a
> surprising claim, to say the least.
Thank you for your reply, Andrew. I don't think Peter is trolling, but
I do suspect some body like a spy agency of strengthening the
timestamping solutions that have nonces in their merkle trees,
avoiding usability for storing public records in a way that could be
verified by anonymous and censored third parties.
> After talking to a few people offline, all of whom are baffled at this
> entire conversation, I think the issue might come down to the way that
> people interpret "timestamping".
>
> If you believe that "timestamping" means providing a verifiable ordering
> to events, then of course OTS does not accomplish this, nor has it ever
> claimed to. If you think that "timestamping" means proving that some
> data existed at a particular time, then this is exactly what OTS does.
>
> Personally -- and I suspect this is true of Peter as well -- I have always
> read the word as having the latter meaning, and it never occurred to me
> until now that others might have a different interpretation.
I looked some into the history of timestamping and I see that what you
are saying is the academic norm.
I don't see OTS as proving the data existed at a particular time,
because the proof is held in a document the user must protect. I
understand somewhat now that it is designed for users who can actually
protect that data sufficiently.
I do reiterate that it is blindingly easy to pin a public hash to the
bitcoin blockchain that asserts the earliest publication of a document
or collection of documents, and that this is desperately needed, to
protect the accuracy of history when it is not safe.
I worry that this form of "rfc timestamping" misleads its users into
believing the timestamps of their documents are preserved. These kinds
of user interaction issues can be very dangerous.
I would recommend uploading .ots files to chains with cheap storage,
such as arweave or bitcoin sv. This way people can prove which one was
first, when there is more than one. For that to work, we need a norm
of how and where to do it, so that users look in the same place, and
it is the people who make the public services and standards, that set
that norm.
Thank you for your reply, and I apologise for my poor support.
It is obvious that Peter has put incredible hard and long work into
providing OTS to the community in a clean and robust fashion, and that
is always very wonderful, and I have very thoroughly failed to
acknowledge that.

2023-06-07 23:10:42

- reply

📅 Original date posted:2022-06-14
📝 Original message:I'm replying to Peter, skipping the other emails.
I perceive all these emails as disruptive trolling, ignoring the
importance of real timestamping, while handwaving about things that
are roughly false and harmful.
Since the start of cryptocurrency, Bitcoin has been used to write
timestamps that stay intact despite malicious action to arbitrary
systems and records, showing the earliest on-chain publication of
data. It seems misleading that OTS does not do that, when it is such a
prominent system.
>> 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
This makes total sense to reduce the expense and size of etching these
very short hashes.
But the OTS approach hashes in a _private nonce_ for every document,
preventing anybody from validating the earliness of an item in a
merkle tree without access to every proof.
Do you think OTS would be interested in publicizing nonces and
document hashes, if the user consents?
Non-developers need a tool where they can choose to pay funds to write
a strong timestamp that guarantees earliness of publication of a
document, and for free discern the earliness of timestamped data they
provide to the tool.
> Client-side validated .ots files are a necessary requirement to achieve
> this
> scalability.
Nothing in an engineering task is a strict requirement, aside from the
specification. The data could be publicised elsewhere, or funds
provided to store it on-chain.
> FWIW the most I've personally done is timestamped 750 million items from
> the
> Internet Archive with a single transaction.
That's impressive. It's always great when we write something that can
condense something huge into something tiny and keep working, and use
it reliably.
I would have put the files in a shared datalad repository, and put the
tip commit of the repository in an OP_RETURN along with a tag such as
'DL' or 'IA'.
Then a tool could look for all 'DL' or 'IA' transactions, and verify
that mine was the earliest. You would of course need access to the
etched repositories' git commits.
If the hash can't be verified by an anonymous observer, the archive is
only timestamped for people with the proof. How is the challenge of
protecting many proofs different from the challenge of protecting the
data they prove?
>> 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.
If they can destroy your .ots proof, the information on the blockchain
no longer demonstrates anything.

2023-06-07 23:10:40

- reply

📅 Original date posted:2022-06-14
📝 Original message: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.

2023-06-07 23:10:40

- reply

📅 Original date posted:2022-06-14
📝 Original message:hi r1m, i'll talk with you as long as it's fun to do so.
>> 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
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.
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.
>> 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.
> for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to
I mean the cryptographic wallets that hold the funds spent in etching
the hash to the chain.

2023-06-07 23:10:39

- reply

📅 Original date posted:2022-06-14
📝 Original message:hey various,
it's been obvious since its inception that opentimestamps is designed
to be broken.
if you have energy to normalise a better system, or support one of the
other better systems that already exists, that's wonderful.
i suspect the opentimestamps ecosystem is very experienced at defending itself.