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

[Vanderbleek]

I like it.

[BeeCee1]

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 like the idea of charging higher fees for lots of small outputs, however, we risk capturing small-but-useful transactions in the mix.  I also want to have fee formulas we can keep instead of temporarily changing them and planning on changing them back.  Instead of two tiers we could have three with only the lowest tier getting charged per-output fees
large value = no fee
small value = .1 fee per transaction
very small value = .1 fee per output

Make "very small" be 10% of small and all these too small to be useful even when aggregated transactions are really expensive, but leaves open the possibility of small but potentially useful transactions (like paypershare mining)

If we are making the fees additive, we'd want to remove the "if (nMinFee < nBaseFee)" check so people can't escape the per txout fee by making the block larger.

We can also have a higher fee for large-sized transactions.
From:        int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:          int64 nMinFee = (1 + (int64)nBytes /  500) * nBaseFee;

That would only have an effect on blocks larger than 27000 bytes (but we could make that smaller too).

Code:

            BOOST_FOREACH(const CTxOut& txout, vout) {
                if (txout.nValue < (CENT/10))
                    nMinFee += nBaseFee;
                else if ((txout.nValue < CENT) && (nMinFee < nBaseFee))
                    nMinFee = nBaseFee;
            }

This would be independent of any nMinFee scaling that was done based on difficulty.

[coblee]

I like the idea of charging higher fees for lots of small outputs, however, we risk capturing small-but-useful transactions in the mix.  I also want to have fee formulas we can keep instead of temporarily changing them and planning on changing them back.  Instead of two tiers we could have three with only the lowest tier getting charged per-output fees
large value = no fee
small value = .1 fee per transaction
very small value = .1 fee per output

Make "very small" be 10% of small and all these too small to be useful even when aggregated transactions are really expensive, but leaves open the possibility of small but potentially useful transactions (like paypershare mining)

Why do you draw the line at 0.001 ltc? is there really a special use case where someone would need to send tons of ~0.005 ltc to other people and only pay .1 in fees?

If we are making the fees additive, we'd want to remove the "if (nMinFee < nBaseFee)" check so people can't escape the per txout fee by making the block larger.

We can also have a higher fee for large-sized transactions.
From:        int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:          int64 nMinFee = (1 + (int64)nBytes /  500) * nBaseFee;

I've thought about this, but that's effectively just doubling the nBaseFee. So I'd rather change the base fee than mess with that code b/c there are other places that expect 1*basefee per 1000 bytes. (like the GUI)

Code:

            BOOST_FOREACH(const CTxOut& txout, vout) {
                if (txout.nValue < (CENT/10))
                    nMinFee += nBaseFee;
                else if ((txout.nValue < CENT) && (nMinFee < nBaseFee))
                    nMinFee = nBaseFee;
            }

I may want change CENT here to nBaseFee/10. As Litecoin gets more popular, and ltc price goes higher, what's classified as dust spam should also be lower.

[coblee]

I checked in code to deal with the dust spam: https://github.com/coblee/litecoin/commit/ee851e8cbdd74e8f0fe86613aa93f8c598ab88b4
Basically this changes the transaction relay fee to the same 0.1 LTC base transaction fee. And it adds a base fee for each output less than 0.01 LTC.

Please update to the latest code. As more users update, it will be harder for the spam to get to the old unupdated miners that mine the blocks with this spam. Of course, after updating, your mined blocks won't include this spam.

Note that this does not prevent the spammer to send thousands of 0.01 LTC outputs to himself or others. But this reduces dust spam, where people have to spend work dealing with tiny transactions that aren't worth much. If the spammers sends out 0.01 LTC spams to others, then at least he's also losing significant coins that way. If he sends it to himself, he'd have to deal with a bloated wallet and a slow client trying to deal with those transactions. So win/win.

Windows binary coming soon.

[BeeCee1]

