Quote from: jakecnn on March 16, 2014, 06:53:04 PM

The payment in question is https://blockchain.info/tx/b9151c3371d46853e59ee6c9124c2a534f41363b29f372d914a19a83a5917665
and according to blockchain.info a tx-fee was paid.

This is not so much a problem of the Master Protocol, but more one of how bitcoin works. If I may take a moment to explain

Miners 'prioritize' transactions. This means when your transaction is relayed to a given mining client it adds the transaction to its memory pool and assigns a priority and fee. If the priority/fee is high enough, hopefully the transaction will be included in the next block.

Now - the interesting bit is in how this transaction priority is calculated by bitcoin core, as follows:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

Thus we can see the smaller and younger the inputs, the lower the transaction priority becomes.

If we specifically relate this to your transaction, we can see that the inputs were all very small. Additionally because there are a number of them, the size is actually over 1KB. Thus we have a small input value and a (relatively) large byte size for the transaction. If you pop those numbers into the formula above you'll see this provides for a very low priority transaction.

The good news (and this is bitcoin-wide) is that in laymans terms - the more you send, the higher your transaction priority. Thus this may be an issue for low value fractional transactions and I'll do some further investigation and discuss with the team - but essentially as the value of the DEx purchase increases, the risk of the issue you describe occurring decreases.

I have also been doing some thinking on input selection, but that would apply only to the Masterchest implementation when I get there. Currently I select smallest input for risk minimization (avoid losing a big input if something goes wrong creating the transaction). On the todo list is adaptive transaction encoding in the library, so rather than 'dumb' input selection we look at input values, ages and eventual transaction size to determine priority before it's broadcast & if this would result in a LP transaction that is likely to take a while to get mined, re-encode it if possible for a higher priority, else send it with a higher fee. That's a complex undertaking though so will take a little time (we always have to be careful when coding input selection and amounts as that's where the biggest potential to lose bitcoins sits IMO).

Thanks!
Zathras

EDIT: Also realized I wasn't explicit in stating it's of course also feasible to simply discourage (or disallow) fractional purchases of for example 0.000X BTC after a specific block height in the protocol itself too - the Master Protocol DEx has never been intended for high frequency or micro trading (and these micro trades cost more in fees than the trade itself).