Adaptive DEx fees based on purchased amount

[dexX7]

Especially given that we are very near at the point where transactions are really cheap (watch closely.. ;), a fixed DEx fee seems outdated.

Currently a fee of usually 0.0001-0.0005 BTC is used, whether the purchased amount is 1 MSC or 1000 MSC. This seems broken and I suggest to adopt a fee based on the purchased amount and on a "per MSC" basis instead.

Say there is a seller with an amount of 500 MSC up for sale and the fee is set to 0.0001 BTC/MSC. One who wishes to reserve 200 MSC would pay a 0.02 BTC fee. while one who would like to reserve only 0.1 MSC would be required to pay only a fee of 0.00001 BTC.

[m21]

It makes some sense that the one reserving a lot should pay more than the one reserving a single unit.

But I don't like giving more the miners. Something towards the MSC & Master Protocol would be more appropriate. Since I don't have a good solution here I am not strongly pushing for any change, just commenting. :)

Also, advertising fees under the current Bitcoin's min per KByte, as in your example: 0.00001 could be confusing.

[dexX7]

There is no such thing as "current fee", but rather "default fee in Core client version X" and "fee used by miners". Anyway, that's a different topic. :)

But I don't like giving more the miners.

Why "more"?

Think of it this way:

You are the seller of 100 MSC and want to apply a "commitment-fee" (or "spam-fee", "protection-fee" ... whatever you like to call it) of 0.01 BTC, so no one dares to accept your offer without paying.

Currently this would be a transaction like:

transaction version: 1
transaction type: 20
currency identifier: 1 (Mastercoin)
amount for sale: 100.0 MSC
amount desired: 10.0 BTC (0.1 BTC/MSC)
payment window: 25 blocks
minimum transaction fee: 0.01 BTC <<
action: 1 (new)

• If a buyer accepts the whole amount of 100 MSC, he would need to spend at least 0.01 BTC as fee.
• If a buyer accepts an amount of 50 MSC, he still needs to spend at least 0.01 BTC as fee.
• If a buyer accepts an amount of 1 MSC, he still needs to spend at least 0.01 BTC as fee.
• If a buyer accepts an amount of 0.1 MSC, he still needs to spend at least 0.01 BTC as fee.

The proposed change would look like this:

transaction version: 2 <<
transaction type: 20
currency identifier: 1 (Mastercoin)
amount for sale: 100.0 MSC
amount desired: 10.0 BTC (0.1 BTC/MSC)
payment window: 25 blocks
minimum transaction fee per full unit: 0.0001 BTC <<
action: 1 (new)

• If a buyer accepts the whole amount of 100 MSC, he would need to spend at least 0.01 BTC as fee.
• If a buyer accepts an amount of 50 MSC, he would need to spend at least 0.005 BTC as fee.
• If a buyer accepts an amount of 1 MSC, he only needs to spend at least 0.0001 BTC as fee.
• If a buyer accepts an amount of 0.1 MSC, he only needs to spend at least 0.00001 BTC as fee.

In both cases you are equally well secured against abuse, but in the later case a buyer is more inceived to accept an amount that he really wants to buy. The total amount spent in fees is never more than in v1 and always the same, if the whole amount is sold in one trade.

[dacoinminster]

If the fee doesn't go to the miner, it should go to the MSC foundation, or
should be burned. It can't go to the seller (or they'll have perverse
incentives)

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

There is no such thing as "current fee", but rather "default fee in Core
client version X" and "fee used by miners". Anyway, that's a different
topic. :)

But I don't like giving more the miners.

Why "more"?

Think of it this way:

You are the seller of 100 MSC and want to apply a "commitment-fee" (or
"spam-fee", "protection-fee" ... whatever you like to call it) of 0.01 BTC,
so no one dares to accept your offer without paying.

Currently this would be a transaction like:

transaction version: 1
transaction type: 20
currency identifier: 1 (Mastercoin)
amount for sale: 100.0 MSC
amount desired: 10.0 BTC (0.1 BTC/MSC)
payment window: 25 blocks
minimum transaction fee: 0.01 BTC <<
action: 1 (new)

