WOTS-Ed25 Wallet Transition Requirements

[cvarley100]

Description

In the new wallet users will transition their funds from WOTS addresses to Ed25519 addresses. Ed25519 will be the default signature scheme in the new wallet. One important part of this transition involves recovering funds that sit on spent addresses. Before transitioning a user's funds from WOTS to Ed25519, we check for funds on spent addresses and execute an optional process we call "Spent Address Recovery". Spent Address Recovery seeks to generate signatures that reveal as minimal additional private key fragments such that an attacker cannot realistically brute force signatures and steal the funds before they confirm. To execute Spent Address Recovery we need the signatures of the previous spend(s), and therefore will need to rely on a permanode.

One important consideration is how to handle historical data (pre-Chrysalis) as the transaction structure is changing (see iotaledger/tips#17 and iotaledger/tips#18). It seems there are two options: either 1. Maintain legacy APIs and legacy transaction structure for any pre-Chrysalis data, or 2. Transition all pre-Chrysalis transactions/bundles to the new transaction/message scheme. Option 2 may prove infeasible with Chrysalis' deprecation of bundles, but it might be worth exploring for the sake of cohesion.

Motivation

We need historical transactions/signatures to allow users to safely transition from WOTS to Ed25. Requiring the user to enter signatures manually is too great a friction point for UX. The only option is to request them from a Permanode.

Requirements

1. Store historical data as far back as possible (preferably to 2018).
2. IF to host (a) scalable permanode(s).
3. Transactions from before Chrysalis need to be handled appropriately.

Open questions

• How should historical data (pre Chrysalis) be stored on the permanode?
• Can we add historical data further back than the April 2019 (current earliest)?

Are you planning to do it yourself in a pull request?

No.

[louaykamel]

In permanode the historical data is stored inside Scylla keyspace which reflects the network name(mainnet, devnet, comnet, etc), therefore the two options which you described above are possible, I would prefer the second one but also depends on legacy API to query the Signatures.

[cvarley100]

Hornet will remove the spent address list with Chrysalis part II. So we also need Chronicle to store spent addresses in the legacy API.

[louaykamel]

@cvarley100 What is the required lookup API for spent-addresses?

[cvarley100]

Something like:

isAddressSpent

Parameters
Name	Required	Type	Description
address	✔	array	Addresses for which to check spend status.
Returns
Name	Type	Description
spendStatus	array	Address spend statuses.

[louaykamel]

Update on your requirements:

Store historical data as far back as possible (preferably to 2018).

Our permanode already hold the data all the way back to 2017, but there might be some gaps in the earliest dump files.

IF to host (a) scalable permanode(s).

Already hosted

Transactions from before Chrysalis need to be handled appropriately.

Permanode doesn't differentiate between pre-chrysalis and chrysalis-pt-1 data, because the transaction layout doesn't change, but this should change for any data after chrysalis-pt-2.

Answers to your open questions:

How should historical data (pre Chrysalis) be stored on the permanode?

Chrysalis-pt-2 will require us to adapt a new data model, to simplify the implementation we will keep the data pre-chrysalis-pt-2 in mainnet keyspace using the current data-model, and we will have chrysalis keyspace for all the data after chrysalis-pt-2, therefore permanode will be able to satisfy everything.

Can we add historical data further back than the April 2019 (current earliest)?

Yes, and I also plan to resolidify everything we currently have and hopefully identify any gap in the earliest data we have and most importantly if we could fetch them from somewhere.

[louaykamel]

chrysalis-pt-2 support landed and our chronicle is already in production, please feel free to reopen if needed.