Enable the purchaser to indicate that his bitcoin send is for tx22 purchase or a tx51 participation

[marv-engine]

(I first added this as #261 (comment) to #261. It's moved here.)

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.

[marv-engine]

@dexX7 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.

[dexX7]

Sorry, I think I miss something important. Can we quickly go through the process with an example?

Step 1: the seller posts an offer:

Transaction version: 1
Transaction type: 20
Currency identifier: 1 (Mastercoin)
Amount for sale: 10 MSC
Amount of bitcoins desired: 1 BTC (= 0.1 BTC/MSC)
Payment window: 15 blocks
Minimum bitcoin transaction fee: ... depreciated?
Action: 1 (new offer)

Step 2: a buyer posts a buy intent:

Transaction version: 1
Transaction type: 22
Currency to be bought: 1 (Masterrcoin)
Currency to pay with: 0 (Bitcoin)
Amount willing to spend: 1 BTC*
Minimum amount of currency to be bought: 8 MSC (= 0.125 BTC/MSC)*
Maximum amount of currency to be bought: 12 MSC (= 0.0833 BTC/MSC)*

__One of them is not necessary: there is no need to define a maximum, if amount willing to spend is provided and a minimum amount to be bought.*

What happens next? At which point are amounts reserved and payments made?

[marv-engine]

@dexX7

*One of them is not necessary: there is no need to define a maximum, if amount willing to spend is provided and a minimum amount to be bought.

Specifying the maximum amount to be bought allows the buyer to prevent a purchase if the price has dropped so low that the buyer doesn't want to buy them because the seller is just trying to unload them on someone else.

There is no reservation of tokens to be bought. After the tx22 in your example, the buyer sends 1 BTC to the seller within the payment window. The protocol recognizes the send is related to the tx22. If the trade can occur within the limits specified by the tx22, the 10 MSC are transferred to the buyer. Otherwise no MSC are transferred from seller to buyer, but the wallet recognizes that it was a failed purchase attempt and prompts the seller to refund the 1 BTC back to the buyer.

This is better for the buyer because it alerts the seller to the fact that a purchase was attempted and failed. Otherwise, it's up to the seller to infer that it was a failed purchase attempt and then refund the 1 BTC based on his inference.

[dexX7]

Edit: #269 (comment)

If there is no reservation, what triggers the beginning of a payment window? A successful match? What happens, if no payment is made during that time?

I have no data regarding payments for Mastercoin, but I recently read a bit about Counterwallet (XCP web wallet). The DEx is similar to ours, but there is also a BTC buyer side - and once there is a match, the user is required to initiate a BTC payment whereby this is automated by the wallet (as long as the user is logged in). It turned out, the actual payment rate is less than 22 %.

Is there any reason to believe a mechanism that relies on user interaction once a match was found which is further limited by a payment timeframe would score higher?

... but the wallet recognizes that it was a failed purchase attempt and prompts the seller to refund the 1 BTC back to the buyer.

If you assume everyone acts honest, then we could indeed skip the whole accept/commit step and move to "every payment sent to a seller counts as (partial) payment".

I proposed a mixed-solution that allows instant-payments as well as two step purchases here: #252 (comment)

... but it's naive to assume this is always the case and I have a strong bias towards a solution that relies on honest actors. As long as there is no reputation involved or any other inceive, it's much more appealing to act dishonest.

[marv-engine]

@dexX7 Just like now, the tx22 triggers the beginning of the payment window.

My variation is analogous to someone seeing an item in a store advertisement in the newspaper (maybe I'm dating myself with this analogy). The person calls the store to see if they still have the item available. That lets the store know of the buyer's intent, but there's no commitment by either side. The store has the item(s), but won't reserve them for this buyer, so it's up to the buyer to go to the store and buy them before someone else does or there's an unattractive change to the terms.

Note that the time window could be specified by the buyer in the tx22. It's used by the protocol to recognize that a btc send from the buyer to the seller is supposed to be a payment. So, in this new tx22 version, the time window benefits the buyer more than the seller - because no tokens have been reserved by the buyer.

As for honesty affecting behavior by the participants - this new tx22 gives the seller an indication of someone's intent, but there's no risk for the seller if the buyer doesn't follow through. If the buyer's attempt to pay fails, all we can do is remind the seller that a refund is due.

FYI - a btc send to a tx20 address without first sending a tx22 is not recognized as a MP transaction, so it's just a btc send.