search

openwallet-foundation / architecture-sig

This special interest group (SIG) is focused on conversations related to the architecture of digital wallet engines and is a sub-group reporting to the OpenWallet Foundation's Technical Advisory Committee.
Creative Commons Attribution 4.0 International
42 stars 16 forks source link

Create crypto-currencies.md #35

Closed OR13 closed 1 year ago

OR13 commented 1 year ago

Screen Shot 2022-10-14 at 5 15 18 PM

hboon commented 1 year ago

Users could also sign a message with the key and not a transaction; but maybe this is covered in a separate diagram? This is useful for proving that the user owns the key (and hence the wallet address) or authorisation (provide permission for X, commits).

OR13 commented 1 year ago

Users could also sign a message with the key and not a transaction;

I think you are asking for rawSign support ?

But at the "digital object" layer, not the KMS layer?

hboon commented 1 year ago

I'm sorry for replying really late; was on vacation.

I'm not sure about the distinction between digital objects vs KMS layer, but I'm looking at the Account entity/box and see:

+createTransaction(Currency currency, String amount, Address recipient) Transaction

It looks to me that if "something" (in this case an Account) can sign a transaction for cryptocurrency, it ought to be able to rawSign with the same key. Transactions are technically a more specific form of rawSign with some headers or additional bytes, though they are treated as different types.

Also in the same type definition:

+createTransaction(Currency currency, String amount, Address recipient) Transaction

This seems to assume a single fungible currency (eg. BTC or ETH) but transactions in some blockchains (EVM-based for example) can have arbitary tokens, multiple tokens, just raw bytes, or a combination of them. Example a transaction that swaps 1 token for another would at least include at the source and destination tokens, 1 or 2 numbers for the amounts.

I might not have the full context, so excuse me if it's out of scope for the PR, or doc.

OR13 commented 1 year ago

I'm going to merge what we have, so its easier to focus the next PR on the next step... I suggest you do a PR to the diagram after this is merged so we can discuss on a smaller change set.