Transactions

[cakesoft-priyanka]

Description:

Epic Link: https://github.com/bithyve/internal-docs/issues/76

1. In the current scenario there is a hierarchical structure where every account has sub-accounts which is time consuming.
2. In the new scenario every account will have only one xPub and one set of transactions. There will be no sub-accounts.
3. This will be achieved by implementing the following:
   • For F&F channels there will be no new xPubs. Instead of having separate sub-accounts of their own, use addresses from the checking account by default. They will not have separate F&F account. (User can create a F&F account if they want. And then the addresses you place in the channel will be from F&F but it won’t matter to the other party as they don’t know/ care. Later when we have Liquid or other assets we will place more addresses based on the asset and depending on what the user is sending, the correct address is picked up from the channel - refer #3523)
   • Buy feature by default will also use addresses from checking account unless user creates new accounts. There will be no separate xPubs. - refer #3524
4. A lookup table will be associated with every account. Persist transaction properties in that lookup table. Addresses will be placed on a common channel and when a friend accepts it the lookup table will keep a track of which address is given to whom. If the user sends a new address to the contact then the old address will be replaced with the new address and transactions will take place in & out of that address only. This will help the user to view the names of the people(to/from) instead of addresses in the transaction details page. Transaction list will contain transaction type and To/From address/person name, type(F&F, Ramp). Same case will apply for buy feature where the look up table will track from which platform the bitcoins were bought.
5. Transaction details page will have the following properties:
   • Account name
   • Date
   • Amount
   • From/To Address and From / To entities - if the transaction is to/from a contact then display contact name for this. Incase of non-F&F transaction display address. In outgoing transactions "From" will be from an account and "To" will be to a Service like FastBitcoins, Contact, Address or Another Account. In Incoming, it will be vice versa.
   • Fees
   • Transaction Id / The Transaction ID is also an external link and it opens a webpage to check for the transaction. This should be clear on the screen
   • Confirmations / Whether it is pending or confirmed. The number of confirmations is not important and can be inside the details section. It is very important to differentiate between Pending and Confirmed from the user point of view.
   • Transaction Type
   • Tags: For eg. NEW tag for a newly triggered transaction
6. Transaction types will be F&F outbound/F&F inbound, Internal account transfer, Exchange transfer(Buy), Exchange Transfer(Sell)- These transaction types can be used in the backend if needed

Transaction Tagging:

Flow:

1. The user can see the details of the transaction including its account, source and privacy tag
2. They can also see the user defined tags but can also:
   • associate new tags (from what already exist)
   • create new tags (and associate them to the txn)
   • delete a tag
3. A maximum of 5 unique tags are allowed. Tags cannot be repeated
4. A user can also tag transactions when receiving. When receiving from an account, the account tag, source tag and privacy tag of the xPub is shown. If the privacy tag is Public, it can be changed to Private or Peer. More user tags can be added by the user. This is shown on the receive address screen. Txn type tag is associated accordingly.
5. A user can tag outgoing transactions when sending. This will also tag any incoming change transaction. When sending from a particular account, the least private tag of the UTXOs used is used as privacy tag. The user can change the privacy tag to less private tag (e.g. from peer to public). The source tag is the tag of the xPub used to generate change address. Txn type tag is associated accordingly.
6. Adding/ changing tags while send and receive is optional and not something which the user may want to do every time. The order of tags from least private to most private is: Public, Unknown, Peer and Private.
7. All output transactions show the change transactions within the details as coming in.
8. All transaction details screen have an option of 'Send UTXO' (Send coins from this Transaction)', this takes the user to the send screen but will allow only one recipient and will send the whole UTXO to the recipient (minus the fee) When the user is looking at the latest transactions, they can decide to 'View All'. This will take the user to a separate screen where the user can: a. Search transactions based on tags, period (date to and from), from, to and amount b. They can select one or multiple transactions c. Once selected they can: Send those UTXOs together

Specs Link:

https://xd.adobe.com/view/e917b3eb-4927-4cc9-a973-f60a0c1dc69b-bc44/

[cakesoft-priyanka]

@summikhan11 Please provide an updated UX page link for this Accounts page with transaction list and transaction details page: Transaction details page will have the following properties:

• Account name
• Date
• Amount
• From/To Address: if the transaction is to/from a contact then display contact name for this. Incase of non-F&F transaction display address.
• Fees
• Transaction Id
• Confirmations
• Transaction Type
• Tags: For eg. NEW tag for a newly triggered transaction

[antuz123]

@AliMeer - pls see what UI changes is needed in this for Rohit to do

[summikhan11]

Specs Link: https://xd.adobe.com/view/e917b3eb-4927-4cc9-a973-f60a0c1dc69b-bc44/

[antuz123]

@summikhan11 - can't see the new tag for transactions

[antuz123]

@cakesoft-rohit - check throughout what of this is remaining from a UI and functional perspective

[antuz123]

1. Active addresses to maintain an entity mapping/ pair (like F&F, Account or Service). So Active addresses will have a type - General or the above three. @Parsh 1.1 AA list to be backed up as a pair array @cakesoft-shashank
2. Once a txn is received on any of these addresses, the paired entity and type is copied to the txn table. @cakesoft-shashank
3. For Send flow, when an Account or F&F or Service is chosen it gets directly into the Txn list.
4. Non- PMDD items (that can't be got from node) to be backed up for TxNs - Send/ Receive, type (F&F, Exchange, general), tags (multiple), note, Receiver (if F&F or Exchange then the internal ID or name), Sender (if F&F or Exchange then the internal ID or name), TXN ID @cakesoft-shashank

[antuz123]

UI changes:

1. Dot on accounts when new transaction on smart sync
2. New tag or red dot on transactions which is new for that session @summikhan11
3. Show Sender in received transaction (if sender present)
4. Show Receiver in sent transaction (if receiver present)
5. Dot and new tag goes away when the account is opened

[summikhan11]

https://xd.adobe.com/view/69730b23-793e-4df6-b663-0c680f65329d-3c20/screen/70c49583-217d-4542-9c47-fb2073193307

[cakesoft-swati]

• Verified this issue on dev app v1.9.5(330) also discussed with dev.