Allow users to specify the specific terms of an offer they are responding to

[marv-engine]

Currently users submit a tx such as tx22 or tx0 to accept or participate in a posted offer. However, there's no way for a user to indicate the specific terms of the offer they want to accept. So the terms may have changed dramatically, or the offer may no longer be available by the time the user's response is processed. This adds uncertainty and risk to the user's participation.

I propose that we let the user specify the terms he's accepting. This can be done by including the txhash of the transaction that set the terms the user wants to accept with tx22. If those terms are no longer available for any reason, e.g. the terms have been updated by a newer transaction or the offer is no longer active, then the user's acceptance is invalid and the user hasn't committed to unintended terms.

For a crowdsale and future similar offers, there would be a new type of Send tx, e.g. SendResponse (or other meaningful name) that includes the txhash of the desired transaction.

Obviously this proposed change doesn't affect bitcoin sends, but that shouldn't prevent us from improving what we can.

[dacoinminster]

Interesting idea. I think we should definitely have the UI check that terms
have not changed before allowing the user to send payment, but I'm a little
reluctant to modify the protocol for this purpose. I'm trying to think of
an advantage to changing the protocol (vs just having the UI check that
terms have not changed) . . . .

On Tue, Sep 23, 2014 at 7:43 AM, Marv Schneider notifications@github.com
wrote:

Currently users submit a tx such as tx22 or tx0 to accept or participate
in a posted offer. However, there's no way for a user to indicate the
specific terms of the offer they want to accept. So the terms may have
changed dramatically, or the offer may no longer be available by the time
the user's response is processed. This adds uncertainty and risk to the
user's participation.

I propose that we let the user specify the terms he's accepting. This can
be done by including the txhash of the transaction that set the terms the
user wants to accept with tx22. If those terms are no longer available for
any reason, e.g. the terms have been updated by a newer transaction or the
offer is no longer active, then the user's acceptance is invalid and the
user hasn't committed to unintended terms.

For a crowdsale and future similar offers, there would be a new type of
Send tx, e.g. SendResponse (or other meaningful name) that includes the
txhash of the desired transaction.

Obviously this proposed change doesn't affect bitcoin sends, but that
shouldn't prevent us from improving what we can.

—
Reply to this email directly or view it on GitHub
#261.

[dexX7]

Currently users submit a tx such as tx22 ... Obviously this proposed change doesn't affect bitcoin sends ...

Actually tx 22 is the case where it does not matter, because the trade is secured by the two-step purchase process where terms are "locked" via the "accept offer" transaction. That's the (whole?) purpose of an "accept" step in the first place. If one ends up accepting terms that have changed in the meantime, the current assumption is that user would not continue with the payment and let the accept time out.

Nevertheless: this is an issue for crowdsales which can be manually closed. And with v1 prices might be changed as well - adding additional risk for potential buyers. Related: #132

Interesting idea. I think we should definitely have the UI check that terms have not changed before allowing the user to send payment ...

How would that help? Unless I got this topic wrong, it's about those edge-cases where the user assumes he gets X, sends his purchase/participate-in-crowdsale transaction and ends up with Y or nothing, because the issuer changed the terms in the meantime and the transaction to do this confirmed before the user's one.

[dacoinminster]

I think Marv is concerned that the user getting Y when they expected X
would be bad. Seems possible to avoid this in the UI though.

On Tue, Sep 23, 2014 at 3:05 PM, dexX7 notifications@github.com wrote:

Currently users submit a tx such as tx22 ... Obviously this proposed
change doesn't affect bitcoin sends ...

Actually tx 22 is the case where it does not matter, because the trade
is secured by the two-step purchase process where terms are "locked" via
the "accept offer" transaction. That's the (whole?) purpose of an "accept"
step in the first place. If one ends up accepting terms that have changed
in the meantime, the current assumption is that user would not continue
with the payment and let the accept time out.

Nevertheless: this is an issue for crowdsales which can be manually
closed. And with v1 prices might be changed as well - adding additional
risk for potential buyers. Related: #132
#132

Interesting idea. I think we should definitely have the UI check that
terms have not changed before allowing the user to send payment ...

How would that help? Unless I got this topic wrong, it's about those
edge-cases where the user assumes he gets X, sends his
purchase/participate-in-crowdsale transaction and ends up with Y or
nothing, because the issuer changed the terms in the meantime and the
transaction to do this confirmed before the user's one.

—
Reply to this email directly or view it on GitHub
#261 (comment).

[dexX7]

Well yeah, this is indeed concerning and the case in crowdsales.

How could this be avoided by the UI? The obvious case aside that a client already "knows" that the terms have changed, but I'm wondering about the cases where "purchase" and "change/cancel" transactions overlap.

