OpenTimestamps (OTS) in Bisq — Design Analysis #4325
Replies: 3 comments 1 reply
-
|
Great and detailed analysis! Sad to see that OTS is coming with such disadvantages. Seems like you digged quite deep into OTS. First question coming to my mind: What if all oracle nodes fail / shutdown will the network still be able to function? Is that a scenario we should consider at all? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, thats a good point and we have to avoid that oracle nodes are required for trades. But as far I see now that will not be the case. We use them for time stamping the user profile creation data (already done) and for time stamping a payment account creation. If no oracle-signed data is present in the network, it is considered age zero. As it can be assumed that oracle nodes are only temporary out of service, the requests sent to them will be processed once they are available again and then the data gets published. Worst case the user need to do a request again if the tolerated time difference of oracles clock and the users requested time is too large. But re-requesting will be anyway required when the data have been expired or are close to expiry date. In that case the oracle will look up its already persisted data and republish. A similar process could be applied in case the user did not see the data shortly after request but with a new time to avoid that the oracle side tolerance check fails. So worst case is that that users age is a bit less old as it would have been if oracles would have been available. |
Beta Was this translation helpful? Give feedback.
-
|
In option 2, section Flow number 5 you write: |
Beta Was this translation helpful? Give feedback.
-
|
Since the Oracle node needs explicit trust and OTS is not a project we would like to be Alice is a trader trying to get a timestamp (let's say for her profile creation)
Important to notice:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
OpenTimestamps (OTS) in Bisq — Design Analysis
Overview
This document explains:
The goal is not to achieve perfect trustlessness, but to reach a reasonable, auditable, and operationally safe design under real-world constraints.
What OpenTimestamps Is
OpenTimestamps (OTS) is a cryptographic protocol that allows proving that some data existed at or before a certain point in time.
It does this without trusted timestamp authorities and without embedding data directly into the Bitcoin blockchain.
Instead, OTS provides:
OTS answers the question:
How OpenTimestamps Works
1. Hashing
The user hashes some data:
Only the hash is used. The original data is never published.
2. Calendar aggregation
The hash is submitted to one or more OTS calendar servers.
Calendars:
At this stage, the timestamp is incomplete.
3. Bitcoin anchoring
Calendars periodically anchor the Merkle root into Bitcoin using:
OP_RETURN, orThis creates a verifiable link between:
4. Proof upgrade
After the anchoring transaction is confirmed, the timestamp can be upgraded.
The final OTS proof contains:
This allows anyone to verify:
What OTS Does Not Provide
OTS does not provide:
OTS only proves:
Bisq Use Cases for Timestamping
In Bisq, timestamping is primarily needed for:
Important properties:
Bisq Constraints
Network constraints
Client constraints
Operational constraints
These constraints strongly limit how OTS can be used.
Option 1 — Clients Perform OTS Themselves
Flow
Problems
1. Incomplete timestamps
2. Massive request amplification
Thousands of clients performing:
creates:
3. Block verification problem
To verify a timestamp, the client must know:
Without:
there is no independent way to verify this information.
OTS provides only the block hash.
Without validating that this block exists in the Bitcoin blockchain, the timestamp must be considered untrusted data.
4. Hidden trust
Although OTS appears trustless, in practice the client must trust:
This re-introduces implicit trusted third parties.
5. Dependency concerns
During evaluation this already caused issues with transitive dependencies, including incompatible protobuf versions.
We prefer to keep dependencies to a minimum.
6. Development effort
Supporting Tor exit nodes would require integrating the Bisq Tor HTTP client into OTS, which would require modifying upstream library code and maintaining a fork.
Result
Client-side OTS becomes:
Option 2 — Oracle Performs OTS
Flow
Clients receive only:
Advantages
Drawbacks
Trust Implications
The oracle is trusted for:
The oracle is not trusted for:
However, the oracle could:
This introduces explicit trust.
Why Fully Trustless Time Is Not Achievable Here
Given the client constraints:
there is no scalable and secure way for clients to independently verify:
in real time.
Requirements for a Fully Trustless Solution
A fully trustless OTS integration would require:
Avoiding explorer lookups would likely require using the Bisq wallet:
For Electrum, this would result in significant request volume (≈2000 profiles plus future payment account timestamps).
While technically possible, this approach introduces high operational cost and complexity that is not justified by the use case.
Alternative
Use the oracle as a trusted timestamp source, consistent with the existing profile-age model.
Multiple oracle nodes already provide a limited level of protection against abuse.
In the future, additional auditing mechanisms could be introduced, such as:
These mechanisms can be added later without affecting the current protocol design.
Conclusion
Given the constraints and trade-offs, oracle-based timestamping currently provides the best balance between:
under real-world conditions.
This approach keeps the system simple today while preserving the option for stronger auditability in the future.
Beta Was this translation helpful? Give feedback.
All reactions