Jump to content
JoelKatz

Suggestion: Checks

Recommended Posts

David,

I think that would be an awesome feature. What if checks were taken further to also include recipient validation? Each "check" payment could include a shared secret that only the sender and intended recipient would know (offline communication somehow). This would ensure 1. The recipient actually wants the money and 2. The wallet's address is actually the one you intended to send the money to.

This might help ease the minds of certain senders who are moving large amounts of money and scared they mistyped an address for instance.

Share this post


Link to post
Share on other sites

The "Checks" amendment, as designed and implemented, handles receipt validation fairly elegantly already. The sender has to sign a transaction to send the Check, and the address already has the checksum built into the address, so simple typos probably couldn't result in the money going to a valid address. (Copy-paste mistakes are a different problem that's harder to solve, of course...) And the recipient has to send a transaction to receive the Check, so the recipient can't actually get the money unless they cryptographically sign a transaction specifically trying to do so.

Share this post


Link to post
Share on other sites

@mDuo13Thanks, yeah I understand that it handles receipt validation elegantly from a cryptography standpoint. I was just trying to highlight a UX and sociological issue regarding the transferring of larger sums of money with irreversible payments paired with the UX of public addresses and QR codes. If you're already adding/modifying a feature that defers payment until the receiver actively accepts it, why not add an optional feature that could ensure the receiver was the intended receiver in the first place?

When scanning QR codes, pasting public addresses, or programmatically sending money, sometimes I don't like trusting myself. I make mistakes all the time with non-monetary aspects of my life. Sometimes I'm tired or sick. If I can make it a little harder for myself to goof up a transaction that is significant for me, then I'd do it.

If I’m sending 5 USD to someone, I would agree that it’s probably not worth my time and I could send a regular payment. If it's $100, maybe a regular payment or accepted "check" would do. But if I’m sending a $50k “check”, why not make it less likely for me to shoot myself in the foot? 

My naive thought on implementation would be something like this:

// Alice wants to send a secure "check" to Bob over the XRPL

// Step 1: Alice shares a pre-shared key with Bob "password123" in some unknown secure fashion (offline)

// Step 2: Alice sends the check to Bob

// XRP: CheckCreate
{
  "id": "sign_req_1",
  "command": "sign",
  "tx_json": {
    "TransactionType": "CheckCreate",
    "Account": "rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za",
    "Destination": "rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
    "SendMax": "100000000",
    "InvoiceID": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
    "DestinationTag": 1,
    "Fee": "12",
    
    "CheckPassword": "password123"
  },
   "secret" : "s████████████████████████████"
}

// Step 3: A rippled server hashes the CheckPassword with a randomly generated salt and returns both

{
  "id": "submit_req_1",
  "result": {
    "engine_result": "terQUEUED",
    "engine_result_code": -89,
    "engine_result_message": "Held until escalated fee drops.",
    "tx_blob": "r405950959",
    "tx_json": {
      "Account": "rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za",
      
      "CheckPasswordHash": "d1d3ec2e6f20fd420d50e2642992841d8338a314b8ea157c9e18477aaef226ab",
      "CheckPasswordSalt": "bv5PehSMfV11Cd",

      
      "Destination": "rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis",
      "DestinationTag": 1,
      "Fee": "12",
      "Flags": 2147483648,
      "InvoiceID": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
      "SendMax": "100000000",
      "Sequence": 4,
      "SigningPubKey": "03B6FCD7FAC4F665FE92415DD6E8450AD90F7D6B3D45A6CFCF2E359045FF4BB400",
      "TransactionType": "CheckCreate",
      "TxnSignature": "3044022071A341F911A8EF3B68399487CAF5BA3B59C6FE476B626698AEF044B8183721BC0220166053A859BD907251DFCCF34DD71202180EBABAE7098BB5903D16EBFC993C40",
      "hash": "09D992D4C89E2A24D4BA9BB57ED81C7003815940F39B7C87ADBF2E49034380BB"
    }
  },
  "status": "success",
  "type": "response"
}

// Step 4: Bob then cashes the check