[marv-engine]

My objective is to make these transactions as explicit and unambiguous as possible. I don't like the fact the current model is based on inference, e.g.:

• I saw what you had on sale just a short time ago. I'm sending you some money to make a purchase. I'm willing to purchase whatever you happen to have on sale, at whatever terms are in place, when the money arrives (by the way, it's ok if there's nothing on sale when you get my money).

I'm not aware of any other market that works this way.

The tx22 behavior is just a variation on this. A change in terms can turn a legitimate potential buyer into what looks like a troublemaker (accepting a sell offer and then not paying for it), potentially affecting that buyer's reputation. It also prevents anyone else from buying those MSC until the block time limit expires.

As @dexX7 said, a UI can't eliminate this race condition.

[dacoinminster]

I think the UI CAN make sure the terms haven't changed, and warn the user
if they have changed. It should be up to the user if they want to proceed. The
UI absolutely can prevent the user from getting Y when they expected X.

Interesting point about reputation. Hopefully any reputation systems would
check for conditions like "the terms just changed", and ignore a buyer not
paying, but I can see how explicitly referencing a hash of the old terms
would make things simpler for a reputation system. However, I doubt that
reputation systems alone are worth making this change.

Changing already implemented features at the spec level is very painful, so
the case for this has to be compelling. If this significantly harms the
user experience and the UI cannot work around it, that is when we would
want to make the change. If the UI can make the user experience acceptable
with the current rules, we shouldn't change them.

I think the UI can work around this, but I'm open to hearing arguments to
the contrary.

On Wed, Sep 24, 2014 at 7:37 AM, Marv Schneider notifications@github.com
wrote:

My objective is to make these transactions as explicit and unambiguous as
possible. I don't like the fact the current model is based on inference,
e.g.:

• I saw what you had on sale just a short time ago. I'm sending you
  some money to make a purchase. I'm willing to purchase whatever you happen
  to have on sale, at whatever terms are in place, when the money arrives (by
  the way, it's ok if there's nothing on sale when you get my money).

I'm not aware of any other market that works this way.

The tx22 behavior is just a variation on this. A change in terms can turn
a legitimate potential buyer into what looks like a troublemaker (accepting
a sell offer and then not paying for it), potentially affecting that
buyer's reputation. It also prevents anyone else from buying those MSC
until the block time limit expires.

As @dexX7 https://github.com/dexX7 said, a UI can't eliminate this race
condition.

—
Reply to this email directly or view it on GitHub
#261 (comment).

[marv-engine]

It's not only changes in the terms, but sales can close because they sell out. I don't see how a UI can reliably detect those events that aren't yet on the blockchain, and the order they ultimately will appear. I guess it could get close by pseudo-processing all the pending transactions, but that would mean duplicating in the frontend everything that mastercore does. Am I overlooking something?

As for the pain of "changing already implemented features at the spec level", I see it as adding features - a new Send tx for participating in a crowdsale plus a new version of tx22. Existing behavior doesn't change. The UI could even let the user choose the current or new.

Note the spec already has the notion of identifying an offer to sell, in the Futures section. See Listing Something for Sale.

... Every sale offer published by a given address gets a 32-bit "Listing ID" number assigned, which increments for each item offered for sale from that address. ...

The Initiating a Purchase tx uses that Listing ID to identify the offer. This approach also lets a user offer to sell multiple items from the same address - another user convenience.

[dexX7]

... Every sale offer published by a given address gets a 32-bit "Listing ID" number assigned, which increments for each item offered for sale from that address. ...

It would be a waste of space maybe, but referencing transaction ids instead would be bullet proof and could be adopted for "property ids" as well.

[dacoinminster]

I guess I assumed the UI already had to watch transactions coming over the
wire for other purposes.

I'm sold that this would be an improvement, but not sure how big the
complexity is compared to having the UI watch incoming TXs.

On Wed, Sep 24, 2014 at 12:40 PM, dexX7 notifications@github.com wrote:

... Every sale offer published by a given address gets a 32-bit "Listing
ID" number assigned, which increments for each item offered for sale from
that address. ...

It would be a waste of space maybe, but referencing transaction ids
instead would be bullet proof and could be adopted for "property ids" as
well.

—
Reply to this email directly or view it on GitHub
#261 (comment).

[dexX7]

Even if you watch unconfirmed transactions right from the moment they hit the mempool, you still have no guarantee or an insight about the final state or order. At best a client could notify the user about the new unconfirmed transaction that changes the terms, but that might be already too late.

Regarding complexity and current state: at the moment the UI and client isn't even able to subtract an amount from my balance, once I send a Simple Send, because it only parses confirmed transactions and has no knowledge about unconfirmed ones, even in this rather obvious case where I'm the sender. -- Notifications based on unconfirmed transactions are therefore a bit far away and it's still no complete solution.

