This explains the blackbytes workflow but doesn't seem to answer CryptKeeper's question ...
Sorry, got totally consumed by describing the chat workflow
(which is equally good for bytes BTW).
I might add the display of the sender's addresses in a future version, just for completeness, but be warned that it won't tell you who is the real person behind these addresses.
I am not interested in who got the fees, I just want to know if some user got them or if they were burned ... I mean if someone was the first to reference my transaction as parent and/or is a witness then they should've gotten the fees, just wanted to make sure of that.
They can't be burned, somebody definitely gets them after the transaction is confirmed.
The wallet is designed for unsophisticated users (GUI was borrowed from Copay, the most easy to use bitcoin wallet) and we generally avoid displaying information that bears little meaning to regular user.
Having both is having complexity again, something I avoid by all means throughout this project.
I'm not against accommodating
regular users, I just think that this
simplicity may annoy less regular users. As far as I'm concerned, even if the info may have little meaning, being able to display it and choosing not to is not the same as not being able to display it.
There is a lot of information that is available but I chose not to display. The choice was dictated by the desire to keep the UI as clean and uncluttered as possible. This is weighted against the usefulness of information, while keeping in mind a regular user. I understand the choices may not be optimized for every user, and if you want to design a wallet for pro users, fork it and release your own.
Can you elaborate a bit on the complexity that signing a message instead of making a payment may introduce? (I'm not taking about the complexity of signing a message per se, I'm talking about how this will make the distribution process more complex.)
Accepting claims as signed messages
alone is not complex technically but there are serious issues on the usability side:
1. First of all, not every wallet has this function.
2. Even in wallets that can do it, it is a rarely used function, users need to be instructed how to use it for every brand of wallet, and they feel insecure when they do something for the first time.
Having both options adds complexity on both technical and usability sides:
1. More code that needs to be written, debugged, and tested. Despite all the testing, more code is always more complexity and greater probability of errors, including security errors. Complexity is the enemy of security.
2. More options for users means more options for attackers too. This needs to be analyzed, and with growing complexity the chances of missing something increase.
3. Longer instructions for users. They are scared off by the abundance of text or unfamiliar words, like "signing a message".
4. Users have to evaluate both options and make their choices. Choice is difficult when the difference between the choices is not immediately clear.
All this is fine as long as there is a real tangible benefit in adding more options that overweights the negatives. In this particular case, there isn't.