To remove the Accept step from a DEx purchase

[marv-engine]

The reason why a DEx purchase needs tx22 (Accept a sell offer) is to protect a buyer, because there's no way for the Master Protocol to send bitcoins from the seller's address, in case the purchase cannot be completed.

I'm proposing a way to eliminate the Accept step by introducing a known "Clearinghouse" address that accepts payments on behalf of all DEx sellers. Unlike a central exchange that holds the coins to be sold for an indefinite amount of time, the seller retains ownership of the coins for sale and the clearinghouse holds the BTC to make the purchase only for the duration of the Mastercore processing of the attempted purchase tx.

Here's the sell/buy flow:

1. Seller S publishes a sell offer (like now, but with no buyer fee or block time limit required)
2. Buyer B looks at the active sell offers and chooses one (S) to purchase
3. Buyer B sends a BTC payment for some or all of the offer to the Clearinghouse C
   • the seller's address is included in B's tx
   • C will generate 1 or 2 BTC sends, taking the miner fee from the BTC amount (see below)
4. Mastercore does the following for all these tx's that are addressed to C:
   • parse the message to get the seller's address (S, in this case) and the BTC amount sent
   • if S has an active sell offer, then /* exchange MSC for BTC */
     • calculate how many MSC can be bought (M) with the amount sent
     • if S has less than M MSC for sale, then
     • generate a BTC send from C back to B with the excess BTC
     • generate a BTC send from C to S with the BTC amount to pay for the amount of MSC to be purchased
     • transfer M MSC from S to B
     • (optional) transfer a small MSC fee from S to Exodus
   • else /* refund the attempted purchase amount */
     • generate a BTC send from C back to B with the BTC amount sent

At the end of the processing of each transaction, C will have no BTC so we don't need to worry about anyone misusing C's private key to steal any accumulated BTC.

This flow is appropriate when a buyer chooses a specific sell offer (and seller). The clearinghouse approach can be adapted to work for an order matching scheme (like tx 21) where the buyer specifies a max unit price rather than a specific sell offer.

If we need to make the clearinghouse address less detectable to uncooperative miners, we can periodically generate 1 or more new clearinghouse addresses and use #250 to make them available to instances of Omniwallet or other wallets.

[dexX7]

I really like the direction where this is going.

... generate 1 or more new clearinghouse addresses and use #250

This in particular seems impossible. The essence of #250 is to store information off-chain which inherently comes at the cost of less security and data availability than on-chain (and otherwise we could just move off-chain completely).

Say for example MasterCore client M parses the transactions and based on off-chain information clearinghouse C is identified - fine. What if another MasterCore client N has no knowledge about C, because the off-chain data source might not be available at the very moment?

At the end of the processing of each transaction, C will have no BTC ...

... if C keeps it's promise to send back the BTC. This sounds more secure than a traditional exchange, but I wouldn't go so far and introduce third party trust on a protocol level - this seems to open quite a few other problems on it's own. Maybe the first step could be changed to:

1. S publishes: "I want to sell xxxxx and I entitle clearinghouse C as escrow-agent"

With P2SH support, which is already live on testnet, there is also a very powerful new option: the ability to create multisig transactions where m-of-n parties need to be in consensus.

Did you consider this or ecrow/multisig in general?

[marv-engine]

@dexX7 I didn't consider P2SH, but since you bring it up can you describe what the mechanics would be?

[dacoinminster]

What I like about this is that it could give us a two-sided order book. A clearinghouse could hold the BTC which is "for sale". Obviously the protocol would have to have built-in "trust" for the clearinghouse address.

HOWEVER, I believe a clearinghouse (multisig or not) is a security vulnerability - an evil clearinghouse can always rip somebody off. Thus, if we run the clearinghouse, and a hacker breaks in to that PC, the hacker can steal funds from people trying to use the clearinghouse.

I spoke to Marv about this, and I believe this is a simple example of the age-old tradeoff between convenient centralization and two-step decentralization.

With that in mind, it occurs to me that an existing exchange like MasterXChange could be a clearinghouse right now (without any changes to the protocol) by setting up addresses where someone could send BTC and immediately get MSC in return (via market order) and vice-versa (send MSC and get BTC in return). I think such a service could be very valuable, since the exchange would only hold people's funds momentarily (just long enough for confirmations) before sending funds in return.

