•   almost 12 years ago

Ability to Tamper?

Okay so I've been looking through documentation, and it seems like the ValueRequestMessage's have the ability to be tampered with...

Ex. A value request message could be sent to a user, but before withdrawing and converting to a ValueMessage, the .setAmount() method could be called to modify the amount being given back to the actual payee.

So, in other words, would you be required to confirm on the payee side that the correct value has been paid? This could make things like paying for stuff at a retailer a much more complicated issue, as the retailer would have to receive confirmation of the requested valuation being returned.


  •   •   almost 12 years ago

    Good point. I'm trying to figure out if the request has to be signed. From what I can tell, it doesn't need to be signed, so I guess it's possible then that the value could be tampered with.

    Perhaps an easy way to solve this problem would be to include an MD5 checksum of the request along with that of the message.

    But this leads to another interesting question. What happens if a payer sends the wrong amount of money? Too much or too little... Does the payee have to refund the incorrect amount, or send another request for more money? In either case the payee cannot ignore the value message since the money has already be debited from the payer's MintChip.

    Just introduces some more implications. :)

  •   •   almost 12 years ago

    The payee *can* ignore the Value message, which is a concern; he or she can back out of the agreement after putting forward the Request, but before relinquishing services/goods/their-side-of-the-bargain. The Value has been created, and at this point the payee could hold the payer "ransom" in a sense -- give me that Value you created for nothing in return, and I'll give you back half.

    Of course, if you still trust the payee to believe that...

    So the lesson learned is: before paying for anything with MintChip, receive your goods first. COD, in a sense. It requires trust in the other direction, but at least the payee might have more (legal) recourse against the payer not paying... a payer stuck with a Value that the payee won't accept doesn't have any legal way to force the payee to take it, but perhaps one day they will.

    It brings up an interesting question with the meaning of "legal tender", and if MintChip Value would be considered thus for purposes of attempts to satisfy an obligation.

  •   •   almost 12 years ago

    Another good point. At least with cash, if the payee refuses my payment (the value), I can at least take the cash back. However, in the case of MintChip, once I generate the value, it now belongs to the payee and there's nothing the payer can do to get it back.

    I think with the bitcoin system, if I remember correctly, if you send a payment, the payee accepts no matter what... but I guess like MintChip, there's no way you can go back once the transaction is done.

    Perhaps the question is, is there any reason for a payee not to collect payment?

  •   •   almost 12 years ago

    At the very least, should the transaction be taken to court, the payer can use the value message as proof of purchase/payment. The only issue then because proving the MintChip ID belongs to the payee.

  •   •   almost 12 years ago

    I would assume the correct response in this situation would be for the payee to accept the payment, then issue a refund payment to the original payer? That's the best option I can think of.

    The good thing about MintChip is that it works offline. However, the bad thing about MintChip is that it works offline. :P

  •   •   almost 12 years ago

    @DanielN Yes, that's the correct response if the payee has integrity. These ideas came from the dregs of my brain, thinking of the worst that can happen...

    @BrianJ Sure, that's proof of the target of the Value, but if the payee decided to (be a jerk and) reneg on the transaction, there's nothing to be taken to court -- the payee said, "y'know, I decided I didn't want to sell you this rare bottlecap after all" and never took money for it; the payer is out of luck if the payee doesn't do as @DanielN suggested, because he's out his $X and has a useless Value message.

    @BrianJ The worst of me says, "because people are people", and there will always be some situation where the Value message has been generated and the payee decides not to accept it -- not only because he/she has decided not to complete the transaction for the initial goods/services, but also because, for whatever reason, doesn't want to cash it and transfer it right back as a good MintChip citizen.

    It may be farfetched, it may be rare, and it may be cruel, but the possibility exists, and because it's not illegal to leave someone hanging with a useless Value message, the risk is on the payer. The nature of transactions should thus be considered for those of us developing MintChip apps - make sure that the payer is aware of risks, has taken possession of their good/service (if any), and only then create their Value message.

  •   •   almost 12 years ago

    First, I am not a lawyer. Second, the following is based on my own, personal, reading of the Currency Act and should not be taken as legal advice of any kind.

    Refusing a MintChip value message destroys it, so it is probably equal to burning or melting currency, which is a criminal offence carrying a penalty of 12 months in jail, in addition to whatever you get for defrauding the payee, or for breach of contract. The Crown can also seize the means by which the currency was destroyed.

    The legal precedent would have to be established unless the legislation was explicitly updated, but because MintChip is created by the Royal Canadian Mint, I doubt this kind of "coin" would be treated differently.

  •   •   almost 12 years ago

    @WayneP I disagree with you when you say there's nothing that can be taken to court. I'm almost certain the value file could be proof a payment. It contains the amount, the payee, and is even signed by the unique certificate of the payer which would be impossible to fabricate. At the very least, I think the payee would be obligated to issue a refund value message, as prior to the transfer of funds, some kind of contract would have been negotiated. But you're right to say that all of these gets a bit messy, and probably a little more messy than cash. But who pays a contractor in cash? And I suspect that Ebay is not a place we'd be using MintChip as we'd want the protection of PayPal. But if I'm buying a can of pop, I'd probably use MintChip since I know the product is 99% likely to be delivered to me.

    But I was thinking about this last night, and I could see MintChip being vulnerable to the Newspaper vending machine problem. Have you ever had a coin get stuck in a newspaper vending machine, and then lose your coin? I could see a similar thing happening with MintChip, where for whatever reason, a bug, the vending machine ignores your value message. On a positive note, unlike cash you have proof you paid the vending machine. Which could be shown to customer service who could fix the issue.

    I guess the thing to keep in mind with MintChip is that you should always keep your value files for future reference, both the payer and the payee. I believe the MintChip does have built in logging functions to do this, but keeping them for auditing and accounting purposes would be a good idea.

  •   •   almost 12 years ago

    I guess I should quickly clarify, who pays a contractor with coins. :)

  •   •   almost 12 years ago

    Interesting take on it...

    Refusing a MintChip Value message doesn't "destroy" it; being just data, it can be copied and duplicated, so the idea that you've destroyed it doesn't match with the idea of destroying physical currency.

    In that same vein, while the RCM issues the MintChip devices, saying that they issue the Value messages is a bit of a stretch for purposes of destroying something they've created.

    I think this is the right idea, though, for protecting Value messages; if the concept of "destroying" currency is extended to the refusal of a Value message (and thus making it nearly as useless as destroyed currency) then such hijinks aren't going to happen.

Comments are closed.