Comments (11)
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.
from spec.
@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.
from spec.
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.
from spec.
Hi @marvgmail,
it's a really interesting concept. I think you're onto something. :)
I'm currently wondering:
-
What are the use cases? Can you name a few examples?
-
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!".
-
If it's intended to avoid sending unintentionally tokens to Coinbase or other exchanges, what benefit does it have over Omni specific addresses?
from spec.
@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
from spec.
@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.
from spec.
@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.
from spec.
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.
from spec.
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.:
-
a ticket for admittance to an event
-
a limited time to pick up something, physical or digital, that was purchased online
-
indicating acceptance of an agreement
from spec.
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?
from spec.
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.
from spec.
Related Issues (20)
- Update specification for 0.0.10 changes HOT 4
- Best solutions to list USDT on an exchange? HOT 2
- A transaction send USDT(version:0.13) to BTC(version:0.16) address,How to transfer out from BTC address? HOT 8
- is there any qrcode spec like bip21? HOT 2
- TetherUS - USDT guide ? HOT 1
- Where could I find a detailed description of the freezing tokens and unfreezing tokens ?
- why omni do not support p2pk input as a sender in Class C? HOT 1
- Endianness is unspecified HOT 1
- Failed to load freeze state from levelDB. It is unsafe to continue. HOT 1
- [Question] Is there any risk by using the same address for toadress and feeaddress in omni_funded_send/omni_funded_sendall API? HOT 1
- Why are 32 bits of Property ID enough? HOT 1
- Convert Specification to AsciiDoc from Markdown HOT 3
- Start work on revised specification in file name OmniSpecification -- move spec out of README file HOT 4
- Update include images that still say Mastercoin or MSC. HOT 3
- #345 HOT 1
- Еду домой HOT 1
- taproot support
- Clarify and/or Improve Dev OMNI section in the specification
- [Discussion] On-chain protocol layer HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.