Proof of Account Age using the blockchain

[ChrisSon15]

Proof of Account Age using the blockchain

For a Proof of Account Age, the account data could be written to the blockchain.
Storing the hash of the Account data to the blockchain would give a proof of its age without a
need for a third party.

How to store in the blockchain

storing as OP_RETURN

Storing as OP_RETURN in a transaction would be very simple, yet it needs more blockspace and
would require more fees. Also, the hash would need to be blinded, so that anybody knowing the
Account Data (e.g., the Bank itself) could not detect the Proof of Age on the blockchain, by
hashing
the data and checking if the hash after OP_RETURN matches.

storing as schnorr adaptor signature

When a Schnorr signature is being constructed, the signature could be created as an adaptor
signature where the adaptor (offset) is the hash of the Account data. That signature could be
used for a transaction and written to the blockchain. For
verification the
creator of the signature could present the offset (the hash of the Accound data and the Account
data) to the verifier plus the adapted signature. The adapted signature could be verified by the
verifier, proving that the hash of the account data was part of the original signature, which
is stored on the blockchain at a specific block height.

This has the advantage of not needing any extra block space. Also, it is more private.
Only the
party to which the hash is being presented knows about the hash.

Where to store in the blockchain

The hash of the account data needs to appear in a transaction, and the height of the transaction
will serve as the age.
For the trades, that wants to proof the existence of the hash on the blockchain, the location of
the
transaction which records that information must be revealed. So the question is in which
transaction should one put the hash information into.

use the first trade

The hash info could be embedded into the transaction where the user makes the first transaction
with that account.
Since he would need to reveal that transaction to do a proof of age, he will need to reveal this
transaction to all trading partners. So his trading partners will not only learn his current
trade (which they are part of) they also will learn his first trade. Obviously, this will not
incur any additional mining fees.

using a separate transaction

Alice could use a transaction which sends funds to herself to embedd the hash information. This
would be unrelated to other transactions, except the normal chain analysis heuristics.
This
would obviously incur some mining fees, but would not reveal info about the first trade.

How to use the proof of Age

When the make creates an offer, he can show the account age even if its nor verified at that
point in time. When the taker takes the offer, he will then validate the proof of age. If the
maker was lying, then the offer fails.

conclusion

The proof of age can be done without a third party by storing some information on the blockchain.
Which has some tradeoff in regard to mining fee and privacy, but gaining full decentralization.

[suddenwhipvapor]

The idea is smart, but I don't like that it could mean adding non-monetary data on the blockchain 😅
It would be a cleaner approach if that OP_RETURN is piggybacked on a real monetary tx, like the first funding tx for the Bisq wallet (however that can be done), and the data, being just a hash string on top of the already necessary tx, would add but a few bytes of weight.

[HenrikJannsen]

Interesting idea, but compared the p2p network based approach I think it has several drawbacks.

We have to distinguish also the 2 features:

• account age (proof of the date when the user created the account - a stolen account scammer cannot backdate or prepare before he has actual access to the account)
• signed account age witness (proof from a trusted seller that he received the fiat)

Drawbacks

The current model would work at account creation not on first trade. Requiring a new tx just for publishing account age would be inferior and comes with privacy costs when user does coin-merge (most will).

For verifying the tx needs to be obtained from the blockchain, adding delay and potential privacy issues (electrum server leans about the requested txs).

The handling of adapter signature would be done on the Rust side, which would make development more complicated. With the current model I can do it quite fast as its all standard stuff we do in Bisq 1 and Bisq 2.

The ownership of the account witness data (the p2p network data) is verified in the trade by the peer with a challenge nonce signed by the owner. Not sure if such would work with the suggested approach as well.

Benefits

The date would be guaranteed by the blockchain.
In the current model, the oracle node would verify that the date is in a tolerance range. This adds trust requirement to the oracle.

In Bisq 1 the user publish the data themself and the nodes receiving the message check for the date and would reject if date is out of tolerance. Though the data received from the seed nodes at initial data requests require trust in the seed node that they have not backdated data.

[HenrikJannsen]

Another point is that we want to allow the Bisq 1 users to import their accounts and account age and witness data to Bisq 2, thus they do not lose those properties. With a new system that would not be possible.

[HenrikJannsen]

Opentimestamps has been explored in the past and might be an option. I will investigate...

[HenrikJannsen]

OTS requires to use the ots client (python), thus it cannot be easily used directly be the desktop clients (no Rest APIs to public calendar services). The oracle nodes would run ots and the user send the request to the oracle.
At that moment the state is pending, thus not safe to use as attestation.

After a long enough time break (3 hours or when online next time) the user makes another request to the oracle for the attestation and the oracle send back the attestation as http response (oracle does not know users onion). The user stores that locally and publish it with a 20 day TTL (user profile has 15 days). The account date is now defined by the block date of the ots tx. If user has been offline longer the data expires and is removed from the network and user once online will republish the data.

Anyone can verify the data by making a request to the oracle and oracle will respond with ots verification result.
This can be done by the trade peer and can be persisted locally at the peer to avoid repeated requests.

Ots client (at oracle) does not learn anything about the trade or account. But it can observe the frequency of time stamp requests (account creation events) and verification requests (trade events). We could make the peer verification randomized after a certain account age. E.g. accounts older then 3 months are only verified with a 50% probability, after 6 months, 25%, after 1 year, 10%...

Any failed verification would lead to publishing of a Nullifier message by the oracle to make a certain account age witness invalid and a user who use that account age witness would be subject to ban.

The Ots calendar servers would only see the frequency of hash inclusions to the merkle tree, thus could learn about the frequency of account creations.

[HenrikJannsen]

Ah there is a java impl. for ots (was used in the past in Bisq).
https://github.com/opentimestamps/java-opentimestamps

This makes the system likely work without oracle.

[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