And stealt addresses are comming:)
Great addition layer for anon but ....
If I pay someone anon. And not even the chain shows the coin's received how do you settle discussions between buyer and sender? What if that "whatever" seller claims they never received my payment?
Simply speaking, you can't verify anything with 100% anonymity.
This makes sense though. I mean, if you want to verify something (trustlessly) then you have to make information public. If it's public it's not anonymous.
My guess is that single-use publicly known addresses are the sorts of things that retailers will need to use. Stealth addresses are no good for both seller and buyer, since there's (generally) a mutual interest in payment confirmation or tracking.
Ultimately the flexibility that XC will offer with its privacy solution will be something like:
- separate control over disclosing amounts and addresses
- either amounts or addresses (or both) can be made public, private, or known only to sender and receiver.
This way we'll be able to provide appropriate solutions to any given use-case.
Makes perfect sense to me. Otherwise it's monkey logic - how to make the impossible possible because everything is possible or the more popular interpretation:
http://en.wikipedia.org/wiki/Chicken_or_the_egg.
Indeed.
Let's sketch a scenario here:
- I want to pay someone
- I don't want to publicly reveal my address
- I don't want to publicly reveal the amount paid
- I will need to prove to the recipient that the amount has been paid
- If the product/service I'm paying for is not delivered I want the option of using this proof of payment to demand a refund or otherwise seek redress.
- The recipient does not want to disclose his/her address
- The recipient does not want to disclose the amount received
- The recipient needs proof of payment before providing the product/service
Solution:
- Sender uses multipath to conceal the amount paid
- Sender uses trustless mixing to conceal the address paid from
- Sender sends to a single-use address that (s)he is in control of
- Recipient provides a publicised address but will receive payment on a stealth address, thus concealing the address received on
- Sender then makes a public payment to the recipient's publicised address that is recorded on the blockchain as successfully sent
- In the event of a dispute, the sender can sign a message proving to be the owner of the public key associated with that address. This involves disclosing - at least to the recipient and possibly also publicly or to a mediator - the address and the amount. As such, users will be discouraged from engaging in illicit transactions due to inability to dispute publicly should products or services not be delivered.
So that'll work pretty well - and I haven't even need to use XChat, which would come in handy for other scenarios.
Secondly, when XC starts on smart contracts there'll be an additional tool at our disposal: escrow service nodes (which earn fees for forwarding/arbitrating multisig transactions). Now that'll be powerful. There'll be no conceivable situation we can't engineer optimally.