[dexX7]

MasterXChange

This makes me wonder: is there any route where a service such as MXC or a vending machine might serve as intermediate, removing one step by acting as buffer, but still maintains interaction with the DEx? Offers might be accepted upfront and put on the market and once bought, BTC payments could be initiated. Ideally rather longer-than-usual payment time frames would be beneficial, allowing to keep a certain window for several payments without the need of opening new "sell-accept-channels" every time.

... can you describe what the mechanics would be?

Alice, Bob and Carlos decide: "if either two of us three provide a cryptographic proof matching to the provided public keys of ours, so shall those be able to claim the coins that are to be associated with the hashed value of this statement" -- the bitcoin developer guide provides further details about the specifics, but it seems to come down to the ability of binding the success and likewise failure of spending Bitcoins to consensus of more than one entity.

The role of a clearing house in this context, at least to my understanding, is to ensure: "this or that payment is legit" and "these Mastercoins were indeed transferred and the seller shall now receive his Bitcoin payment".

Without having a specific protocol in mind, this sounds similar to: "the seller may only redeem the Bitcoins, if the clearing house agrees" and naturally "the seller may also redeem the Bitcoins, if the buyer agrees". Pretty much like a 2-of-3 situation where consensus from either seller and buyer or seller and clearing house is required. The clearing house could pre-approve actions from the buyer, so he can cancel the process at any time which would be fine, since this simply means there was no Mastercoin purchase at all.

How does this fit all together or look like in practise? I'm not sure.

[dexX7]

To pick up some thoughts of #184:

It seems beneficial to have a mechanism to combine accept and purchase:

• Seller defines minimum fee
• Mining fee + amount sent to the seller is counted as "fee"
• Amount sent to the seller is considered as partial payment

One extreme: a trusted vending machine with nearly unlimited tokens up for sale: one could just send the whole amount and basically skip the accept step, it's most likely safe to do so.

The other extreme: a buyer pays the minimum fee to the miners, ensures the offer was accepted, then sends the payment.

This doesn't seem to be exploitable, because the seller doesn't know, whether the buyer will pay the fee to the miners or to the seller.

[m21]

Sorry, but I don't see any benefits in just eliminating the "Accept" command from the protocol.

What exactly does that buy us right now besides more centralization, weaker security and bad PR about more magic Master Protocol addresses?

[dexX7]

No, no. Not eliminating the "accept" step, but rather counting coins sent to the seller as partial payment - not as replacement. Why? More choices and a faster route for risk-takers. ;)

Edit: underlying assumption on top: say we come at a point where a spam fee of 0.001 BTC is required to combat abuse. Would be painful, if this amount is "wasted".

[m21]

Making accept optional (the payment acting as an "Accept" in reserving/buying tokens for sale) is fine by me if that in itself is secure.

More Magic Addresses within the protocol and centralization is major disappointment.

[marv-engine]

@dexX7 can you elaborate on your 2 most recent comments? I don't get the specifics.

[marv-engine]

In the DEx, 1) the seller may update/cancel his sell offer, and/or 2) other buyers may purchase some or all of the sell offer after a prospective buyer retrieves the list of active sell offers.

Omniwallet has gotten negative feedback about the Accept step in the current DEx user experience, so my objective is to enable a buyer to purchase MSC with BTC in the fewest steps possible, while ensuring:

1. the buyer receives all the MSC he pays for
   • if less is available (e.g. someone else bought some in front of him), then he gets BTC change for the difference
   • if the sell offer has been cancelled, the buyer gets all his BTC back
2. the buyer doesn't lose any BTC
3. the seller receives the correct amount of BTC for the MSC delivered to the buyer
4. the seller doesn't lose any MSC

Maybe P2SH can be applied here, but I'm not sure.

I think the buyer should also be protected from changes to the sell offer that he cannot see before his purchase attempt is processed.

[dexX7]

I feel like this might be put into a different thread, but since the discussion is already ongoing:

Currently a seller defines a "minimum fee" when creating a sell offer. This minimum fee is intended to prevent abuse in the form of accepting sell offers without an actual intend to purchase the Mastercoins. Without such a mechanism, one could easily shutdown the whole DEx by accepting all offers without paying any.

