The last time I was looking into paying taxes it seemed that all the available solutions involved pointing the software at the assorted sources of the information needed, (e.g. to the crypto ledger via your address, your exchange accounts, etc) rather than getting all of that information from a standardized wallet source. This doesn't mean there are no wallet solutions, but at least they weren't widely adopted enough that the accounting solutions relied on them.
Perhaps it would be better to design a crypto-agnostic solution, creating a standardized format that can be used by all other cryptocurrency wallets and accounting software.
Well I think it should be pretty easy to distinguish which of these fields are general to currencies and which are specific to nano. Any conflicts would arise with the overall structure: are there cryptocurrenceis which can't be organized by account + transaction? Otherwise, you could have a field at the "account" level which identifies which cryptocurrency the account belongs to. The standard would then have a set of required fields (the general ones) and each cryptocurrency could then have a set of additional fields that make sense in the context of their own protocol.
Things that would probably be general:
- crypto protocol
- private name
- public name
- accounting unit
Things that would not be general:
Things that I'm not sure of:
- time published
- time confirmed
I would think these two are general, as long as the cryptocurrency has a reasonably identifiable confirmation point (e.g. bitcoin reaching N blocks deep).
Provide a way for additional data fields to be defined (either custom metadata from the wallet, or crypto-specific parameters)
I'm not sure this even needs to be defined. Anyone adopting this format could add their own fields, and any software reading the format could just skip fields that it doesn't understand.
Personally I don't feel this would provide much of a purpose to the handoff protocol — that requires its own set of parameters and is for dealing with the processing of blocks, whereas the standard you propose seems to be aimed at storing and transferring historical data of already existing blocks
Ideally all of these fields would be populated at the time of transaction, rather than after the fact, and some of them would ideally be populated by the opposing party. In practice I would expect that the transaction process would simply involve the exchange of a generic "metadata" chunk that contains an assortment of fields like this from each party. The wallet of the other party can then choose which metadata fields it cares to integrate into its own records of the transaction. Sort of like "throwing it at the wall and seeing what sticks." For instance, the merchant might store the "transactee" field from the customer. The customer might store the "memo" and "transactee" fields from the the merchant, and if their "accounting_unit" matches your own you would store their "value" field because the merchant is likely the one defining the exchange rate of the transaction.
- Personally I'm not so sure about the inclusion of the fiat currency - exchange rates can differ between sources, and different apps may expect or support different currencies. Perhaps including the crypto amount would be better, instead allowing the wallet/accounting software to make the conversions?
The crypto amount could be included. It would be redundant since it could be read from the ledger, but there's no strong reason not to have the field and it would make it easier for accounting software to just read this value rather than interact with the network. If the amounts disagree it might be cause for further error checking.
But the fiat currency should be included, because there's no other good place to store this information. In principle two parties could agree to make an exchange where the Nano is valued drastically differently from the current market price, and you would need to record that. Not everyone has to use this field, but if they do use it this is the logical place to have it. Eventually of course we would hope that people are accounting in nano and this field becomes obsolete.
I feel I'm misunderstanding how people are suggesting this could be integrated into the handoff protocol, so if you could help clarify it for me (or provide any other suggestions) I'd greatly appreciate it.
I might have answered this question earlier in this reply. Basically at some point during the transaction communication they simply trade a chunk of metadata that they populate with their own info, and let the other do with it what they will. For a merchant it might make sense to include their chunk in the payment request, which lets the customer wallet display all of this information while they authorize the tx. The customer they could include their chunk it when they hand off the block, since they are already sending data at this step.