// XRP: CheckCash
{
  "Account": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
  "TransactionType": "CheckCash",
  "Amount": "100000000",
  "CheckID": "838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334",
  "Fee": "12",
  
  "CheckPassword": "password123"
}

// Step 5: If the password Bob sends can be hashed with the public salt and matches, then the funds are released, otherwise the check gets canceled.


Now even if Alice sent the check to Charlie's address, Charlie couldn't do anything with it. Alice and Bob would realize the transaction went to the wrong address and Alice could cancel it. I'm not sure if it's technologically possible or not, but I would use something like this.

Edited by ChrisMartinez

Share this post


Link to post
Share on other sites

You can always restrict yourself arbitrarily on top of an unrestricted network, it is harder the other way around. I don't think that adding passwords would make Checks safer - if anything, they make it more likely that the money stays locked indefinitely.

I however would like to see Checks being feature-equivalent to Escrow, so maybe a SHA256preimage might be worth including? Anyways, Checks are already in the code (including a purely Checks related Amendment already being enabled on Livenet!) and should be enabled to iterate upon their features in the future instead of having yet another discussion in my opinion.

Share this post


Link to post
Share on other sites

@Sukrim My understanding of checks from the documentation is that they don't put funds on hold: https://xrpl.org/checks.html

So no money would stay locked indefinitely. Even if checks did lock the funds, the sender and receiver would be able cancel the check without my suggested password. The suggested password I mentioned would only be used when the sender calls CheckCreate and the receiver calls CheckCash

In the aforementioned example, If I'm Alice, I want to be able to cancel the check regardless of whether I remember the arbitrary password I sent. I also don't care if Charlie cancels the check I sent to him by mistake. What I really care about is if Charlie cashes the check that I meant for Bob.

Anyway, wont beat a dead horse. Just my 2 cents.

Looks like Escrow operates like this already with the condition and fulfillment fields: 

https://xrpl.org/escrowfinish.html

https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1

 

Edited by ChrisMartinez

Share this post


Link to post
Share on other sites

So after reading:

https://xrpl.org/send-a-conditionally-held-escrow.html

It seems like that is very close to what I was thinking of. If CheckCreate could use a condition field and CheckCash would accept a condition and fulfillment field, the fulfillment string could be shared with the intended receiver offline and thus ensure the sender that even if they sent the check to the wrong address, it couldn't be cashed unless the receiver had the fulfillment string.

Would that work?

Edited by ChrisMartinez

Share this post


Link to post
Share on other sites
5 hours ago, ChrisMartinez said:

So after reading:

https://xrpl.org/send-a-conditionally-held-escrow.html

It seems like that is very close to what I was thinking of. If CheckCreate could use a condition field and CheckCash would accept a condition and fulfillment field, the fulfillment string could be shared with the intended receiver offline and thus ensure the sender that even if they sent the check to the wrong address, it couldn't be cashed unless the receiver had the fulfillment string.

Would that work?

Yes, you've basically been describing Escrow all along.

Of course, the XRPL's Escrow feature currently only works with XRP because you can make much stronger guarantees with a native digital asset than you can for an issued currency, and the details around how you would actually set aside balances of an issued currency (move it out of the trust line??) are a little more complicated. Not that Escrow couldn't theoretically support issued currencies, but there are some details that would have to be worked out and caveats that would have to be accepted first. In fact, I'd love it if someone put out a standards draft for issued currency escrow. If it were comparable to the one for Deletable Accounts then it could probably get implemented without much trouble.

Share this post


Link to post
Share on other sites

Yes, I was basically describing the same crypto-condition feature of escrow, but without the locking of funds. Also, it looks like Checks can only be cashed by the receiver whereas Escrows can be finished by any account.

The fact that only the mistaken destination can call CheckCash is the reason why the crypto-condition would have value for the use case I'm describing. You wouldn't want Alice (actual sender) or Bob (intended receiver) to have the ability of calling CheckCash with the fulfillment string while not realizing the check was going to Charlie (mistaken receiver).  

Edited by ChrisMartinez

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...