Or if predictability is that important, I can always fix the fee to the previous period's difficulty. So you will just use today's difficulty to figure out the fee for the next period. Sounds good indeed. And maybe to reduce variability (improve predictability even further), if it's not too much trouble, compute today's fee based on average diff of the last 2 weeks or something (like average of the last 4 diff). That would take a lot of work and I'm not sure it's necessary. The difficulty is already calculated using the average of the block times in the past period. Also, please remember that as Litecoin becomes more popular, the fee will go down. So I think having fluctuating but generally decreasing fees shouldn't really be a big problem. And if we lose hashrate, I'd be more worried about us getting 51% attacked than the fees. My first suggestion is that we cap the fees at 1 LTC, but I could reduce the cap to 0.2 LTC or even 0.1 LTC if that feels better. |
|
|
|
Though it's just a simple calculation that anyone can do if they know the difficulty, so it's not something mysterious. Yeah, I meant that more in the way that you can't predict what the fee will be like in a week (since the diff will change). I don't like unpredictable stuff. I believe lots of financial people don't like unpredictable stuff either, just see the mess at Wall Street and such.  Well you can just use allchains to get an estimate of next difficulty. Or if predictability is that important, I can always fix the fee to the previous period's difficulty. So you will just use today's difficulty to figure out the fee for the next period. Like everything it's a tradeoff. Would you rather have to upgrade every now and then to get new adjusted fees? Or would you rather have fees set automatically to something close but then it's not something that's fixed. |
|
|
|
Really sad to see LTC slip away into a maniacal man's paradise just like ScamCoin. Manual TX fee adjustments ? That sounds like fun  It's really hard to figure out your position on stuff, bulanula. And plus you seem to flip flop so often. Ever thought of running for a political position? Are you against manual transaction fee adjustments or for them? Do you know that the bitcoin fee has been manually adjusted from 0.01 btc to 0.0005 btc as the bitcoin price rose to $30? And now that the price is back to $2, the current bitcoin fees make it very cheap to spam bitcoin also. I'm not sure difficulty is that much linked to coin value. For instance, the BTC diff is now about what it was in early June or something, but its value is like 10 times lower.
Yes, so if bitcoin had auto adjusted fees, the fee won't increase back to 0.01 btc because the difficulty didn't drop so much. But it would be about twice the 0.0005 btc fee, which would at least be going in the right direction without having to release another client just to manually adjust the fees. I'm not sure either if a fluctuating fee (or to put it in other words, a somewhat unpredictable fee) is a good thing psychologically. Manual adjustment from time to time, depending on the economic situation, sounds good enough to me.
Yes psychologically, it might be bad. Though it's just a simple calculation that anyone can do if they know the difficulty, so it's not something mysterious. |
|
|
|
|
Here's another thought I have. Ideally, I'd like to tie the transaction fees with current price of Litecoin so that the cost of spamming stays the same in terms of fiat cost. (We are still living in a fiat world whether we like it or not.) But that's impossible to do in code. The next best thing is to tie it to the difficulty. The idea is that difficulty is loosely coupled with price. If ltc price goes up, difficulty will follow as more miners jump in. And as ltc price goes down, mining becomes unprofitable, miners leave, and difficulty goes down.
So we want an inverse relationship between the base fee and the difficulty. When Litecoin becomes popular and more people start to mine it and ltc price goes up, we want the fees to go down. And we should also cap the max fee at 1 LTC. Something like this.
BaseFee = 0.1 / difficulty (round to 2 significant digits)
With the current difficulty at 0.63769, the base fee will be 0.15 LTC.
If the network doubles and difficulty doubles, the base fee will be reduced to 0.075 LTC.
And if we ever go back down to difficulty of less than 0.1, the base fee will be at most 1 LTC.
Thoughts?
|
|
|
|
You don't even understand the problem that Litecoin is currently facing. Don't tell me I don't know what I'm talking about, when the exact thing happened with the very coin you're telling me to go back to.
I don't think the same thing happened to SolidCoin 1.0. SolidCoin 1.0 was using a fixed fee system, and ArtForz took advantage of that and spammed the network and only paying the same low fixed fee as everyone else. So RealSolid has to shutdown the chain because his change to Bitcoin's fee system backfired. Having a fixed fee is good, but that's assuming no one abuses it and sends spam transactions for low cost. Let me summarize what's been happening Dust spamming transactionsLitecoin is using the SAME Bitcoin code to deal with spam. The problem was that when I initially released Litecoin, I tried to change as a little as I could from Bitcoin. So I naively left the fee the same: 0.0005 ltc for transaction fee and 0.0001 ltc for transaction relay fee. This made it too cheap for a spammer to bloat our chain. The spammer started off by sending transactions with a ton of 0.00000001 LTC outputs and paying very little fees. (See: http://blockexplorer.sytes.net/block/4d5fc716d8a56f4223d38ebdaa2858551302d2118084448895db4131a3087117) So I increased it 200 times to make it closer to Bitcoin dollar-wise: 0.1 ltc for transaction fee and 0.02 ltc for transaction relay fee. See these 2 commits: https://github.com/coblee/litecoin/commit/b661930c59691761691e0690771981af37b2b835https://github.com/coblee/litecoin/commit/f0f9b11e860acb96279f26010c55d30b0684f10bExempt low-priority transactionsAfter this change went in, the spammer decided to send a lot of 2 LTC transactions for free. (See: http://blockexplorer.sytes.net/block/cf33787eec7468824617350664ec77048e6ecf47e6ade82a3bf07d5d566219a7) Bitcoin allows 3000 bytes of low priority transactions to go into a block for free. So he manages to fit about 13 of these transactions into each block without paying any fee. It's annoying but not too bad. But since we are finding blocks 4 times as fast as Bitcoin, this attack is 4 times as effective than a similar attack on Bitcoin. So I made the change to reduce the amount of exempt free transaction space to 500 bytes: https://github.com/coblee/litecoin/commit/65f2053c72522a12ff92429c28d654ac8002cea4https://github.com/coblee/litecoin/commit/332adc52190d079ccc3a6da0457ad2a494fc3866I also changed the priority threshold to match Litecoins parameters. It was previously using 144 for the numbers of blocks found a day. So by using 576, the priority cutoff is now 1 litecoin day per 250 bytes. https://github.com/coblee/litecoin/commit/8fe8e1304c7e7ed15e5499054e24b97b96ba98a1High-priority transactionsOnce that fix went in, the spammer can no longer fit 13 of those low priority transactions in each block. He can fit about 3. So he decided to make his transactions high priority. He started sending 577 coins to himself per transaction. (See: http://blockexplorer.sytes.net/block/960d4b540de8663508fad8e3a24b8329bc8c435a1233648281788a557ccbdcfb) He could then fit about 13 of these into a block. Since they are high priority, they can be sent without any fees. And they are only limited by the free transaction rate limiting code to prevent abuse. I then decided that we can live with this since honest user's transactions will be higher priority and will go in ahead of this spam. This attack will just slowly bloat the chain. Dust spamming transactions round 2I think after the spammer saw that I wasn't going to do anything about the high-priority transactions, he decided that's it's not worth his time to continue that since it's not doing much damage. He went back to dust spamming. But this time, he's taking advantage of the lower relay transaction fees and the fact that many users have not upgraded to the latest code. So he's paying 1/5 the cost that he normally should be charged. He's paying about 1 LTC for 50k of chain bloat. (See: http://blockexplorer.sytes.net/block/fa27fbea0d3e1a45021debb64c894ad619223baa5ee594c6fd47cda4d3e5168c) This is the problem we currently have. This exact same attack can be performed on Bitcoin, but I don't think anyone is wasting time with it. You can bloat the Bitcoin chain by 50kb by spending 0.025 btc or 6 cents. (and 1GB is only going to cost $1200) My fix proposed above should fix this problem for both Litecoin and Bitcoin. |
|
|
|
I don't really understand the inner workings of those transactions (and I'm just discovering about relay fees), but I guess if there was a way to make the transaction fee work per receiving address (like, sending 0.000001 LTC 100 times to different addresses or even from the same address to the same address = paying 100*0.1=10 LTC in transaction fees) this would impair his ability to cheaply make large transactions while not being an issue for legitimate users.
Here's my latest thought. I can force a transaction fee for each output greater than 2. Normal users will only send transactions to 1 address with a address for the change. Only advanced users will use the sendmany api to send coins to many address at once. I can force a fee to use the sendmany feature. So for every output greater than 2, you have to pay an additional 0.1 LTC fee. Without the ability to send to multiple addresses at once, I don't think the spammer can bloat the chain cheaply anymore. This might not be the best idea. Might work in the short term, but in the long term we probably don't want to do that. The main reason to use sendmany is to limit chain growth, so seems kind of silly to punish use of it. The idea I was going with is to punish someone for sending dust spam. Here's the original code: // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01 if (nMinFee < nBaseFee) BOOST_FOREACH(const CTxOut& txout, vout) if (txout.nValue < CENT) nMinFee = nBaseFee; Basically, we were setting min fee to at least 0.1 LTC if any of your output is less than 0.01 LTC. I'd like to extend that to add 0.1 LTC for every output less than 0.01 LTC. So using sendmany to send to 1000 outputs is fine as long as you are paying the 0.1 LTC fee per 1000 bytes. But if you are sending 0.00000001 LTC to each of those 1000 outputs, then you need to pay an additional 100 LTC in fees. // To limit dust spam, add MIN_TX_FEE/MIN_RELAY_TX_FEE for any output is less than 0.01 BOOST_FOREACH(const CTxOut& txout, vout) if (txout.nValue < CENT) nMinFee += nBaseFee; The spammer can still send a ton of 0.01 outputs, but this will deal with the dust spam. It's really hard for the receiving end to collect these worthless transactions. Here's this code in action on the testnet: http://blockexplorer.sytes.net/block/d1d987e3674b5f17a7881220376fb97aad9ec31880ac87b225c8dad5801dd215Each output that is less than a litecent adds an additional 0.1 LTC fee. |
|
|
|
It would be WAY worse if the person doing this decided to put every single output pair into it's own transaction ...
If he sent 1 transaction for each of his 0.00000001 LTC output, he would have needed to pay 0.1 LTC for EACH transaction. Or at least 0.02 LTC per transaction with the relay transaction workaround. I don't see how that's way worse. He's taking advantage of the fact that the fee system charges less fee for dust spams using sendmany. Please see my previous post on how I want to fix that. |
|
|
|
I don't really understand the inner workings of those transactions (and I'm just discovering about relay fees), but I guess if there was a way to make the transaction fee work per receiving address (like, sending 0.000001 LTC 100 times to different addresses or even from the same address to the same address = paying 100*0.1=10 LTC in transaction fees) this would impair his ability to cheaply make large transactions while not being an issue for legitimate users.
Here's my latest thought. I can force a transaction fee for each output greater than 2. Normal users will only send transactions to 1 address with a address for the change. Only advanced users will use the sendmany api to send coins to many address at once. I can force a fee to use the sendmany feature. So for every output greater than 2, you have to pay an additional 0.1 LTC fee. Without the ability to send to multiple addresses at once, I don't think the spammer can bloat the chain cheaply anymore. This might not be the best idea. Might work in the short term, but in the long term we probably don't want to do that. The main reason to use sendmany is to limit chain growth, so seems kind of silly to punish use of it. The idea I was going with is to punish someone for sending dust spam. Here's the original code: // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01 if (nMinFee < nBaseFee) BOOST_FOREACH(const CTxOut& txout, vout) if (txout.nValue < CENT) nMinFee = nBaseFee; Basically, we were setting min fee to at least 0.1 LTC if any of your output is less than 0.01 LTC. I'd like to extend that to add 0.1 LTC for every output less than 0.01 LTC. So using sendmany to send to 1000 outputs is fine as long as you are paying the 0.1 LTC fee per 1000 bytes. But if you are sending 0.00000001 LTC to each of those 1000 outputs, then you need to pay an additional 100 LTC in fees. // To limit dust spam, add MIN_TX_FEE/MIN_RELAY_TX_FEE for any output is less than 0.01 BOOST_FOREACH(const CTxOut& txout, vout) if (txout.nValue < CENT) nMinFee += nBaseFee; The spammer can still send a ton of 0.01 outputs, but this will deal with the dust spam. It's really hard for the receiving end to collect these worthless transactions. |
|
|
|
I don't really understand the inner workings of those transactions (and I'm just discovering about relay fees), but I guess if there was a way to make the transaction fee work per receiving address (like, sending 0.000001 LTC 100 times to different addresses or even from the same address to the same address = paying 100*0.1=10 LTC in transaction fees) this would impair his ability to cheaply make large transactions while not being an issue for legitimate users.
Here's my latest thought. I can force a transaction fee for each output greater than 2. Normal users will only send transactions to 1 address with a address for the change. Only advanced users will use the sendmany api to send coins to many address at once. I can force a fee to use the sendmany feature. So for every output greater than 2, you have to pay an additional 0.1 LTC fee. Without the ability to send to multiple addresses at once, I don't think the spammer can bloat the chain cheaply anymore. |
|
|
|
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: 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. |
|
|
|
So it's costing the spammer 1 LTC to send these huge transactions (~50kb). Doing the math (ignoring 1024 versus 1000)... 20 LTC for 1mb or 20,000 LTC for 1gb. 20k LTC is only $264 at today's exchange rate. So for someone who hates Litecoin, it only takes a measly $264 to bloat the chain by 1 gig. Not even Bitcoin has a chain that large. He's actually taking advantage of the relay transaction fees of 0.2 ltc to propagate his transactions and then taking of advantage of the miners who haven't upgraded to write his transactions into blocks. We could increase the relay transaction fee to the same .1 ltc (it's 0.02 ltc now), but that just means it's 5 times more expensive for him. Or we could increase both fees to 1 ltc and make it 50 times more expensive. Or we could do nothing. I've create a pool on the liteco.in forum. If you care about Litecoin, please vote: http://liteco.in/threads/what-should-we-do-about-transaction-spam.44/ |
|
|
|
Is this why I can't get LTC out of BTC-E atm btw?
Probably. I know they had trouble dealing with the 0.00000001 ltc transactions. |
|
|
|
I thought there was only 500 bytes of space allocated for free transactions, that block has over 3k and there aren't even any paid transactions. There are only 500 bytes of space allocated for low-priority free transactions. By sending 577 coins in a transaction, that makes the transaction high priority. So that's when the rate-limiting code kicks in. You are right, we could use the rate limiting code to reduce the number of free transactions per block, but that will limit non-spam free transactions also. If we can't handle a dozen transactions a block, we need to just shut down. The bloat is negligible. I say just ignore it.
Isn't booth Litecoin and Bitcoin pretty doomed anyway unless it is possible to implement a cut-off point for downloading the chain that at least keep the file under a few gig? So, does it really matter in the long run how big the chain gets?
BeeCee1 makes a good point why this is not about the long run: https://bitcointalk.org/index.php?topic=51915.msg622386#msg622386Right now, exchanges, pools, and block explorers are all having trouble dealing with this transaction spam. True in the long run, we'd all have to deal with it, but Litecoin is still young. It seems silly that 1 spammer can cause so much pain for everyone else that wants Litecoin to suceed. So I'm just trying to do what I can to fix this problem. Problem is if you can block real transactions that should have been free by doing this...
Yes, I'd like to avoid that. |
|
|
|
This spammer is quite annoying. He's started to spam 577 ltc transactions now. Due to the way we calculate priority, sending 577 coins (even with just 1 confirmation) makes it high priority enough that it can be done for free. And he's able to cram about 13 of these into each block for free: http://blockexplorer.sytes.net/block/6a73e81f628fbd612c6c1359f7c7ef06dce074d1946608b51756d08ce7e95178There's only so much we can do about this since we can't really tell that these are spam transactions. The way to stop this is to require a transaction fee on all transactions, but I don't think we want to go that route. If you send a free transaction with higher priority, it will be include in the block before these spam transactions. Or if you want your transaction to always be include, just add a fee. If this guy keeps sending 13 of these spam transactions per block, he will bloat the chain about 1.7mb/day. This might be something we just have to accept. This is the same way that Bitcoin works. If you have free transactions, there will be ways for malicious person to take advantage of it. 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? |
|
|
|
excellent work again - some LTCs are on the way  Thanks! |
|
|
|
He is probably going to figure out what types of transactions get in the block chain for free then try to send a bunch of those, pushing out genuine free transactions. This will make litecoin less inviting to newbies which is bad. I think we should come up with several algorithms for deciding which transactions are free and let miners decide which one to use (via a config file option) It would also be good to let miners configure a blacklist of addresses that they don't want included in blocks. I wouldn't want it populated by default, but if a user wanted to they could add addresses to it themselves and those wouldn't go in blocks or be broadcast to other connecting clients. This is all handled pretty well by the priority of transactions. The attacker will be resending newer coins so the priority will be lower than normal genuine transactions. So normal genuine free transactions will likely be include first before the spam transactions. |
|
|
|
Can we find out who is doing this at least ?
How do you propose we do that? No one has step forward and admitted doing this. But my fixes seem to be working. See this last block: http://blockexplorer.sytes.net/block/046ed8ad984dd05e62807eedde8de1706b753f8f0e1b35463c48214882d17b73The guy has started doing transactions with random amounts. Only of of those were include for free. And there were 3 that's costing him 0.1 LTC each. It's not much, but at least he's being charged for being a menace. And more profit for miners. Everyone, please upgrade to the latest code and things will get much better. Thanks. |
|
|
|
Yes, I think part of the allure is that they contain actual bitcoin value that you can use.
I suppose you're right. What if I offered a roll of 50 blanks, plus 50 printed gold foil stickers with the bitcoin addresses on them. I preload, or you preload, but either way, you stick them on. I actually have gold foil round stickers (same size as holograms) that have an invisible layer that can be printed on. If I don't have to apply the stickers by hand, the price goes way down. All of these are materials I have today, right now. Minting new coins, that'll be a couple months. I assume these would be 1 btc since the coins say 1 btc on them, right? Are you thinking of printing the mini key right on the gold foil? I'm just wondering if this will cause confusion with your original 1 btc series since the coin will look the same. |
|
|
|
OK, here is a random thought...
What if I sold rolls of 50 of the bitcoin brass coins? The exact same 1 BTC coin, but just the metal part. I could offer this today.
I have like 6,000 of ones with year 2011 left, and have already ordered some with the year 2012 printed on them.
A roll of 50 1BTC blanks, I could sell for as little as 10BTC.
Me personally, not interested. Unless I misunderstood, it would be no different than buying tokens for a carwash and giving them to people saying they are bitcoins. Same here. Tokens without actual bitcoin value is worthless to me. Stick with the 0.1 btc aluminum coins. I will definitely buy them to give away and help promote bitcoins. |
|
|
|
|
Show Posts
