Quote from: localhost on November 21, 2011, 06:23:18 AM

Quote from: BeeCee1 on November 20, 2011, 11:39:48 PM

Quote from: coblee on November 20, 2011, 11:30:17 PM

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?

That would probably be ok, however, you can't choose which coins to use so if you had a bunch of older coins and one new one which was exactly the size you want, I think the client would choose that one. We'd need to combine it with a tweak to the coin selection algorithm

Yup, seems like a good idea.

Also, I'm not sure I understand why there isn't a 0.1 LTC fee per receiving address there:

Quote from: coblee on November 21, 2011, 03:06:54 AM

This guy just spent 9.3 ltc to spam these 0.00000001 ltc transactions:
http://blockexplorer.sytes.net/block/74c44fc98bbdafd1c2dfb72f2f26a0798492cbd30d2f55fcfafe88b6e1bb7bcb

The formula is: nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;

It's not about how many receiving addresses there are, but it's the size of the transaction that matters. These huge transactions take up ~49kb. In order for a client to relay these transactions, the fees must be at least (1 + 49,000 / 1000) * 0.02 ltc = 1 ltc. So he's paying 1 ltc on these transaction. And clients will propagate these transactions because there are enough fees. And miners that have not upgraded will write these transactions into blocks.

EDIT: If we increased transaction relay fees to the same 0.1 ltc as transaction fees, then he will need to spend 5 ltc as fees for these transactions. The cost to bloat the chain by 1gb will increase to $1,320... it's more but still fairly cheap.