---

Let's blank out the implementation, complexity and so on for a moment - because this is the spec which should be decoupled from actual implementation (and UI - which is yet another scope).

Goal: find a solution to prevent unintentional payments/purchases based on overlapping transactions which were initially broadcasted based on (as it turns out) outdated information.

Bonus: simplicity, small overhead (in terms of additional fields, length) and in the best case backwards compability

[dacoinminster]

Good point: UI interventions can significantly reduce, but not completely
eliminate this problem. I agree without reservation that we should do this

• we just need to prioritize it. Step 1 is the spec change. What do you
  guys think about making the tx hash optional?

Note that people participating in a crowdsale using bitcoins (not yet
implemented, but in the spec) aren't helped by this change.

On Wed, Sep 24, 2014 at 4:46 PM, dexX7 notifications@github.com wrote:

Even if you watch unconfirmed transactions right from the moment they hit
the mempool, you still have no guarantee or an insight about the final
state or order. At best a client could notify the user about the new
unconfirmed transaction that changes the terms, but that might be already
too late.

Regarding complexity and current state: at the moment the UI and client
isn't even able to subtract an amount from my balance, once I send a Simple
Send, because it only parses confirmed transactions and has no knowledge
about unconfirmed ones, even in this rather obvious case where I'm the
sender. -- Notifications based on unconfirmed transactions are therefore a

bit far away and it's still no complete solution.

Let's blank out the implementation, complexity and so on for a moment -
because this is the spec which should be decoupled from actual
implementation (and UI - which is yet another scope).

Goal: find a solution to prevent unintentional payments/purchases based on
overlapping transactions which were initially broadcasted based on (as it
turns out) outdated information.

Bonus: simplicity, small overhead (in terms of additional fields, length)
and in the best case backwards compability

—
Reply to this email directly or view it on GitHub
#261 (comment).

[dacoinminster]

Actually, this doesn't help someone purchasing MSC with BTC either (it
can't get their BTC back, it can only invalidate their purchase - the worst
of both worlds). Am I correct in stating that this is ONLY helpful for
someone participating in a crowdsale with a non-BTC currency?

On Thu, Sep 25, 2014 at 8:53 AM, J.R. Willett jr.willett@gmail.com wrote:

Good point: UI interventions can significantly reduce, but not completely
eliminate this problem. I agree without reservation that we should do this

• we just need to prioritize it. Step 1 is the spec change. What do you
  guys think about making the tx hash optional?

Note that people participating in a crowdsale using bitcoins (not yet
implemented, but in the spec) aren't helped by this change.

On Wed, Sep 24, 2014 at 4:46 PM, dexX7 notifications@github.com wrote:

Even if you watch unconfirmed transactions right from the moment they hit
the mempool, you still have no guarantee or an insight about the final
state or order. At best a client could notify the user about the new
unconfirmed transaction that changes the terms, but that might be already
too late.

Regarding complexity and current state: at the moment the UI and client
isn't even able to subtract an amount from my balance, once I send a Simple
Send, because it only parses confirmed transactions and has no knowledge
about unconfirmed ones, even in this rather obvious case where I'm the
sender. -- Notifications based on unconfirmed transactions are therefore a

bit far away and it's still no complete solution.

Let's blank out the implementation, complexity and so on for a moment -
because this is the spec which should be decoupled from actual
implementation (and UI - which is yet another scope).

Goal: find a solution to prevent unintentional payments/purchases based
on overlapping transactions which were initially broadcasted based on (as
it turns out) outdated information.

Bonus: simplicity, small overhead (in terms of additional fields, length)
and in the best case backwards compability

—
Reply to this email directly or view it on GitHub
#261 (comment)
.

[marv-engine]

It does help someone using tx22 to accept an MSC for BTC sell offer. The accept will not take effect if the terms have changed.

[dacoinminster]

I see what you're saying. In that particular case, the UI could handle it
100% though if need be. So, I see:

• Highest priority: use tx hash to prevent changing an offer during crowdsale
  with non-BTC currency
• Lower priority: use tx hash to assist UI in determining whether terms
  changed before accept was received when purchasing MSC with BTC

[marv-engine]

A more general approach (which also takes fewer bytes than the tx hash):

The purchaser specifies what currency he wants to buy, what currency he wants to pay with, how much he wants to spend, the minimum amount he is willing to get for what he pays, and the maximum amount he's willing to get for what he pays. This max amount lets the purchaser avoid buying if the price drops dramatically and he doesn't want to purchase if the bottom falls out.