• If a buyer accepts the whole amount of 100 MSC, he would need to
  spend at least 0.01 BTC as fee.
• If a buyer accepts an amount of 50 MSC, he still needs to spend at
  least 0.01 BTC as fee.
• If a buyer accepts an amount of 1 MSC, he still needs to spend at
  least 0.01 BTC as fee.
• If a buyer accepts an amount of 0.1 MSC, he still needs to spend at
  least 0.01 BTC as fee.

The proposed change would look like this:

transaction version: 2 <<
transaction type: 20
currency identifier: 1 (Mastercoin)
amount for sale: 100.0 MSC
amount desired: 10.0 BTC (0.1 BTC/MSC)
payment window: 25 blocks
minimum transaction fee per full unit: 0.0001 BTC <<
action: 1 (new)

• If a buyer accepts the whole amount of 100 MSC, he would need to
  spend at least 0.01 BTC as fee.
• If a buyer accepts an amount of 50 MSC, he would need to spend at
  least 0.005 BTC as fee.
• If a buyer accepts an amount of 1 MSC, he only needs to spend at
  least 0.0001 BTC as fee.
• If a buyer accepts an amount of 0.1 MSC, he only needs to spend at
  least 0.00001 BTC as fee.

In both cases you are equally well secured against abuse, but in the later
case a buyer is more inceived to accept an amount that he really wants to
buy. The total amount spent in fees is never more than in v1 and always the
same, if the whole amount is sold in one trade.

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

[dexX7]

It can't go to the seller (or they'll have perverse incentives)

It could, if this would grant a partial payment -- but I agree and I think it would be required to keep both options (fees to miners and fees to seller), so there is no way for a seller to exploit this, because he doesn't know what a buyer might do.

[marv-engine]

Not directly related to fees, but I've thought the unit price should be less for a buyer who wants to buy more rather than less - effectively a volume discount. It could be tiered (as specified by the seller) or linear.

The seller's objective is to sell more sooner, so buyers should be encouraged to do that.

[dexX7]

unit price should be less for a buyer who wants to buy more rather than less

If you mention this in the context of floating fees, I'm actually split. In general I agree and it would be nice for a seller to sell in bulk at a slightly cheaper price, but I feel like the spam-fee is not the right tool here, because it does more harm than good usually (where usually equals rather low volume and transaction amounts).

Currently we use a static fee - which I consider as worth to update. The next step I had in mind was to adopt a fee model based purchased amounts.

The old model was: mininum fee = fee and the new model would be minimum fee = purchased-amount * fee. What if we add an exponent to this? minimum fee = purchase-amount * fee^x where x is 1.0 per default?

[dexX7]

Actually no, this is flawed:

• The fee is marginal anyway, but might (given the current, static fee) be very high for low orders while insufficient for large ones
• We can't reduce the fee for larger offers, because it protects them and reducing the fee also increases the potential attack of shutting down large offers without any purchase

I think it's worth to move the discussion about "dynamic prices" such as bulk orders to a new thread, so this one can focus on amount-based fees.

What's your general opinion about this topic by the way?

[marvgmail]

A few thoughts on the anti-prank fee:

1. it should be proportionate to the amount accepted vs the amount currently available, but the amount available could go up or down by the time the Purchase (accept offer) tx is processed, so there's no way for a buyer to reliably determine what the fee should be for a Purchase.
2. if the fee goes to the miner, how can the anti-prank fee amount be distinguished from a higher miner fee that's sent just to increase the processing priority for the tx itself?
3. how about this: if the purchaser sends no anti-prank fee (how would OC know?), then the time window to send payment is reduced to/by an amount so the "purchased" coins are off the market for a minimal amount of time (TBD) if the buyer doesn't send payment?

[dexX7]

1. If we do it, I would set the fee based on the amount to accept, which is known to the buyer.

2. That's an inherit issue.

3. Actually, that's a very interesting idea. What if we also introduce a time component? Instead if "must have a fixed fee", it turns into something like "to reserve 1.0 tokens for 1 block, you need to pay at least n fee", which increases for the amount to accept and the time to lock it. Then again, people may start to set the time limit too low, because they want to save money and then potentially miss the payment window. :/