Furthermore we associate this "abuse fee" with the "transaction fee", so, say for example, a seller creates a sell offer with a "abuse fee" of 0.0005 BTC, then a buyer would be required to send an "accept" transaction with at least 0.0005 BTC transaction fee attached.

This approach of linking the "abuse" fee to "transaction/mining" fee was chosen over one where the fee is directly send to the seller to prevent malicious sellers from creating dirt cheap offers with the intend of getting fees.

This worked pretty well, since the transaction fee was around 0.0001-0.0005 BTC, which seems fine to prevent abuse, but in reality there is no relation between an "abuse-prevention" fee and the transaction fee to begin with.

The cheaper the transaction fees are becoming, the more coins are "spent with no gain", simply to prevent abuse.

So what I proposed and what would be very, very handy in the whole context of a faster DEx trade:

Let's not define the "abuse fee" as "transaction fee", but instead as "transaction fee + amount send to the seller" - and furthermore consider any amount sent to a seller as partial payment.

Since this doesn't enforce that a buyer sends the amount to the seller and buyers may pay the abuse fee in terms of transaction fees nevertheless, there is no abuse potential from sellers which create cheap offers to get fees.

On the other hand this still serves as abuse protection and on top, it would be possible to purchase Mastercoins in one step, if the seller provides enough depth and the risk is low that there are no more Mastercoins for sale, but that's just an extreme.

Here are three use-cases:

The seller creates sell offer for 1000 MSC for 0.2 BTC each, the spam prevention fee is 0.005 BTC.

• Buyer A sends an accept for 50 MSC and attaches a transaction fee of 0.005 BTC. This is fine and after confirmation, he sends the payment amount of 10 BTC and gets his 50 MSC.
• Buyer B wants to buy 50 MSC as well, but in this case uses a transaction fee of 0.00001 BTC and sends 0.0049 BTC to the seller. This in combination is sufficient and the spam prevention fee is served. He will get about 0.25 MSC credited immediently and the rest after his full payment.
• Buyer C simply wants to purchase 2 MSC as fast as he can, so he sends his accept transaction with 0.4 BTC to the seller attached, which is way over the abuse prevention threshold of 0.005 BTC, and he will get the 2 MSC immediately.

[marv-engine]

@dexX7 How is the buyer protected with this approach?

[dexX7]

In the extreme case where buyer sends full payment in one step he indeed runs into the risk that there are no more Mastercoins for sale. This is rather an option for risk-takers or the case where sellers either provide enough depth or honor purchases in any case - such as a trusted vending machine for example.

The other goal is to turn the "wasted" amount, that would otherwise be spent in transaction fees, into a partial payment. The lower the actual transaction fees become, the higher the "wasted" amount (assuming a similar "abuse protection fee") and this seems to create a conflict of interest: buyers usually don't benefit from a high "abuse prevention fee" which could lead to a situation where sellers use a low "abuse fee" to stay competitive, but basically make the whole DEx vulnerable.

I think it's crucial that the buyer still has the option to pay the whole "abuse protection fee" as mining fee nevertheless.

"Proof-of-commitment" is probably a better wording for "abuse protection fee".

[dexX7]

Related to Omniwallet: I think the two step process is not necessarily the worst part here, but rather the general flow and interaction. I posted my feedback about this here: https://github.com/mastercoin-MSC/omniwallet/issues/892

if the sell offer has been cancelled, the buyer gets all his BTC back

Yea, that would be awesome. I think all we can do right now is to find a balanced solution which is not great, but rather the best of all trade-offs.

I didn't dig deeper into P2SH, but right from the start: at best this provides an option which requires minimal third party trust, but is not completely trustless - at least in the form I was thinking about.

I think the buyer should also be protected from changes to the sell offer that he cannot see ...

Yup, agreed. Would be nice, too. And this seems even more relevant in the case of a crowdsale and manual close.

[dacoinminster]

We just had a great call about this, and the consensus was: rather than remove the accept step, hide it from the user (optionally) so they can just set up a amount and price they want, and Omniwallet will automate everything with a progress bar and cancel button.

[dexX7]

Completely removing the step exposes the buyer, so I wouldn't do this, but is this is an either-or choice?

+1 for a smoother and more user friendly process with Omni.