Suggestion: Checks

[JoelKatz]

Most public ledgers provide no way to refuse an unwanted incoming payment. While most people would be perfectly happy to receive an unexpected, possibly misdirected, payment, it can create a real problem for some users. Regulatory requirements may make returning the payment difficult but they may also make keeping the payment difficult.

We propose adding a feature to allow recipients to actively accept payments. We dubbed the feature “checks” internally. A sender can, instead of making a payment, create a check payable to a recipient. The recipient would have to actively claim the check.

Users who do not want to receive unrequested payments could set their account to only accept checks. They could then simply not accept any unwanted payments. A whitelist of accounts permitted to send directly could be offered. Checks can also be used if the sender is not positive that the receiver still has access to the account. If the check is not cashed within some time period, the sender can cancel it and ensure the funds do not leave their account in the future.

This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/

You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

[Guest]

Quote

 

This would be an awesome feature!!

[ChrisMartinez]

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.

[mDuo13]

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.

[Malloy]

maybe not...if my unknown uncle from Nigeria wants to send me 1B XRP by mistake it's ok...

Seriously...it's a cool feature...

[ChrisMartinez]

@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 October 3, 2019 by ChrisMartinez

[Sukrim]

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.

[ChrisMartinez]

@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 October 3, 2019 by ChrisMartinez

[ChrisMartinez]

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 October 3, 2019 by ChrisMartinez

[Guest]

To me, checks are more than "good old paper checks". They could be seen as vouchers, gift-cards, "money" for in-game purchase etc.. Hopefully https://xrpl.org/known-amendments.html#checks shall be enabled soon.

[mDuo13]

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.

[ChrisMartinez]

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 October 3, 2019 by ChrisMartinez