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

[marvgmail]

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

[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.