CAMOPEJB
|
|
November 21, 2011, 11:12:57 AM |
|
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.
I think it's a great idea to pay fee if you are sending coins to more than one address at the same time - common user will never use that option and it will stop spamers! You have my support on it.
|
|
|
|
localhost
|
|
November 21, 2011, 11:15:03 AM |
|
I like this idea too
|
-
|
|
|
bulanula
|
|
November 21, 2011, 11:25:28 AM |
|
Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS . Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself.
|
|
|
|
Schwede65
|
|
November 21, 2011, 11:41:14 AM |
|
Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS . Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself. for whom is it useful to send one amount to many addresses at once? i give u a little hint: spammers... Great idea of coblee the fee for an output greater then 2 = 0.1 LTC/each transaction in my opinion it should be higher for greater outputs: for an output greater then 10 = 1 LTC/each transaction
|
|
|
|
CAMOPEJB
|
|
November 21, 2011, 11:42:51 AM |
|
ha-blody-ha!
bulanula, do you have any better solution to spam or even just idea?
|
|
|
|
coblee (OP)
Donator
Legendary
Offline
Activity: 1654
Merit: 1354
Creator of Litecoin. Cryptocurrency enthusiast.
|
|
November 21, 2011, 12:18:49 PM |
|
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
|
|
November 21, 2011, 12:27:01 PM |
|
Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS . Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself. for whom is it useful to send one amount to many addresses at once? i give u a little hint: spammers... Great idea of coblee the fee for an output greater then 2 = 0.1 LTC/each transaction in my opinion it should be higher for greater outputs: for an output greater then 10 = 1 LTC/each transaction Sigh ... knee-jerk reactions don't solve problems (as we have already seen ...) Although no one already does, you would hope that people (e.g. pools) would actually make single transaction payments rather than multiple 2 output transactions. This change is just saying that people should only use a standard 2 output txn for everything they do and not promoting optimum use of transactions at all. Since your both just picking random numbers and not thinking about them or asking for input on them, then pick 2 much larger random numbers. It would be WAY worse if the person doing this decided to put every single output pair into it's own transaction ...
|
|
|
|
FlipPro
Legendary
Offline
Activity: 1764
Merit: 1015
|
|
November 21, 2011, 12:33:15 PM |
|
Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS . Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself. LOL Now Litecoin finds itself in the same predicament that Solidcoin had to solve to fend off malicious attackers. It's going to be very interesting seeing how Coblee fixes this "bug" in the protocol.
|
|
|
|
coblee (OP)
Donator
Legendary
Offline
Activity: 1654
Merit: 1354
Creator of Litecoin. Cryptocurrency enthusiast.
|
|
November 21, 2011, 12:36:22 PM |
|
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.
|
|
|
|
coblee (OP)
Donator
Legendary
Offline
Activity: 1654
Merit: 1354
Creator of Litecoin. Cryptocurrency enthusiast.
|
|
November 21, 2011, 12:39:41 PM |
|
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.
|
|
|
|
tacotime
Legendary
Offline
Activity: 1484
Merit: 1005
|
|
November 21, 2011, 01:29:30 PM |
|
holy shit, just woke up to a 300% increase in difficulty.. The price of ltc may rally today.
|
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 102
Bitcoin!
|
|
November 21, 2011, 03:07:00 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?
It's a cat and mouse game. Would not the spammer just use coins that are two days old in that case?
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
November 21, 2011, 03:30:03 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?
It's a cat and mouse game. Would not the spammer just use coins that are two days old in that case? He would have to wait 2 days to be able to spam again after he exhausted his funds.
|
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 102
Bitcoin!
|
|
November 21, 2011, 03:31:53 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?
It's a cat and mouse game. Would not the spammer just use coins that are two days old in that case? He would have to wait 2 days to be able to spam again after he exhausted his funds. We don't know how many coins he has. He could spam for two days using 5% of his coins, and then start recycling the spammed ones for all we know.
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
November 21, 2011, 03:38:31 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?
It's a cat and mouse game. Would not the spammer just use coins that are two days old in that case? He would have to wait 2 days to be able to spam again after he exhausted his funds. We don't know how many coins he has. He could spam for two days using 5% of his coins, and then start recycling the spammed ones for all we know. Meh. Bitcoin has solved the problem with a combination of time and value based fee requirements. Why reinvent the wheel here?
|
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 102
Bitcoin!
|
|
November 21, 2011, 03:40:44 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?
It's a cat and mouse game. Would not the spammer just use coins that are two days old in that case? He would have to wait 2 days to be able to spam again after he exhausted his funds. We don't know how many coins he has. He could spam for two days using 5% of his coins, and then start recycling the spammed ones for all we know. Meh. Bitcoin has solved the problem with a combination of time and value based fee requirements. Why reinvent the wheel here? Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 102
Bitcoin!
|
|
November 21, 2011, 03:46:23 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. If he's using custom code to create the transactions, he can use whichever coins he wants to.
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
notme
Legendary
Offline
Activity: 1904
Merit: 1002
|
|
November 21, 2011, 04:05:29 PM |
|
Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.
Then why are we wasting time talking about how to fix it? Maybe I jumped in the middle of something without realizing what was really being discussed.
|
|
|
|
FlipPro
Legendary
Offline
Activity: 1764
Merit: 1015
|
|
November 21, 2011, 04:07:59 PM |
|
Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.
Then why are we wasting time talking about how to fix it? Maybe I jumped in the middle of something without realizing what was really being discussed. HENCE THE ENTIRE DILEMMA .
|
|
|
|
btc_artist
Full Member
Offline
Activity: 154
Merit: 102
Bitcoin!
|
|
November 21, 2011, 04:11:08 PM |
|
Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.
Then why are we wasting time talking about how to fix it? Maybe I jumped in the middle of something without realizing what was really being discussed. Alternate solutions are being discussed, but the currently implemented solution is what I said. (unless I'm mistaken)
|
BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
|
|
|
|