I like the idea of charging higher fees for lots of small outputs, however, we risk capturing small-but-useful transactions in the mix.  I also want to have fee formulas we can keep instead of temporarily changing them and planning on changing them back.  Instead of two tiers we could have three with only the lowest tier getting charged per-output fees
large value = no fee
small value = .1 fee per transaction
very small value = .1 fee per output

Make "very small" be 10% of small and all these too small to be useful even when aggregated transactions are really expensive, but leaves open the possibility of small but potentially useful transactions (like paypershare mining)

Why do you draw the line at 0.001 ltc? is there really a special use case where someone would need to send tons of ~0.005 ltc to other people and only pay .1 in fees?

It is really just an acknowledgment that my imagination is limited and other people might be able to come up with something useful that wouldn't be possible with higher fees. Pay per share mining is one possible example, but I haven't every joined a pay per share pool so I don't know what they do when someone is due a very small payout.  I'm also thinking that if someone started trying to spam with >= 0.001 ltc then it would quickly add up to a useful amount of ltc.  Dust spam would still be prohibitively expensive though.

We can also have a higher fee for large-sized transactions.
From:        int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:          int64 nMinFee = (1 + (int64)nBytes /  500) * nBaseFee;

I've thought about this, but that's effectively just doubling the nBaseFee. So I'd rather change the base fee than mess with that code b/c there are other places that expect 1*basefee per 1000 bytes. (like the GUI)

It isn't quite the same since we use nBaseFee other places, like in the small transaction case.  If it is too hard to change then it might not be worth it.

Code:

            BOOST_FOREACH(const CTxOut& txout, vout) {
                if (txout.nValue < (CENT/10))
                    nMinFee += nBaseFee;
                else if ((txout.nValue < CENT) && (nMinFee < nBaseFee))
                    nMinFee = nBaseFee;
            }

I may want change CENT here to nBaseFee/10. As Litecoin gets more popular, and ltc price goes higher, what's classified as dust spam should also be lower.

I like your concept of auto-scaling the definition of spam.  Much better than requiring periodic intervention.

[coblee]

Version 0.5.0.7 released. Please update to help with dust spam.

https://github.com/downloads/coblee/litecoin/litecoin-windows-client-0.5.0.7.zip

I checked in code to deal with the dust spam: https://github.com/coblee/litecoin/commit/ee851e8cbdd74e8f0fe86613aa93f8c598ab88b4
Basically this changes the transaction relay fee to the same 0.1 LTC base transaction fee. And it adds a base fee for each output less than 0.01 LTC.

Please update to the latest code. As more users update, it will be harder for the spam to get to the old unupdated miners that mine the blocks with this spam. Of course, after updating, your mined blocks won't include this spam.

Note that this does not prevent the spammer to send thousands of 0.01 LTC outputs to himself or others. But this reduces dust spam, where people have to spend work dealing with tiny transactions that aren't worth much. If the spammers sends out 0.01 LTC spams to others, then at least he's also losing significant coins that way. If he sends it to himself, he'd have to deal with a bloated wallet and a slow client trying to deal with those transactions. So win/win.

Windows binary coming soon.

[coblee]

For those of you that have received dust spam (transactions with 0.00000001 ltc other tiny amounts), you may have trouble sending your coins. If you try to send coins, your client might be stuck trying to sort through all those transactions to come up with a list of inputs. ArtForz made a simple suggestion to have the create transaction code ignore transactions below a certain user-configurable amount. I will implement this soon and release a new client. Stay tuned.

[jjiimm_64]

For those of you that have received dust spam (transactions with 0.00000001 ltc other tiny amounts), you may have trouble sending your coins. If you try to send coins, your client might be stuck trying to sort through all those transactions to come up with a list of inputs. ArtForz made a simple suggestion to have the create transaction code ignore transactions below a certain user-configurable amount. I will implement this soon and release a new client. Stay tuned.

this might be what is happening with btc-e  wallet.?