If there's no offer that matches his terms, then the tx22 accept is invalid. This allows the terms to change as long as they are still within the purchaser's acceptable (pun intended) price range when the tx22 is processed. Note, the min & max amount to be purchased could be expressed as a percentage (0 - 255) rather than an absolute amount if we want to save 6 bytes per message.

Add the following fields to the tx22 message:

1. currency id to be bought (4 bytes)
2. currency id to pay with (4 bytes)
3. amount willing to spend (4 bytes)
4. minimum amount of currency to be bought (4 bytes)
5. maximum amount of currency to be bought (4 bytes)

I have a 2 related proposals, coming in separate issues -

1. to enable the purchaser to indicate that his bitcoin send is for tx22 purchase or a tx51 participation (which will also tell the seller that the buyer would like a refund if the payment is late).
2. a semi-automatic hybrid mechanism to enable a two-sided order book involving bitcoins on one side.

[dexX7]

It does help someone using tx22 to accept an MSC for BTC sell offer.

The current approach is that you would let it time out which shouldn't be a problem for you as buyer: Alice creates a sale of 10 MSC at 0.001 BTC each, Bob accepts, but in the meanwhile Alice raises the price to 1 BTC each, so Bob actually accepts an offer to buy 10 MSC for 10 BTC. Should he care? No, he just doesn't finalize the trade and does not pay. This has two downsides though: Alice' offer is still in an "accepted" state and thus not available to be purchased and Bob can't accept the new offer (maybe with a smaller amount to buy) during this timeout phase (of usually 10 blocks at the moment).

I'm really looking forward to see your proposals, and that being said: I'm really enjoying the ideas you published recently! :)

A small side note: I'd change the field order to:

1. Property to be bought
2. Amount willing to spend
3. ...

The underlying reason is the aim for uniformity. This transaction might be put in the category of "balance reducing", similar to a simple send. See my comments here: #111 (comment), #239 (comment) and @petertodd's post about the concept. To visualize (the schematic, abstract idea):

[marv-engine]

No objection to re-ordering the fields I proposed adding. I listed them in the order I had thought of them.

[dacoinminster]

No objections, other than not being sure how high priority this is . . .

On Wed, Oct 1, 2014 at 12:12 PM, Marv Schneider notifications@github.com
wrote:

No objection to re-ordering the fields I proposed adding. I listed them in
the order I had thought of them.

—
Reply to this email directly or view it on GitHub
#261 (comment).

[marv-engine]

Here's a variation on the current tx22 which also addresses the concern in #253 about fixed fees for DEx accepts:

A new version of the tx22 message would include the additional fields I proposed in #261 (comment) above. This new tx22 version would let the buyer express an intent to purchase at his specified terms, but without incurring the fee to reserve the MSC prior to payment. Because the MSC aren't reserved for that buyer, they are available for anyone to purchase or the seller's terms to be updated or the sell offer to be cancelled.

The buyer then sends bitcoins as payment within the sell offer's block time limit. If the buyer's terms can be met at the time of processing, then the buyer receives the corresponding number of MSC based on the number available and the price at the time of processing.

If the buyer's terms cannot be met for any reason, the buyer receives no MSC. The next step involves the wallet's participation: the combination of the incoming tx22 and that incoming bitcoin send from the same address are detected by the wallet. The wallet then alerts the seller that the bitcoin send was a failed attempt to purchase MSC and that the bitcoins should be refunded to the sender.

The benefits of this variation are:

1. to the buyer: no buyer's fee required
2. to the buyer: the buyer's purchase terms are respected
3. to the seller: no MSC are taken off the market while waiting for a payment
4. to the buyer: the seller is notified by the wallet of a failed purchase attempt, with an easy way for the seller to refund the bitcoin payment (minus miner's fee)

There are details and edge cases to be dealt with, e.g. what happens if for some reason the bitcoin send is confirmed before the tx22. Note that case isn't addressed in the spec now.

[dexX7]

... and that the bitcoins should be refunded to the sender.

Maybe I missed the part, but what mechanism is there in place to enfore a Bitcoin refund? What inceive is there to act honest?

[marv-engine]

There is no mechanism to enforce a bitcoin refund. My proposal provides a way to let the seller know that someone sent bitcoins to make a purchase and didn't get any MSC. The wallet can provide a button to easily send the refund.

This doesn't provide any incentive for the seller to be honest. It does encourage the seller to send the refund.

[marv-engine]

Note this same approach can be used for crowdsales that accept bitcoins. We just need an equivalent of the new tx22, to be used to indicate intent to participate in the crowdsale before sending btc. The early bird bonus percentage, if any, would be calculated when the btc send occurs.

[marv-engine]

see #268 for discussion on "Enable the purchaser to indicate that his bitcoin send is for tx22 purchase or a tx51 participation"