Proof of Account Age

[HenrikJannsen]

Proof of Account Age

This mechanism is similar to the Bisq 1 account-age feature but introduces several improvements.
In Bisq 1, account-age data grows indefinitely and is currently around 10 MB.
Additionally, it requires trusting seed nodes not to inject fake account-age entries with back-dated timestamps.

The scaling issue is resolved by utilizing the oracle nodes. The trust issue is moved from the seed nodes to the oracle nodes which is slightly better as oracle nodes are enforced bonded roles.

Overview

When creating a fiat payment account, the user sends a request to the oracle nodes.

Publish Account-Age Request

The request contains:

• Current date
• Blinded account hash

Blinded Account Hash

The blinded account hash is derived from identifying payment-account data (e.g., IBAN, name), the same approach used in Bisq 1.
The version field allows modifying the hash composition in future updates.

The hash is combined with a payment-account-specific secret that is stored locally by the user.
The blinded account hash = hash(payment-account data + secret).

The secret ensures that anyone who knows the raw payment-account data cannot link it to a specific blinded hash.
The secret is only revealed to the trade peer during the trade.

Proof of Account Age

The Proof of Account Age consists of:

• Account-creation date
• Blinded account hash

The oracle verifies that the submitted date in the request is within a defined tolerance window (+/- 2 hours).
If the date is in the future, the UI treats it as age 0 instead of a negative value.

The oracle publishes the Proof of Account Age as authorized data with a TTL of 20 days. It should be longer than the TTL used for the user profiles which is 15 days.
This prevents unbounded growth of account-age data by removing entries from inactive users.

The oracle persists all Proof-of-Account-Age data locally and can restore and republish it upon user request.

If multiple proofs exist for the same blinded hash, any proof with a newer timestamp is ignored.

Republishing

The orcale node republished the Proof of Account Age data of active users before it expired.
When an inactive user becomes active again, they send a republish request to the oracle containing their locally persisted Proof-of-Account-Age data.

Using Proof of Account Age

A maker may include their account age in an offer.
Since an offer can specify multiple payment methods/accounts, account-age information is part of the detailed offer data and shown to the taker when accepting the offer.

For buy offers, the account with the youngest age determines the maximum trade amount.
For sell offers, the maker may require the taker to meet a minimum account age, or account age may be used directly in trade-limit calculations.

During the trade, the seller verifies the buyer’s account age by receiving the buyer’s secret and recomputing the blinded hash. If buyer would have lied about their account age the trade fails.

Impact on Trade Limits and Fraud Protection

The precise usage within trade-limit rules and the fraud-prevention system is outside the scope of this document and will be specified in follow-up documents.
Additional adjustments may be required.

Note: This is an AI generated summary

[suddenwhipvapor]

Sounds solid to me as a proof of age in and of itself, and also doesn't let the trade peer know anything more that he would end up knowing for participating in the same trade.
I would think that a malicious user could farm this data point across multiple instances, but yes, how this can be counteracted or even be a real issue or not, is a different topic.

[HenrikJannsen]

a malicious user could farm this

Yes, but only if he has access/knowledge of the accounts in advance. As focus is on stolen bank account scams, for that case it is unlikely that the scammer is willing to wait out the period after he gets access to the account as with every day there is risk that the fraud gets detected. It is reasonable to assume they prefer to try to cash out as soon as possible and the account age system will be a hindrance for that.

[ChrisSon15]

Sounds to me like that would work out. May be it could be simplified:

Since the trader needs to present the secret for the blinded hash, he could instead present the complete hash with a signature from the oracle. In this model we have a trusted oracle. So the oracle could have a service to sign account data for traders. The trader could the present the other trader with that signature (are the original data). The second trader would need one or several trusted certificates hard coded in the client. Then he could verify the account data age without the oracles storing the data locally and without the blinded hashes being send around as authorized data.

Please also see this idea.

[HenrikJannsen]

I started to integrate ots at https://github.com/HenrikJannsen/bisq2/tree/add-open-timestamp but came to the conclusion that its not a feasible solution. See: #4325

[HenrikJannsen]

Not sure if I understand your suggestion...

the oracle could have a service to sign account data for traders

the trader does not want to send account data to the oracle. Only the hash. The secret is only exchanges with the trade peer enabling him to verify that the oracle signed hash is matching the peers provided account data + secret.

If I missed your point, maybe you can describe it more in detail.

[HenrikJannsen]

This is implemented now with import from bisq 1 accounts.