I unintentionally participated in a crowdsale

[marv-engine]

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]

Is there a real-world analogy? Maybe:

• shopping on a site they award you shopping "points" to be used for later discounts
• shopping IRL, the store they may throw a gift in with the purchases
• airlines miles (analogy overused in Bitcoin2.0 space) - you get them no matter what
• a purchase over $100 makes your shipping cost free

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]

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]

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:

• a "no solicitors" sign
• the do-not-call list
• caller id
• "no thank you, I don't want any"
• "I'd like to buy this, not that"

(I'm traveling today and tomorrow.)

On Thursday, October 23, 2014, Michael [email protected] 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
#277 (comment).

Marv Schneider
VP, User Experience/Product Usability
Engine, Inc.
[email protected]

[dexX7]

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]

You can hardly prevent these in the real-world:

• shopping on a site they award you shopping "points" to be used for later discounts
• shopping IRL, the store they may throw in a gift with the purchases
• airlines miles - you get them every time you fly
• a purchase over certain amount awards you free shipping

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]

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]

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]

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:

• If no transaction reference xxx is provided, then the conditions and effects of an interaction at the time of confirmation apply.
• If xxx is given, then the participation in a crowdsale is only valid, if the terms of the crowdsale equal those defined by transaction xxx
• If xxx is given, then the accept of an offer on the traditional DEx is only valid, if the terms of the offer equal those defined by transaction xxx.

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.