[ANN] Litecoin - a lite version of Bitcoin. Launched!

[CAMOPEJB]

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.  

[1713948925]

1713948925

[localhost]

I like this idea too

[bulanula]

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]

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]

ha-blody-ha!

bulanula, do you have any better solution to spam or even just idea?

[coblee]

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]

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]

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]

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]

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/d1d987e3674b5f17a7881220376fb97aad9ec31880ac87b225c8dad5801dd215
Each output that is less than a litecent adds an additional 0.1 LTC fee.

[tacotime]

holy shit, just woke up to a 300% increase in difficulty.. The price of ltc may rally today.

[btc_artist]

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?

[notme]

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]

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.

[notme]

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]

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_artist]

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.

[notme]

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]

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]

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)