[coblee]

For those of you that have received dust spam (transactions with 0.00000001 ltc other tiny amounts), you may have trouble sending your coins. If you try to send coins, your client might be stuck trying to sort through all those transactions to come up with a list of inputs. ArtForz made a simple suggestion to have the create transaction code ignore transactions below a certain user-configurable amount. I will implement this soon and release a new client. Stay tuned.

Here's the fix: https://github.com/coblee/litecoin/commit/f6fdedcf732265391eebbba48e8c537077b10f01

Windows binary coming up shortly.

[coblee]

For those of you that have received dust spam (transactions with 0.00000001 ltc other tiny amounts), you may have trouble sending your coins. If you try to send coins, your client might be stuck trying to sort through all those transactions to come up with a list of inputs. ArtForz made a simple suggestion to have the create transaction code ignore transactions below a certain user-configurable amount. I will implement this soon and release a new client. Stay tuned.

Here's the fix: https://github.com/coblee/litecoin/commit/f6fdedcf732265391eebbba48e8c537077b10f01

Windows binary coming up shortly.

Litecoin version 0.5.0.8 released.
https://github.com/downloads/coblee/litecoin/litecoin-windows-client-0.5.0.8.zip

You only need to download this if you have been sent dust spam and are having trouble dealing with it slowing down or crashing your client when you send coins. This new binary should fix the problem. When you run this new client, you will not be able to spend any coins that were sent to you in a transaction less than 0.0001 LTC. If you really need to spend those coins, you can start the client with "-mininput=0.00000001"

[kano]

Patch 99.99?
Again that's also the point of having more than one person decide and consider the options/problems rather than one person hacking and changing stuff over and over again.
Hopefully this includes resolving the problem (and not causing another problem) if you try to spend the remainder of your LTC ...
Expecting any more problems to pop up?

Edit: and if you try to spend them you will lose about 10000x their value in fees ...

[Vanderbleek]

Now devs who know more than me, correct me if I'm wrong, but I don't think any of these changes are mandatory. If you want, you could run an old version of litecoin-qt (or whatever), or even run your own wallet client thing. The TX fees are not required by the protocol persay, all that was being done was changing the default to accept them in a block and relay them...if I understand it correctly, you could mine blocks and not enforce ANY transaction fees, and no one could stop you.

The transaction fees are decided by the miners -- the miners could have rejected coblee's changes by not using the new version, and he couldn't have done anything. He produced a fix which most people think will work, so they switched over.

[kano]

Now devs who know more than me, correct me if I'm wrong, but I don't think any of these changes are mandatory. If you want, you could run an old version of litecoin-qt (or whatever), or even run your own wallet client thing. The TX fees are not required by the protocol persay, all that was being done was changing the default to accept them in a block and relay them...if I understand it correctly, you could mine blocks and not enforce ANY transaction fees, and no one could stop you.

The transaction fees are decided by the miners -- the miners could have rejected coblee's changes by not using the new version, and he couldn't have done anything. He produced a fix which most people think will work, so they switched over.

Exactly the old clients still work and if anyone wishes to use them to receive then propagate the spam transactions then feel free to do so, just don't come bothering us with the problems it can cause if you can't be bothered to upgrade...

The problem has already been caused - it seems that the attack was smarter than anyone realised (or more likely was smarter by mistake)
Many people now have 1000's (I have 6832) of tiny transactions that they cannot spend and need to be avoided or ignored for eternity.
They also exist in the block chain and will never disappear.

[coblee]

Now devs who know more than me, correct me if I'm wrong, but I don't think any of these changes are mandatory. If you want, you could run an old version of litecoin-qt (or whatever), or even run your own wallet client thing. The TX fees are not required by the protocol persay, all that was being done was changing the default to accept them in a block and relay them...if I understand it correctly, you could mine blocks and not enforce ANY transaction fees, and no one could stop you.

