Quote from: TomHolden on June 17, 2016, 09:44:20 AM

Quote from: tonych on June 16, 2016, 06:16:57 PM

It is not incentivized this way. Descending from a low-fee transaction still doesn't hurt as there is no limit on the number of parents.

Well, it's not quite true that there's no limit on the number of parents. You can only include a parent if it strictly increases the set of ancestors (so, for example, none of a nodes parents can be parents of each other).

Of course, it is a natural requirement (Iota lacks it, btw) that is easy to satisfy by considering childless parents only.

Quote from: TomHolden on June 17, 2016, 09:44:20 AM

A transaction sent with zero fee may perhaps be picked up by an altruistic individual, but they would unambiguously be incurring a cost with no reward if they did this. Firstly, including a transaction may restrict the set of other transactions you can include, if it is not already childless. Secondly, there is some (albeit small) computational cost to hashing in another transaction as a parent. . Thirdly, there is some (albeit small) bandwidth cost to broadcasting a transaction with another parent. Fourthly, since transaction size is increasing in the number of parents, and fees required are likely to be increasing in transaction size (see below), including additional parents may require paying a higher transaction fee. In the face of positive costs (albeit small) and zero gain, it is not rational to include such a transaction.

Obviously there is no point descending from a 0-fee transaction, but they still can be abused: a user could still build a long chain of his own transactions of which only the last one pays fees.

Quote from: TomHolden on June 17, 2016, 09:44:20 AM

For transactions with low fees, there is an additional two mechanisms. The makers of many transactions will seek to "gamble on inclusion" by including all remaining unclaimed fees. The more transactions a transaction descends from, and claims fees from, the higher the chance that it will be orphaned by another transaction which got to the network first, and which claimed at least some of the same fees. This is both because larger transactions will propagate slower, and because other transactions will be attempting to claim from the same parent transactions. Thus it is rational for makers of transactions claiming fees to restrict the set of parents to reduce the chance of being orphaned, meaning that transactions with low fees are likely to miss out, and hence face longer confirmation times. Transactions that do not attempt to claim all available fees are less likely to be orphaned, but rationally they should at least claim enough fees per parent to compensate for the costs of including a parent detailed above. So, if the equilibrium is that each transaction is attempting to claim 1% of the available fees of its parents (say), then the total transaction fees paid by a transaction need to be 100 times higher than the costs of including a parent. In this way, the small costs outlined in the previous paragraph are scaled up to something more significant.

Edit: There is one further mechanism. At least in times of low usage, any transaction which pays significantly less in transaction fees than it claims is likely to be replaced by an alternative transaction with the same parents, but which pays higher transaction fees.

If you have a set of 10 childless transactions, of which 9 are normal-fee and 1 is low-fee, and the low fee is above some tiny threshold which is the cost of hashing etc, would you lose the opportunity to earn some pennies that are just lying on the road? You can take 1% of the available fees if are are afraid of being orphaned.

In fact there are so many moving parts in the design (how much fees to pay, how much fees to claim, which parents to descend from) and so many dependent variables to optimize for (speed of confirmation, fees earned minus fees spent, chances of being orphaned) that the analysis of the design is already too complex, and chances that there are unforeseen abusive strategies look quite high. Your attempt to mix in some PoW adds even more complexity.

I'm also concerned how easily you orphan or replace transactions. Most people won't be happy to put their money into a system where there is such uncertainty about being able to send a payment.