New Tx Types: Send with Receipt Request, Send with Receipt (to prevent loss of misdirected funds, and other uses)

[marvgmail]

There's a longstanding and ongoing problem where owners of Omni Layer smart property tokens (mainly USDT, property id 31) mistakenly send tokens to an address who's owner doesn't use the Omni Layer protocol (typically an account deposit address at an exchange). That means the tokens end up sitting at the receiving address and the sender has no way to reclaim them - because the receiving address owner won't issue an OL transaction to send them back.

This proposal describes a mechanism to prevent future instances of this problem, where tokens languish in such addresses because the address owner won't submit an OL transaction to send them back (or anywhere else). It could also be used where an OL-aware exchange chooses to accept only a particular OL smart property at each deposit address.

Introduction

The mechanism involves two new OL transaction types. The first proposed new transaction type is Send with Receipt Request. It has the same fields as Simple Send, plus a timelimit field (in blocks) that specifies how long the recipient has to generate a receipt. The recipient then uses the new Send with Receipt transaction type within the specified timelimit to acknowledge that the tokens have been accepted.

Flow

The Send with Receipt Request (SwRR) tx type moves the specified number of tokens from the sender's available balance to the sender's reserved balance (TBD: or maybe to the recipient's reserved balance, if that makes more sense). The recipient then has to submit a Send with Receipt (SwR) tx referencing that SwRR so it is processed as valid within the specified timelimit number of blocks. If the SwR tx is processed as valid, then the referenced tokens are moved from the reserved balance to the available balance of the recipient specified in the SwR. In the case of an exchange, the new recipient address will likely be the the exchange's sweep address for that property.

If there is no corresponding valid SwR tx processed within the specified timelimit number of blocks, then the tokens are moved from the reserved balance back to the available balance of the original sender. This eliminates the risk that's associated with current misdirected OL sends.

Details

The SwR transaction message can specify either the txid of the corresponding SwRR or the address of the sender and the OL property type (in order to affect multiple SwRR transactions from the sending address). If a txid is specified and the SwR is valid, then all the tokens from that txid are transferred. If the txid doesn't refer to a valid SwRR to the address submitting the tx, or thetimelimit in the referenced SwRR has expired, then the SwR is invalid.

If an address and OL property type are specified, then all referenced tokens in unexpired SwRR transactions from the specified address to the address submitting the SwR tx will be transferred. (TBD: if there are no unexpired SwRR tx's, is that an invalid transaction, or is it valid and the number of tokens affected is 0?)

The tokens don't have to be moved to a third address. The recipient of the SwRR transaction can specify itself as the recipient of the SwR transaction.

As with US Postal Service return receipt requests, an exchange could choose to charge a fee to generate a receipt (the txid of the related SwR tx). That fee could be paid as an additional bitcoin output to the recipient address (which could be used by the exchange to pay the SwR transaction fee). If the SwRR doesn't include the necessary additional bitcoin output, the exchange could choose to not submit the SwR tx, thereby refusing and ultimately returning the account holder's deposit.

This proposal will require OmniCore to be efficient in how it is able to retrieve data associated with unexpired SwRR transactions - for providing status feedback to users and for returning the tokens to the sender's available balance when a timelimit expires.

I expect there will be other uses for SwRR and SwR.

[msgilligan]

I think the response should be called Send Receipt or SR (the "with" is confusing to me)

I think this is a novel and interesting solution to the I-accidentally-sent-Tether-to-Coinbase problem, but will only really be helpful if we make SwRR the default send transaction type in all/most wallets.

[marvgmail]

@msgilligan I added "with" because the tx is primarily a Send that happens to also serve as an acknowledgement. I'm not wedded to the names of either proposed tx.

As for making SwRR the default send - the unintended consequence there is that sends would be undone if a recipient isn't diligent about checking for and acknowledging the send. I think the wallet UI/UX could ask the user if she wants to use the mechanism when constructing each send.

[msgilligan]

the tx is primarily a Send that happens to also serve as an acknowledgement.

That makes sense. I will admit to skimming over that paragraph rather quickly.

As for making SwRR the default send - the unintended consequence there is that sends would be undone if a recipient isn't diligent about checking for and acknowledging the send. I think the wallet UI/UX could ask the user if she wants to use the mechanism when constructing each send.

I think the complexity you just described is probably a deal-breaker for this mechanism as a solution to the Tethers-to-Coinbase problem. (The TtC problem?) If we don't make it the default, people won't use it and they'll still send their Tethers to Coinbase. If we do make it the default, we'll have the above problems you just described.

[dexX7]

Hi @marvgmail,

it's a really interesting concept. I think you're onto something. :)

I'm currently wondering:

1. What are the use cases? Can you name a few examples?

2. If it's to avoid sending unintentionally tokens to Coinbase or other exchanges, then I think it won't work as intended, because people who unintentionally send tokens to Coinbase don't know they don't accept it, so may not think "Ah, this receiver may not create a receipt transaction, so I don't send my USDT!".

3. If it's intended to avoid sending unintentionally tokens to Coinbase or other exchanges, what benefit does it have over Omni specific addresses?

[achamely]

@marvgmail I second @dexX7 's comments however i would add that from a functionality point of view if/when the time limit expires the tokens do not 'automatically' move back to the sender but instead the sender then is 'allowed' (if they so choose) to broadcast their own SwR (or whatever we call it) to 'reclaim/return' the tokens to themselves. This allows the receiver at least a guaranteed time frame to claim the transfer but does not allow the tokens to just 'disappear' from the destination address without either party performing an explicit transaction.

I actually see very similar functionality in this and my other proposal of using CHECKLOCKTIMEVERIFY for the BTC/Token dex payments

[marvgmail]

@dexX7 @msgilligan The general use case is where someone wants to get a timely acknowledgement from the recipient for sending OL tokens, and if the ack doesn't happen within the time limit then they get their tokens back. It's not a perfect solution - nothing is, it requires trust that the recipient will do the right thing within the right time, but it eliminates risk for the sender. Simple Send is obviously more risky because there's no recovery mechanism.

Wallets/apps could make it the default Send transaction, with appropriate UI/UX to use Simple Send instead. It's just like sending an insured letter or pkg that requires a signature by the recipient. No signature --> no risk of loss due to an unresponsive or incorrect recipient. And, no claim has to be filed in order to get the sender's funds back.

I think it's simpler than Omni-specific addresses, especially for OL-aware exchanges because the routine case is handled the same as now, just with a different version of Send.

[marvgmail]

@achamely A reclaim/return tx would be fine, but note that the tokens were not delivered to the recipient. They were basically in escrow, waiting for the recipient to claim them within the specified time.

It is definitely similar to your proposal for using CHECKLOCKTIMEVERIFY for the BTC/Token dex payments.

[marvgmail]

I see this as similar to a check that says "Invalid after 60 days". If the recipient tries to cash the check after the time limit, that's when they find out it won't be honored, even if they had recorded it in their books as being received.

And in the case of a check, I don't know if/how the issuing bank automatically credits the amount back to the sender's account.

[marvgmail]

Other use cases are time-limited vouchers to be redeemed by the recipient. This would likely include the use of NFTs to uniquely identify the voucher - e.g.:

1. a ticket for admittance to an event

2. a limited time to pick up something, physical or digital, that was purchased online

3. indicating acceptance of an agreement

[dexX7]

I think it's simpler than Omni-specific addresses, especially for OL-aware exchanges because the routine case is handled the same as now, just with a different version of Send.

Except it needs an extra transaction and action from the receiver?

[marvgmail]

maybe the names should be something like Send Pending an Acknowledgement and Acknowledge and Send. These describe the behavior but not necessarily the user transaction.