The transaction fees are decided by the miners -- the miners could have rejected coblee's changes by not using the new version, and he couldn't have done anything. He produced a fix which most people think will work, so they switched over.

Exactly the old clients still work and if anyone wishes to use them to receive then propagate the spam transactions then feel free to do so, just don't come bothering us with the problems it can cause if you can't be bothered to upgrade...

The problem has already been caused - it seems that the attack was smarter than anyone realised (or more likely was smarter by mistake)
Many people now have 1000's (I have 6832) of tiny transactions that they cannot spend and need to be avoided or ignored for eternity.
They also exist in the block chain and will never disappear.

Just use the new client to send your coins to a new wallet. Leave the dust spam in your old wallet and throw the wallet away and forget that you actually own those coins because they are worthless anyways.

EDIT: Or do what I do. Just use the new client and ignore the dust spam. Yeah, they clutter the transaction list, but once most people upgrade, there won't be much dust spam anymore. And they will be ignored when you send money. So your client will just report an extra ~0.00002 LTC that you can never spend. No big deal, right?

[Spacy]

Just use the new client to send your coins to a new wallet. Leave the dust spam in your old wallet and throw the wallet away and forget that you actually own those coins because they are worthless anyways.

Remote coin kill switch? So 1 person decides about protocol changes, and that I can't use my coins anymore? Seems like some things that people criticized about SC2 are now happening at LTC 

But I know, that's a totally different story...

[coblee]

Just use the new client to send your coins to a new wallet. Leave the dust spam in your old wallet and throw the wallet away and forget that you actually own those coins because they are worthless anyways.

Remote coin kill switch? So 1 person decides about protocol changes, and that I can't use my coins anymore? Seems like some things that people criticized about SC2 are now happening at LTC 

But I know, that's a totally different story...

Um...

If you really need to spend those coins, you can start the client with "-mininput=0.00000001"

The point is spending those coins will slow down the client right now b/c it takes forever to collect enough 0.00000001 LTC to make up a large enough value to send. So I changed the create transaction code to ignore these tiny values by default to speed things up. If you really want to spend them and wait forever for the client to create the transaction, you can by passing in a tiny min input.

Don't try to start a controversy when there isn't one. Please just go back to solidcointalk.org.

[CoinHunter]

The point is spending those coins will slow down the client right now b/c it takes forever to collect enough 0.00000001 LTC to make up a large enough value to send. So I changed the create transaction code to ignore these tiny values by default to speed things up. If you really want to spend them and wait forever for the client to create the transaction, you can by passing in a tiny min input.

You could also ignore these transactions (under the min amount) when checking blocks for wallet transactions. It will help improve the general performance of the wallet going forward too.

[mrx]

The point is spending those coins will slow down the client right now b/c it takes forever to collect enough 0.00000001 LTC to make up a large enough value to send. So I changed the create transaction code to ignore these tiny values by default to speed things up. If you really want to spend them and wait forever for the client to create the transaction, you can by passing in a tiny min input.

You could also ignore these transactions (under the min amount) when checking blocks for wallet transactions. It will help improve the general performance of the wallet going forward too.

it now takes about half a minute to load the blockchain on my server. If it can improve the loading process it would be great.

[michaelmclees]

Anyone thinking these changes are in any way like SolidCoin, doesn't know enough about SolidCoin.

Say it with me....  "Voluntary."

[CoinHunter]

Anyone thinking these changes are in any way like SolidCoin, doesn't know enough about SolidCoin.

Say it with me....  "Voluntary."

That's a bit like saying it's voluntary to update to a new SolidCoin version to get past a checkpoint. If someone cannot reliably send a transaction over the network I would say you are forcing them to update to use pretty much the main feature of a p2p cryptocurrency, sending money. A client which joins the network using an older version, can only connect to 8 other clients. If all of those clients have new rules for relaying transactions it's quite possible that new client will be unable to send some transactions out.