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

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ?? on ??

Quote from: Vanderbleek on November 22, 2011, 02:30:20 AM

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.

Vanderbleek

sr. member

Activity: 518

Merit: 250

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

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

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 ...

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: coblee on November 22, 2011, 01:28:52 AM

Quote from: coblee on November 21, 2011, 08:12:20 PM

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"

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: coblee on November 21, 2011, 08:12:20 PM

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.

jjiimm_64

legendary

Activity: 1876

Merit: 1000

Quote from: coblee on November 21, 2011, 08:12:20 PM

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

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

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.

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

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

Quote from: coblee on November 21, 2011, 06:56:59 PM

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

member

Activity: 115

Merit: 10

Quote from: coblee on November 21, 2011, 06:29:31 PM

Quote from: BeeCee1 on November 21, 2011, 06:13:52 PM

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.

Quote from: coblee on November 21, 2011, 06:29:31 PM

Quote from: BeeCee1 on November 21, 2011, 06:13:52 PM

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.

Quote from: coblee on November 21, 2011, 06:29:31 PM

Quote from: BeeCee1 on November 21, 2011, 06:13:52 PM

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

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

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

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: BeeCee1 on November 21, 2011, 06:13:52 PM

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?

Quote from: BeeCee1 on November 21, 2011, 06:13:52 PM

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)

Quote from: BeeCee1 on November 21, 2011, 06:13:52 PM

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.

BeeCee1

member

Activity: 115

Merit: 10

Quote from: coblee on November 21, 2011, 07:18:49 AM

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.

Vanderbleek

sr. member

Activity: 518

Merit: 250

I like it.

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: DeathAndTaxes on November 21, 2011, 05:20:48 PM

Why not cap fees where they are right now and use formula to decrease them as difficulty rises. With current fee structure spamming would only make sense if value of LTC fell 90% or so. If LTC value has fallen that much the risk of fees being too low are likely not really a significant concern.

It may be easier to convince people fees can only fall than fees can rise and fall but it is unlikely they will rise.

Sounds good. Thanks for the advice. Let's cap the fees at the current 0.1 LTC then.

Code:

Transaction and relay fees:
- base fee = 0.1 / difficulty
- capped at 0.1 LTC
- round to 1 significant digit

With the current difficulty at 0.63769 (0.1 / 0.63769 = 0.156816), the fee is capped at 0.1 LTC.
If the network doubles and difficulty doubles to 1.27538 (0.1 / 1.27538 = 0.078408), the fee will be reduced to 0.08 LTC.
If the difficulty increases tenfold to 6.3769 (0.1 / 6.3769 = 0.0156816), the fee will be reduced to 0.02 LTC.

Sounds good? We can adjust this if there's anything seriously wrong with it... like if the difficulty shoots up but the price stays the same, which makes spamming cheap again.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: coblee on November 21, 2011, 05:09:10 PM

Quote from: localhost on November 21, 2011, 04:57:45 PM

Quote from: coblee on November 21, 2011, 04:51:05 PM

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.

Why not cap fees where they are right now and use formula to decrease them as difficulty rises. With current fee structure spamming would only make sense if value of LTC fell 90% or so. If LTC value has fallen that much the risk of fees being too low are likely not really a significant concern.

It may be easier to convince people fees can only fall than fees can rise and fall but it is unlikely they will rise.

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: localhost on November 21, 2011, 04:57:45 PM

Quote from: coblee on November 21, 2011, 04:51:05 PM

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.

localhost

sr. member

Activity: 392

Merit: 250

Quote from: coblee on November 21, 2011, 04:51:05 PM

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).

bulanula

hero member

Activity: 518

Merit: 500

The difficulty TX fee idea seems to be neater than manually adjusted TX fees though. Maybe we should go with that ? Are deposits and withdrawals still messed up on BTC-E.com ? Thanks.

coblee

donator

Activity: 1654

Merit: 1351

Creator of Litecoin. Cryptocurrency enthusiast.

Quote from: localhost on November 21, 2011, 04:46:01 PM

Quote from: coblee on November 21, 2011, 04:38:23 PM

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. Wink

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.

localhost

sr. member

Activity: 392

Merit: 250

Quote from: coblee on November 21, 2011, 04:38:23 PM

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. Wink

Topic: [ANN] Litecoin - a lite version of Bitcoin. Launched! - page 353. (Read 1467291 times)