search

OmniLayer / spec

Omni Protocol Specification (formerly Mastercoin)
The Unlicense
342 stars 116 forks source link

I unintentionally participated in a crowdsale #277

Open marv-engine opened 9 years ago

marv-engine commented 9 years ago

I was testing some new Send functionality in Omniwallet so I sent some TMSC to an address. Later I noticed that I now owned a currency that I hadn't owned before. It took me a while to figure out why/how that happened.

I have to say I don't like the fact that Sends are implicitly interpreted to mean something besides a transfer. I had no intention of participating in that crowdsale.

Such actions should be explicit. That's the simpler way for it to work - for all parties.

m21 commented 9 years ago

Is there a real-world analogy? Maybe:

Now, if you don't like any of the above -- you can throw them away, destroy them, give them to someone else, send them back. And I suspect the address you were sending to wasn't a 100% random address. You had some prior relationship with it.

m21 commented 9 years ago

In addition: I sometimes do send silly amounts of BTC & MP properties to random (existing) addresses on the blockchain. (Ok, I do it on TestNet 'cause I am not Satoshi.) And I do get random Satoshis on the MainNet from various advertises sent to me - not all confirm, but some do. The point here being is that I am never 100% in control of my addresses. Nothing is taken from me -- that's key, but stuff can and does get put into addresses w/o my consent or knowledge. Such is life I guess heh.

marv-engine commented 9 years ago

Clearly "Such is life I guess heh" is not the prevailing attitude for the bitcoin community. Also I don't know of a real world analogy where I send money to someone without an expected outcome.

With simple send I may get nothing, something I want or something I don't want. I have no control now.

Token ownership will be used to indicate membership or interest in something, so we'll need a way for users to control what they receive and the conditions for receiving tokens.

The real world analogies I use include:

(I'm traveling today and tomorrow.)

On Thursday, October 23, 2014, Michael notifications@github.com wrote:

In addition: I sometimes do send silly amounts of BTC & MP properties to random (existing) addresses on the blockchain. (Ok, I do it on TestNet 'cause I am not Satoshi.) And I do get random Satoshis on the MainNet from various advertises sent to me - not all confirm, but some do. The point here being is that I am never 100% in control of my addresses. Nothing is taken from me -- that's key, but stuff can and does get put into addresses w/o my consent or knowledge. Such is life I guess heh.

— Reply to this email directly or view it on GitHub https://github.com/mastercoin-MSC/spec/issues/277#issuecomment-60237519.

Marv Schneider VP, User Experience/Product Usability Engine, Inc. marv@engine.co

dexX7 commented 9 years ago

I still believe this is purely an UI issue, but probably a difficult-to-solve-elegant one.

But aside from receiving something that you didn't want, I'm all for explicit actions and the other issue - not the one related to receiving something - seems to be related to targeting of specific receivers, mechanisms, policies, ... whether that is the participation in a crowdsale, a simple send or accepting the terms of an offer with clearly defined boundaries. I believe this may be solved by providing additional information such as a reference to the transaction that created a crowdsale or an offer.

m21 commented 9 years ago

You can hardly prevent these in the real-world:

In crypto-world you have perfect control after you receive the tokens : destroy, send back, ignore. But this is impossible: "we'll need a way for users to control what they receive and the conditions for receiving tokens."

dexX7 commented 9 years ago

Well, on a protocol level there could be some flag to tag an address of your control as "not available" and any sends to this address would be considered as invalid, but I don't think this is the way to go.

marv-engine commented 9 years ago

We should decide what control an address owner can have WRT what others can do to that address. It's a general topic that will affect the behavior of several specific tx types and the UX associated with those tx's.

Starting with a broad discussion and then narrowing it to each instance is far better than trying to go the other way.

dexX7 commented 9 years ago

This issue + #132 + #261 + maybe #268 are all sort of similar and would benefit, if there were a mechanism to bind a transaction to a mechanism such as "this transaction is only valid, if all effects of a referenced transaction are still in place". To be more specific:

Why this would be helpful:

  1. A crowdsale can be manually closed and a participant may end up with nothing, if his send confirms after a manual close.
  2. The terms of a crowdsale can be changed and a participant may end up with something different than expected, if his send confirms after the new terms of a crowdsale were in effect.
  3. The terms of an offer on the traditional DEx can be changed and a participant may reserve an amount under conditions that are different than expected. This may have consequences for both buyer and seller, because the potentially not to be finalized reservation is in place until the reservation either times out or is canceled.

I consider 1 + 2 as very important and especially critical for a crowdsale with high volume. Hoping for good faith and manual refunds is no option in my opinion.

But that aside, this also has great consequences for autonomous systems. Let's say there is a crowdsale which grants one token X for one token Y - basically a "token converter" - usefulness aside, using such a "token converter" is only safe, if the outcome, namely the conversion of one X to one Y, is exactly as expected and nothing else.