I suggest you to specify data types in language independent way, not types from sigma-rust implementation

I suggest you to specify data types in language independent way, not types from sigma-rust implementation

We do specify the types in language-independant JSON. This was intended to mirror what sigma-rust had at the time for ease of interopability, but they are specified at the bottom of the document.

I made some minor changes based on issues encountered during our initial implementation inside of Yoroi:

Type definitions are specified using flow types now instead of some
pseudo JS schema.

API errors are added to all API calls to handle things that can go wrong
for any call,e.g. internal error in the wallet, incorrect params
specified to API calls.

get_change_address() was added as an explicit API since it should be
easy to support and allows for an easier way during tx creation rather
than arbitrarily choosing an address from the used or unused API calls,
which aren't guaranteed to be non-empty.

add_external_box() was removed as we are still unsure how any wallets
would be able to implement it in any meaningful way. This could be
reversed and have most wallets treat it as a no-op.

We removedBoxCandidate in favor of justBox to make things simpler. It also allows interop with sigma-rust/full nodes for now.

It would be ideal to not reference sigma-rust in any way for things that are more specific than just the underlying javascript type for example:

Uses `sigma-rust` rep - Hex-encoded bytes for `SigmaSerialize` of a constant.

which specify things like encoding, length, etc.

BoxCandidate was restored as it was only removed to ease support with sigma-rust/for simplicity, but the additional information was never necessary. Now that the data model was updated in sigma-rust it makes more sense to revert that change to the originalBoxCandidate model and remove tx IDs from the unsignedTx which makes it potentially easier to construct by the dApp.

Full box contents are now included inUnsignedTransaction to help light wallets support P2S inputs + for all wallets in processing recently created outputs. Wallets can check that the content matches the ID so there should be no security issues with that.

We're currently also developing a similar spec to this for Cardanohere. There has been a lot of discussion there, some of which is relevant to Ergo. Here are some things that we might want to cover here too:

• Handling multiple wallets installed (for Cardano we solve this by injecting into a namespaced object - for Ethereum they just tell you to only have one installed e.g. MetaMask)
• Versioning (i.e. if this spec gets updated and some API changes)
• Phishing prevention (this could be assumed to be a wallet implementation detail, e.g. showing some user-known secret image in connector popups to stop phishing sites from creating similar looking popups to a user's wallet to farm passwords or other info)